Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.shell > #26850 > unrolled thread

ed __ ___ ________ ____ ______.

Back to article view | Back to comp.unix.shell

Contents

  ed __ ___ ________ ____ ______. Zayd Mohammed <zaydm@172.24.208.1> - 2026-06-08 02:16 +0000
    Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-08 04:46 +0200
      Re: ed __ ___ ________ ____ ______. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 13:44 +0000
        Re: ed __ ___ ________ ____ ______. gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-08 14:12 +0000
          Re: ed. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-08 19:30 +0000
        Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-08 14:40 -0700
          Re: ed __ ___ ________ ____ ______. groenveld@acm.org (John D Groenveld) - 2026-06-09 00:04 +0000
          Re: ed __ ___ ________ ____ ______. Adam Sampson <ats@offog.org> - 2026-06-09 01:50 +0100
          Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 16:47 +0200
            Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:41 -0700
        Re: ed __ ___ ________ ____ ______. Ben Collver <bencollver@tilde.pink> - 2026-06-09 14:27 +0000
      Re: ed __ ___ ________ ____ ______. Eric Pozharski <apple.universe@posteo.net> - 2026-06-08 22:28 +0000
      Re: ed __ ___ ________ ____ ______. Lumin Etherlight <lumin+usenet@etherlight.link> - 2026-06-09 03:25 +0300
        Re: ed __ ___ ________ ____ ______. Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-09 09:47 +0100
          Re: ed __ ___ ________ ____ ______. Joerg Mertens <joerg-mertens@t-online.de> - 2026-06-09 15:53 +0200
            Re: ed __ ___ ________ ____ ______. Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-09 21:00 +0100
            Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-09 16:29 -0700
              Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 08:39 +0200
                Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-11 13:40 -0700
                  Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-12 16:56 +0200
                    Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-12 15:22 -0700
                      Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-13 00:58 +0200
        Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-09 17:57 +0200
    Re: ed __ ___ ________ ____ ______. John McCue <jmclnx@gmail.com.invalid> - 2026-06-08 22:57 +0000
    Re: ed __ ___ ________ ____ ______. Lumin Etherlight <lumin+usenet@etherlight.link> - 2026-06-09 03:02 +0300
    Re: ed __ ___ ________ ____ ______. gmc@metro.cx (Koen Martens) - 2026-06-09 06:17 +0000
      Re: ed __ ___ ________ ____ ______. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:55 +0000
      Re: ed __ ___ ________ ____ ______. John McCue <jmclnx@gmail.com.invalid> - 2026-06-09 19:44 +0000
        Re: ed __ ___ ________ ____ ______. Top Dead Ctr <tdc@invalid.invalid> - 2026-06-09 14:09 -0600
        Re: ed __ ___ ________ ____ ______. Christian Weisgerber <naddy@mips.inka.de> - 2026-06-09 23:52 +0000
          Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:40 +0000
        Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:38 +0000
          Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-06-10 22:01 +0000
            Re: ed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:43 -0700
              Re: ed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 16:50 -0700
              Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:53 +0000
                Re: ed Eli the Bearded <*@eli.users.panix.com> - 2026-06-11 00:12 +0000
                  Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:55 +0000
                  Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 02:00 +0000
                    Re: ed Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-10 19:30 -0700
                      Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-11 11:31 +0000
                      Re: ed Christian Weisgerber <naddy@mips.inka.de> - 2026-06-11 15:02 +0000
                Re: ed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 08:46 +0200
              Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-06-11 14:28 +0000
            Re: ed cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-10 23:48 +0000
            Re: ed Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-06-11 00:24 +0000
              Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-06-11 14:11 +0000
                Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:22 +0000
            Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:53 +0000
              Re: ed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 09:02 +0200
      Re: ed __ ___ ________ ____ ______. Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-10 11:03 +0100
        Re: ed __ ___ ________ ____ ______. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-11 09:12 +0200
          Re: ed __ ___ ________ ____ ______. Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-12 09:44 +0100
            Android editor (Was: ed __ ___ ________ ____ ______.) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-12 09:03 +0000
              Re: Android editor Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-12 12:01 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#26915

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-11 22:40, Keith Thompson wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 2026-06-10 01:29, Keith Thompson wrote:
>> [...]
>>>> The par program by default does not format text the way
>>>> Lumin Etherlight does.  They might be using par with options.
>>>> "par -j" formats paragraphs by inserting spaces so the text is
>>>> right-justified. "par -j -w50" does the same, but with 50-character
>>>> lines.  I don't see an option to insert two leading spaces on
>>>> each line.
>>>
>>> (I'm a bit astonished that Vim doesn't natively support that. -
>>> Or does it, and I just don't know about it?)
>> It does, and I didn't know about it either.  "gq" followed by a
>> motion command formats text, possibly using a configured external
>> program.  ":help gq" in vim for more information.  (I've been using
>> key mappings to invoke "fmt" since before I'd even heard of vim.)
>
> Oh, I obviously was unclear. - I had been talking about the
> left-and-right block-alignment; the format we saw in Lumin's post.
>
> 'fmt' does *not* support that functionality. But 'par' *does*.

No I don't think you were unclear.  I use "fmt" rather than
"par" because (a) "par" probably didn't exist when I started
using "fmt" (and I'm not sure "vim" did), and (b) I don't *want*
left-and-right-justified text.  I'm now aware that vim has a built-in
feature for formatting paragraphs, but as Darth Vader would say,
"The intertia is strong with this one".

> Both can be used from within Vi or Vim with its _external filter_
> interface. But both are not *natively* supported in Vi. And 'gq'
> in Vim supports *native* formatting like 'fmt', but not like 'par'.
>
> You can also configure external commands. But my question was about
> a "native" support; because I like editing functions independent
> of environmental support, and I don't like plugins (which would be
> another options for those who think plugins are a good idea).

Quoting the vim documentation:
"""
JUSTIFYING TEXT         *justify* *:Justify* *Justify()* *package-justify*

Vim has no built-in way of justifying text.  However, there is a neat macro
package that does the job.  To use this package, execute the following
command: >vim

        :packadd justify

Or put this line in your |vimrc|: >vim

        :packadd! justify
"""

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#26916

On 2026-06-13 00:22, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-06-11 22:40, Keith Thompson wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> On 2026-06-10 01:29, Keith Thompson wrote:
>>> [...]
>>>>> The par program by default does not format text the way
>>>>> Lumin Etherlight does.  They might be using par with options.
>>>>> "par -j" formats paragraphs by inserting spaces so the text is
>>>>> right-justified. "par -j -w50" does the same, but with 50-character
>>>>> lines.  I don't see an option to insert two leading spaces on
>>>>> each line.
>>>>
>>>> (I'm a bit astonished that Vim doesn't natively support that. -
>>>> Or does it, and I just don't know about it?)
>>> It does, and I didn't know about it either.  "gq" followed by a
>>> motion command formats text, possibly using a configured external
>>> program.  ":help gq" in vim for more information.  (I've been using
>>> key mappings to invoke "fmt" since before I'd even heard of vim.)
>>
>> Oh, I obviously was unclear. - I had been talking about the
>> left-and-right block-alignment; the format we saw in Lumin's post.
>>
>> 'fmt' does *not* support that functionality. But 'par' *does*.
> 
> No I don't think you were unclear.  I use "fmt" rather than
> "par" because (a) "par" probably didn't exist when I started
> using "fmt" (and I'm not sure "vim" did), and (b) I don't *want*
> left-and-right-justified text.  I'm now aware that vim has a built-in
> feature for formatting paragraphs, but as Darth Vader would say,
> "The intertia is strong with this one".

Then we were (and probably still are!) talking at cross purposes.

I had been asking for a built-in 'par' like function; there isn't
one. (And I thought you had been trying to support my request with
the hints to 'fmt' in your post. - So *I* probably misinterpreted
your post as being an answer to my question.)

I also don't like block-formatting for posts. But it's useful for
specific purposes, and since it's an common editing/presentation
task it should (as Vim's 'gq') be a Vim built-in, in my opinion.

('gq' I'm actually using with Vim already for a very long time.
It's very useful and easy to type and use.)

> 
>> Both can be used from within Vi or Vim with its _external filter_
>> interface. But both are not *natively* supported in Vi. And 'gq'
>> in Vim supports *native* formatting like 'fmt', but not like 'par'.
>>
>> You can also configure external commands. But my question was about
>> a "native" support; because I like editing functions independent
>> of environmental support, and I don't like plugins (which would be
>> another options for those who think plugins are a good idea).
> 
> Quoting the vim documentation:
> """
> JUSTIFYING TEXT         *justify* *:Justify* *Justify()* *package-justify*
> 
> Vim has no built-in way of justifying text. 

Vim has 'gq' formatting natively; see point 3. below (:help gq).

     gq{motion}    Format the lines that {motion} moves over.
                   Formatting is done with one of three methods:
                   1. If 'formatexpr' is not empty the expression is
                      evaluated.  This can differ for each buffer.
                   2. If 'formatprg' is not empty an external program
                      is used.
                   3. Otherwise formatting is done internally.

In my standard Vim environment, the settings of 1. and 2. are empty.
So internal (native) formatting is used.

> However, there is a neat macro
> package that does the job.  To use this package, execute the following
> command: >vim
> 
>          :packadd justify
> 
> Or put this line in your |vimrc|: >vim
> 
>          :packadd! justify
> """

Yes, and this is plugin! - I said that I don't like to use plugins.
I use Vim *natively* with what it comes; it's extremely powerful as
it is already, and I want to avoid dependencies like external 'par'
commands or any plugins!

I've got an answer to my original "native block-formatting question"
("Or does it, and I just don't know about it?") also from the Vim
mailing list:

     There is no built-in command but there is a plugin distributed
     with vim. See ":help justify".

So I'm fine with my curiosity about that. And we can close the topic
(at least as far as my question goes). :-)

Janis

[toc] | [prev] | [next] | [standalone]

#26868

On 2026-06-09 02:25, Lumin Etherlight wrote:
> Janis  Papanagnou  <janis_papanagnou+ng@hotmail.com>
> writes:
> 
>> 'ed'  is  _a_  standard text  editor;  on  Unixes.
>> Though a very primitive one.
> 
>    It is indeed primitive, in the way a chisel is.
> 
>> (I wonder why one would make ones life harder than
>> necessary.)
> 
>          It is not harder with  ed.  As a user of ed,
>    who also  used emacs  and vim  for over  a decade,
>    (and many others) I don't view ed as a lesser tool
>    that is "behind" "modern" editors, I think ed is a
>    different mindset for editing, in the same vain as
>    vim being different from Visual Studio.  If a user
>    of Visual Studio says in relation to learning vim:
>    "Why make  one's life harder than  necessary", the
>    answer would  be very similar.  It  is harder only
>    because it didn't "click" for you yet.

These comparisons ignore some facts and put others in
one bag in an undifferentiated way. I disagree in most
of what you say here.

Line oriented editing (with 'ed' or 'ex' mode of 'vi')
is different from editing larger/other entities of text.
(You may not have used those "higher-level editing" in
your time of Vi/m (or Emacs) use, I have to presume. If
you'd have done you'd probably have missed them after
your switch back to a more primitive form of editing.)

Note that I'm not saying that you couldn't do a lot of
things in line oriented mode, or in sections that are
identified by ranges (lines or patterns). There's even
things that we can do only in ex-mode of vi.[*]

And as a valid sensible comparison of 'ed' and 'vi' the
only true point is pointing out the equivalences of Vi's
'ex'-mode and 'ed'.

For me an editor is "harder" (to fulfill some task) if I
need much more key-strokes, and/or if I have to switch
to the mouse or use menus, etc., or if I just cannot do
the editing with a specific tool. And I'm only speaking
about editing here, not about any IDE-functions or other
functionality outside editing.

(Your comparisons with the MS products make no sense to
me when it's about efficient editing. - I wouldn't start
an argument and won't follow your attempt.)

> 
>> Is that the reason why the formatting of your post
>> is corrupt?  (Or is it your newsreader settings?)
> 
>          Unlikely.  I'm also writing  this in ed, and
>    I don't think my formatting will be corrupt :)

To be frank, I also haven't expected that. Neither that
the 'slrn' would produce such results; quite some use
that newsreader and create clean posts. I was teasing!
But thanks for the confirmation.

(Though I'm still a bit curious what the actual reason
for his malformed post was.)

> 
>> Vim  is  not  based   on  the  Vi  code  base. But
>> functionally  yes,  mostly.   And you  won't  gain
>> anything  if  trying  to  somehow  relate  Vim  to
>> Ed;  these are  functionally completely  different
>> things.
> 
>          Vim, perhaps not.  As the culture around vim
>    is  no  longer similar  at  all  to what  ed  was.
>    People installing a 120  plugins to turn their vim
>    into an IDE  is exactly not what ed  is. 

I'm not sure what sick preconception you presume here.

I've certainly never installed any plugins in Vim. And
I started using Vi more than four decades ago, and I'm
using Vim almost since its beginning (without plugins).

Native Vim is still completely different to Ed (modulo
the Ex subset that has similarities with Ed, of course).

>    But, the
>    original vi  editors, I  would say they  were very
>    close  to  ed indeed.

You can say that for 'ex' mode but certainly not for
'vi'-mode or Vim's "visual" mode, ...

>    Screen  editing  is a  big
>    difference of course, but  with vi, you were still
>    meant to  integrate your  editor into the  rest of
>    your UNIX  environment using the vi  command mode,
>    you don't install  a plugin to wrap  lines in vim,
>    but you pass the text to fmt from vi.

...and picking a singular external filter doesn't make
the argument any better.

It's fine that the Vi concept allows to apply external
filters. (And for that specific 'fmt' example it's also
not necessary any more in Vim, of course, since it's a
builtin.)

'vi'-mode allows more than ex-mode functions and use of
external filters. And Vim makes it less necessary to use
external tools for editing purposes; but still possible.

>    With ed, it
>    is a  very similar approach.   The power of  ed is
>    that it is  open to the rest of  UNIX, and through
>    that integration, you gain great productivity.

Yes, indeed. (This is a feature that 'ed' also and still
has, as 'ex'/'vi' have it.)

But editing text is generally more than being able to use
external filters.

> [...]
> 
>    When I want to edit text, ed is my shell.

If it's sufficient for all you want to do with an editor
it's fine.

Janis

[*] A complex example from a Vi/Vim course I once gave
:/^Start$/,$g/^# Key//Control-Key/s/Hello/Hello World/

[toc] | [prev] | [next] | [standalone]

#26856

Zayd Mohammed <zaydm@172.24.208.1> wrote:
> ed is the standard text editor.

<snip>

Surprised no one posted this old link :)

https://www.gnu.org/fun/jokes/ed-msg.html

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#26861

Zayd Mohammed <zaydm@172.24.208.1> writes:

> reply here if you use ed and would like to talk
> about it, or if your nam e is ed!

        Yup,  ed man!   I  really  enjoy working  in
  ed.  It is  comfy, and helps with focus  a lot.  I
  find myself  preferring it to Emacs  sometimes.  I
  cheat  a  little  by  running  it  inside  rlwrap,
  providing  some  additional   features  like  line
  editing, keyboard macros, and  a shortcut to clean
  the screen.  The power  of piping text to external
  utilities cannot be understated.   I like using it
  with `par'[1] to fold lines  and align them, and I
  use aspell from the command line to spellcheck.  I
  also  like running  !make  and  other commands  to
  build  and run  and test  projects from  inside ed
  itself.  I think it  fits perfectly with the "UNIX
  as IDE"  mindset.  Oh, and  this is not  a repost,
  I'm actually writing this message in ed right now~
  Oh, and did  I tell you about the  power of search
  backwards when using rlwrap with ed?  If I've done
  something before,  I don't have to  remember it or
  retype it, I just C-r to search my command history
  and repeat  the action very quickly.   Good stuff.
  All the  docs are  in ed too!  !man or  !info, you
  have it all at your fingertips.

        Sadly,  I always  end  up  in emacs  anyway,
  because it is a lot more than an editor to me (I'm
  using  GNUS  to  browse  and post  on  Usenet  for
  example), plus, no editor I've used supports other
  languages, especially  RTL ones, as much  as emacs
  does.  And I  need to be able to write  my RTL TeX
  documents.  In a way ed /does/ support RTL, if the
  underlying  terminal does,  but  no terminal  I've
  seen  ever supported  Arabic well  for that.   The
  closest was  mlterm iirc,  but still, it  felt off
  the whole time.

  So yeah, if anyone would like to talk about it~


PS. Replied here and on comp.editors, didn't realize
    it was a repost from your own post 20 hours ago,
    I thought it was  some old circulating post.  My
    apologies.


Best Regards,
Lumin Etherlight

[toc] | [prev] | [next] | [standalone]

#26862

Zayd Mohammed <zaydm@172.24.208.1> wrote:
> ed is the standard text editor.

Ed made sense when your only way to interact with a system
was through a line printer (such as a DECwriter), but when
terminals with a screen and a cursor were invented, it was
rapidly supplanted by more usable editors.

> right now, i am using ed to edit this post!

And it shows ;)

Cheers,

Koen

-- 
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

[toc] | [prev] | [next] | [standalone]

#26863

On Tue, 9 Jun 2026 06:17:10 -0000 (UTC), Koen Martens wrote:

> Ed made sense when your only way to interact with a system was
> through a line printer (such as a DECwriter) ...

Let me suggest that TECO might be a more powerful editing system for
such an interface.

The earliest versions of Emacs were written in TECO.

[toc] | [prev] | [next] | [standalone]

#26869

Koen Martens <gmc@metro.cx> wrote:
> Zayd Mohammed <zaydm@172.24.208.1> wrote:
>> ed is the standard text editor.
> 
> Ed made sense when your only way to interact with a system
> was through a line printer (such as a DECwriter), but when
> terminals with a screen and a cursor were invented, it was
> rapidly supplanted by more usable editors.

There is one use for ed(1), when I boot NetBSD into single
user mode, ed(1) is the only one available without jumping
through hoops. To use it I just need to mount /tmp or / as
rw.

Not sure if that is the case with the Other BSDs.

<snip>

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#26871

On 6/9/26 1:44 PM, John McCue wrote:
>>> <snip>
>>
>> Ed made sense when your only way to interact with a system
>> was through a line printer (such as a DECwriter), but when
>> terminals with a screen and a cursor were invented, it was
>> rapidly supplanted by more usable editors.
> 
> There is one use for ed(1), when I boot NetBSD into single
> user mode, ed(1) is the only one available without jumping
> through hoops. To use it I just need to mount /tmp or / as
> rw.
> 
> Not sure if that is the case with the Other BSDs.
> 
> <snip>
> 

I've run into that as well.  Usually this works:

   $ TERM=vt100 vi <some_file>

-tdc

[toc] | [prev] | [next] | [standalone]

#26875

On 2026-06-09, John McCue <jmclnx@gmail.com.invalid> wrote:

> There is one use for ed(1), when I boot NetBSD into single
> user mode, ed(1) is the only one available without jumping
> through hoops. To use it I just need to mount /tmp or / as
> rw.
>
> Not sure if that is the case with the Other BSDs.

Same there.  Very useful when you screwed up /etc/fstab.

The OpenBSD installer is a ksh script running in a very limited
environment on a ramdisk.  The only editor there is ed and you can
use it to debug or directly modify the installer.  Been there, done
that.

Also, ed can be used to _portably_ edit a file in-place in a script.
For instance, the Game of Trees regression tests use it for that.

"And the next time you're at a job interview where you need to
demonstrate your skills by sharing your screen, establish your
dominance early. Use ed."
https://mwl.io/static/books/ed-mastery.html

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

[toc] | [prev] | [next] | [standalone]

#26877 — Re: ed

On Tue, 9 Jun 2026 23:52:03 -0000 (UTC), Christian Weisgerber wrote:

> The OpenBSD installer is a ksh script running in a very limited
> environment on a ramdisk. The only editor there is ed and you can
> use it to debug or directly modify the installer. Been there, done
> that.

Is there a BSD equivalent of this <https://www.system-rescue.org/>?

[toc] | [prev] | [next] | [standalone]

#26876 — Re: ed

On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:

> There is one use for ed(1), when I boot NetBSD into single user
> mode, ed(1) is the only one available without jumping through hoops.

Why is that? Is it because NetBSD still has the legacy root-versus-usr
separation of executables and libraries?

[toc] | [prev] | [next] | [standalone]

#26879 — Re: ed

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:
> 
>> There is one use for ed(1), when I boot NetBSD into single user
>> mode, ed(1) is the only one available without jumping through hoops.
> 
> Why is that? Is it because NetBSD still has the legacy root-versus-usr
> separation of executables and libraries?

From what I have seen, seems Linux does not have a real single
user mode.  But I think that is OK for Linux.

NetBSD and the other BSDs have real single user mode where no
file systems are mounted, no daemons are started and root is
mounted RO.  NetBSD boots into /bin/sh or a shell of your
choice and you work from that, no login needed.  Also I think
only static executables are available for use.

I do not know what "legacy root-versus-usr" means, I would
never want a system that does not have a clear separation
between root and users.

-- 
[t]csh(1) - "An elegant shell, for a more... civilized age."
                        - Paraphrasing Star Wars

[toc] | [prev] | [next] | [standalone]

#26880 — Re: ed

John McCue <jmclnx@gmail.com.invalid> writes:
> Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
>> On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:
>> 
>>> There is one use for ed(1), when I boot NetBSD into single user
>>> mode, ed(1) is the only one available without jumping through hoops.
>> 
>> Why is that? Is it because NetBSD still has the legacy root-versus-usr
>> separation of executables and libraries?
>
> From what I have seen, seems Linux does not have a real single
> user mode.  But I think that is OK for Linux.
>
> NetBSD and the other BSDs have real single user mode where no
> file systems are mounted, no daemons are started and root is
> mounted RO.  NetBSD boots into /bin/sh or a shell of your
> choice and you work from that, no login needed.  Also I think
> only static executables are available for use.
>
> I do not know what "legacy root-versus-usr" means, I would
> never want a system that does not have a clear separation
> between root and users.

That's not what it means.

Historically, /bin and /usr/bin were two different directories,
with /bin containing only executables that are needed during
system startup.  /usr/bin can be on a separate filesystem that isn't
initially mounted.  I think /usr was also where home directories were
located; for example, Dennis Ritchie's home directory was /usr/dmr.

I think the origin of that is an early PDP-11 or PDP-7 system at
Bell Labs that had limited space on its main hard drive a larger
secondary drive.

NetBSD 10.1, the latest release, retains that distinction.  I have
it running in a VM, and it has 39 files in /bin and 515 in /usr/bin.
All the executables are dynamically linked, but I think they
depend on on libraries in /lib, not /usr/lib.  /bin and /usr/bin
are on the same filesystem (though I think it can be configured
with /usr in its own filesystem).

Many other Unix-like systems have transitioned to making /bin a
symbolic link to /usr/bin.  But remnants of the old layout still
exist; for example /usr/bin and /bin are typically both in $PATH
even if they're the same directory.

Similar things apply to /lib and /usr/bin, and to /sbin and
/usr/sbin.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#26882 — Re: ed

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> John McCue <jmclnx@gmail.com.invalid> writes:
[...]
>> I do not know what "legacy root-versus-usr" means, I would
>> never want a system that does not have a clear separation
>> between root and users.
>
> That's not what it means.

To be clear, "root" here refers to the root filesystem, not to the
"root" user.

[SNIP]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#26883 — Re: ed

In article <110csrb$13aa9$2@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>John McCue <jmclnx@gmail.com.invalid> writes:
>> Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
>>> On Tue, 9 Jun 2026 19:44:19 -0000 (UTC), John McCue wrote:
>>> 
>>>> There is one use for ed(1), when I boot NetBSD into single user
>>>> mode, ed(1) is the only one available without jumping through hoops.
>>> 
>>> Why is that? Is it because NetBSD still has the legacy root-versus-usr
>>> separation of executables and libraries?
>>
>> From what I have seen, seems Linux does not have a real single
>> user mode.  But I think that is OK for Linux.
>>
>> NetBSD and the other BSDs have real single user mode where no
>> file systems are mounted, no daemons are started and root is
>> mounted RO.  NetBSD boots into /bin/sh or a shell of your
>> choice and you work from that, no login needed.  Also I think
>> only static executables are available for use.
>>
>> I do not know what "legacy root-versus-usr" means, I would
>> never want a system that does not have a clear separation
>> between root and users.
>
>That's not what it means.
>
>Historically, /bin and /usr/bin were two different directories,
>with /bin containing only executables that are needed during
>system startup.  /usr/bin can be on a separate filesystem that isn't
>initially mounted.  I think /usr was also where home directories were
>located; for example, Dennis Ritchie's home directory was /usr/dmr.
>
>I think the origin of that is an early PDP-11 or PDP-7 system at
>Bell Labs that had limited space on its main hard drive a larger
>secondary drive.

That's about right.  Btw, it was the -11; the organization of
the filesystem on PDP-7 Unix was very different.

>NetBSD 10.1, the latest release, retains that distinction.  I have
>it running in a VM, and it has 39 files in /bin and 515 in /usr/bin.
>All the executables are dynamically linked, but I think they
>depend on on libraries in /lib, not /usr/lib.  /bin and /usr/bin
>are on the same filesystem (though I think it can be configured
>with /usr in its own filesystem).
>
>Many other Unix-like systems have transitioned to making /bin a
>symbolic link to /usr/bin.  But remnants of the old layout still
>exist; for example /usr/bin and /bin are typically both in $PATH
>even if they're the same directory.
>
>Similar things apply to /lib and /usr/bin, and to /sbin and
>/usr/sbin.

Yup.  I usually just make one big filesystem on most machines.
There isn't much reason to split them up anymore.  Back in the
day, partition sizes were hardcoded and compiled into the
drivers for the different disk devices; you carefully chose how
you used each disk and which partitions you created filesystems
on.  BSD fixed that with disklabels; many commercial Unixes
similiarly with their own proprietary versions.  Now it is du
jour.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#26884 — Re: ed

In comp.unix.shell, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>> Historically, /bin and /usr/bin were two different directories,
>> with /bin containing only executables that are needed during
>> system startup.  /usr/bin can be on a separate filesystem that isn't
>> initially mounted.  I think /usr was also where home directories were
>> located; for example, Dennis Ritchie's home directory was /usr/dmr.
> Yup.  I usually just make one big filesystem on most machines.
> There isn't much reason to split them up anymore.

I've worked with systems where /usr was a NFS filesystem. You had to get
the system booted and on the network before you got /usr/bin. Another
factor for those old space limited systems was you probably wanted
everything in /bin to be statically linked while the /usb/bin stuff
could afford to rely on dynamic libraries, again possibly existing on
filesystems not mounted at boot or even not available until networking
is up.

These days you probably turn to busybox or the like when you need all
statically linked utilities.

Elijah
------
busybox has vi, but a really shitty vi

[toc] | [prev] | [next] | [standalone]

#26887 — Re: ed

On Thu, 11 Jun 2026 00:12:16 -0000 (UTC), Eli the Bearded wrote:

> Another factor for those old space limited systems was you probably
> wanted everything in /bin to be statically linked ...

Surely not. Shared libraries save space, after all.

Executables in /bin were allowed to depend on libraries in /lib.

[toc] | [prev] | [next] | [standalone]

#26888 — Re: ed

In article <eli$2606102012@qaz.wtf>,
Eli the Bearded  <*@eli.users.panix.com> wrote:
>In comp.unix.shell, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>>> Historically, /bin and /usr/bin were two different directories,
>>> with /bin containing only executables that are needed during
>>> system startup.  /usr/bin can be on a separate filesystem that isn't
>>> initially mounted.  I think /usr was also where home directories were
>>> located; for example, Dennis Ritchie's home directory was /usr/dmr.
>> Yup.  I usually just make one big filesystem on most machines.
>> There isn't much reason to split them up anymore.
>
>I've worked with systems where /usr was a NFS filesystem.

I remember that, back in the SunOS 4 and earlier days.  We
called it a "dataless" configuration: / and swap were local, but
/usr, /usr/local, and home directories came via NFS.  It wasn't
a bad way to do things.

>You had to get
>the system booted and on the network before you got /usr/bin. Another
>factor for those old space limited systems was you probably wanted
>everything in /bin to be statically linked while the /usb/bin stuff
>could afford to rely on dynamic libraries, again possibly existing on
>filesystems not mounted at boot or even not available until networking
>is up.

When Solaris 2 came along, essentially everything was
dynamically linked; statically linked binaries went into /sbin,
and my sense at the time was that 's' stood for 'static' (or
possibly 'standalone').  Nowadays, that is mostly system
utilities, whether statically linked or not, and so the meaning
has shifted again.

>These days you probably turn to busybox or the like when you need all
>statically linked utilities.

u-root ftw.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#26889 — Re: ed

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <eli$2606102012@qaz.wtf>,
[...]
> When Solaris 2 came along, essentially everything was
> dynamically linked; statically linked binaries went into /sbin,
> and my sense at the time was that 's' stood for 'static' (or
> possibly 'standalone').  Nowadays, that is mostly system
> utilities, whether statically linked or not, and so the meaning
> has shifted again.

My recollection is that the 's' in sbin (/sbin and/or /usr/sbin), has
always stood for "system".  Typically an ordinary non-administrative
user would not have /sbin or /usr/sbin in their $PATH, but both
would be in the default $PATH for the root account.

Wikipedia (which is not a primary source) says it's "system" or
"superuser".
https://en.wikipedia.org/wiki/Unix_filesystem#Conventional_directory_layout

I believe that the name "sbin" long predates Solaris 2.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.unix.shell

csiph-web