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 __ ___ ________ ____ ______. Daniel Cerqueira <dan.list@lispclub.com> - 2026-07-03 00:55 +0100
              Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-03 00:47 +0000
                Re: ed John McCue <jmclnx@gmail.com.invalid> - 2026-07-03 01:32 +0000
                  Re: ed Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-03 04:11 +0000
                    Re: ed Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-03 07:57 +0100
                      Re: ed Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-03 09:32 +0200
              Re: ed __ ___ ________ ____ ______. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-02 20:30 -0700
        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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#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]

#26894 — Re: ed

In article <110d6ks$15hpd$1@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>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

Ugh, don't nerd-snipe me, Keith: I've got work I have to get
done today.  :-)

I think wikipedia is right, though.

I can't remember when or where I first encountered /sbin, but I
see it was in Net/2 BSD, and I have it on good authority it was
in 4.3BSD-Reno.  It's for things that _used_ to be in /etc.
Note that in those days, BSD distributions from UC Berkeley did
not have shared libraries; those came later.  So everything was
de facto statically linked (kinda like how everyone drove a
manual transmission car and didn't really think about it until
the Jones's drove up with the first automatic on the block.  Now
I can't even buy a new stick shift if I wanted; I digress).

It appears that the intent for /sbin et al was always for it to
hold system binaries that were not of interest to general users,
but necessary for the correct functioning of the system.

	- Dan C.

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

#26897 — Re: ed

On 2026-06-11, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

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

BSD had an sbin _source_ directory since the beginning of the CSRG
repository in 1980.  The history of the Makefiles shows that the
_install_ location of init, mount, dump, etc. moved from /etc to
/sbin in 1989.

https://github.com/jonathangray/csrg

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

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

#26891 — Re: ed

On 2026-06-11 01:53, Dan Cross wrote:
> 
> [...]  I usually just make one big filesystem on most machines.
> There isn't much reason to split them up anymore.  [...]

I have one comparably "small" disk/file-system for all the system
stuff. My user's homes are on a separate 3-disk ZFS file-system.
(Privately I've no network storage; though that might make sense.)

Janis

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

#26896 — Re: ed

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> John McCue <jmclnx@gmail.com.invalid> writes:
<snip>
>>
>> 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,

Thanks, I needed a translation :)

<snip>
> 
> 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).

I checked, /bin/ed is dynamically linked and works in single
user mode.  NetBSD 11 RC4 still uses the same format as 10.1

And yes, you can mount /usr in its own partition (see below).

> 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.
> 

My NetBSD system on a T430, I have cgd(4) active.  The way I
set it up was /usr, /var, /tmp, /home and /u are in their own
"partition" on a cgd "slice".  / is unencrypted.  I still find
BSD slice vs partition confusing. YMMV :)

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

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

#26881 — Re: ed

In article <110cmrj$32trj$1@dont-email.me>,
John McCue  <jmclnx@gmail.com.invalid> wrote:
>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.

Hmm, boot with `init=/bin/sh` is probably pretty close.

>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.

Dynamic executables can be used, provided the shared objects
are available.  "Single user mode" really just means that the
full boot sequence hasn't run and a shell got started on the
console; it doesn't change much else (all of the mounting of
filesystems and so on happens in a startup script)..

>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.

Lawrence is a known troll.  I'm sure he's referring to the
split between `/bin` and `/usr/bin` etc.  Ie, why have some
things on the root filesystem (`/bin`) and others in the `/usr`
filesystem (`/usr/bin`).  There is an answer; it's historical.
`/usr` is actually the _user_ filesystem; that's where home
directories went.  And there was more space on that device than
on the device that contained `/`, so `/usr/bin` was born for
binaries that were too big to fit on `/bin`.

Several systems have more or less done away with the split, now
that disk is plentiful.  Linux and Solaris spring to mind;
others keep the split for organizational purposes.  It doesn't
really say anything about a system, however, beyond what
aesthetics its users and maintainers subscribe to.

	- Dan C.

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

#26885 — Re: ed

On Wed, 10 Jun 2026 22:01:23 +0000, John McCue wrote:

> 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.

Oh, do you mean initlevel "S" or "s"? As in:
 si:S:sysinit:/etc/rc.d/rc.S
 su:1S:wait:/etc/rc.d/rc.K

20:21:14 $ head /etc/rc.d/rc.S
#!/bin/sh
#
# /etc/rc.d/rc.S:  System initialization script.
#
# Mostly written by:  Patrick J. Volkerding, <volkerdi@slackware.com>
#
20:22:43 $ head -12 /etc/rc.d/rc.K
#! /bin/sh
#
# rc.K          This file is executed by init when it goes into runlevel
#               1, which is the administrative state. It kills all
#               daemons and then puts the system into single user mode.
#               Note that the file systems are kept mounted.
#
# Version:      @(#)/etc/rc.d/rc.K      3.1415 Sat Jan 13 13:37:26 PST 2001
#
# Author:       Miquel van Smoorenburg <miquels@drinkel.nl.mugnet.org>
# Modified by:  Patrick J. Volkerding <volkerdi@slackware.com>
#

Like Slackware??


> 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.

Agreed.

Although the OP might have meant the current (IMHO aberrant) trend
of dispensing with the /bin vs /usr/bin (etc) dichotomy. 


-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

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

#26895 — Re: ed

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
<snip>
> 
> Oh, do you mean initlevel "S" or "s"? As in:
>  si:S:sysinit:/etc/rc.d/rc.S
>  su:1S:wait:/etc/rc.d/rc.K

In a way, yes.  When I boot Slackware single user, an extremely
rare occurrence, I can see whit I think are many kernel items
executing in background plus files systems are mounted.  On
NetBSD, nothing is running in background and only / is mounted
RO.  But for Linux that is not a major deal, just different.
That is why said "BSD has a real single user mode".

FWIW, I use lilo and I just type 'single' to boot single
user or I do a '/sbin/telinit 1'.

> 
> 20:21:14 $ head /etc/rc.d/rc.S
> #!/bin/sh
> #
> # /etc/rc.d/rc.S:  System initialization script.
> #
> # Mostly written by:  Patrick J. Volkerding, <volkerdi@slackware.com>
<snip>
> Like Slackware??
> 
> 
>> 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.
> 
> Agreed.
> 
> Although the OP might have meant the current (IMHO aberrant) trend
> of dispensing with the /bin vs /usr/bin (etc) dichotomy. 
> 

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

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

#26899 — Re: ed

On Thu, 11 Jun 2026 14:11:39 -0000 (UTC), John McCue wrote:

> When I boot Slackware single user, an extremely rare occurrence, I
> can see whit I think are many kernel items executing in background
> plus files systems are mounted. On NetBSD, nothing is running in
> background and only / is mounted RO. But for Linux that is not a
> major deal, just different. That is why said "BSD has a real single
> user mode".

That’s just Slackware, though.

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

#26886 — Re: ed

On Wed, 10 Jun 2026 22:01:23 -0000 (UTC), John McCue wrote:

> On Wed, 10 Jun 2026 00:38:51 -0000 (UTC), Lawrence D’Oliveiro 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.

There is no “real single user mode” in any *nix. The concept of
single/multi-user mode is irrelevant to the kernel.

> 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.

You contradict yourself by saying “no file systems are mounted” and
then that “root is mounted RO”. Which is it?

There must *always* be a filesystem mounted on / on every *nix OS
worthy of the name -- surely even the BSDs. On Linux, this is
initially initrd (the “initial RAM disk”) which contains some minimal
code, scripts etc sufficient to find and mount the real root, as
specified in the parameters passed across from the boot loader.

But when switching over, then you can’t just unmount the existing root
filesystem, because after all it is the root filesystem. So you mount
the new root in a temporary directory, and use a special system call
“pivot_root” <https://manpages.debian.org/pivot_root(2)>, to switch
their places around. Now when you unmount the directory where the new
root was previously mounted, it is actually the initrd you’re
unmounting.

As per the man page, pivot_root doesn’t just play a role at boot time,
it is also useful in the setup of filesystem namespaces for containers
etc.

> 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.

On Linux, there is the option to specify the word “single” among the
boot parameters. This is a signal to the init process to pause the
startup of regular services and spawn a shell; if/when this
terminates, it continues with the full startup, including mounting of
non-root filesystem volumes. (Note the kernel itself assigns no
meaning to this boot parameter).

One recent time I tried this, it insisted in asking for the root
password before giving me shell access (could have been just that
distro). But another option that should bypass this is a boot
parameter setting like like “init=/bin/bash” -- this tells the kernel
to run something other than the usual /sbin/init as PID 1. This
disables the normal userland startup process altogether.

But then, you could continue the normal startup with the command
“exec /sbin/init”. Or, of course, terminate the shell, which will
trigger a reboot.

> 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.

Why, do you still keep user directories in /usr?

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

#26892 — Re: ed

On 2026-06-11 02:53, Lawrence D’Oliveiro wrote:
> On Wed, 10 Jun 2026 22:01:23 -0000 (UTC), John McCue wrote:
>>
>>  From what I have seen, seems Linux does not have a real single user
>> mode.
> 
> There is no “real single user mode” in any *nix. The concept of
> single/multi-user mode is irrelevant to the kernel.

Not sure what "real" should mean here. But it's not a question
of whether the kernel generally supports multi-user support.

We certainly had booted Unixes in single-user-mode to operate
administrative tasks, where no other users shall act on the
system. (Wikipedia also mentions that for the "Unix family".)

Janis

> [...]

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

#26878

On 2026-06-09, Koen Martens 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.

ed *is* usable, let's stop this "there are bigger/different programs
available so it has no use now" nonsense, shall we?

If we're going to put ed in that bag, sed should go there too, I
guess. After all, some such "more usable editors" can "replace" sed...

(And if you claim sed is different because it can be used in
automation... can't ed be used that way too?)

-- 
Nuno Silva

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

#26893

On 2026-06-10 12:03, Nuno Silva wrote:
> On 2026-06-09, Koen Martens 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.
> 
> ed *is* usable, let's stop this "there are bigger/different programs
> available so it has no use now" nonsense, shall we?
> 
> If we're going to put ed in that bag, sed should go there too, I
> guess. After all, some such "more usable editors" can "replace" sed...
> 
> (And if you claim sed is different because it can be used in
> automation... can't ed be used that way too?)

This all reminds me the "If all I have is a hammer..." allegory.


Yes, with 'sed' or 'vi' I'm doing different things than with 'ex'
(or 'ed').

Janis

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

#26901

On 2026-06-11, Janis Papanagnou wrote:

> On 2026-06-10 12:03, Nuno Silva wrote:
>> On 2026-06-09, Koen Martens 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.
>>
>> ed *is* usable, let's stop this "there are bigger/different programs
>> available so it has no use now" nonsense, shall we?
>>
>> If we're going to put ed in that bag, sed should go there too, I
>> guess. After all, some such "more usable editors" can "replace" sed...
>>
>> (And if you claim sed is different because it can be used in
>> automation... can't ed be used that way too?)
>
> This all reminds me the "If all I have is a hammer..." allegory.
>
>
> Yes, with 'sed' or 'vi' I'm doing different things than with 'ex'
> (or 'ed').

I use Emacs, sed, ed frequently. The first more than the others, but
this really is like having a set of screwdrivers and picking a somewhat
appropriate one for each screw.



On a smartphone, I've also finally found a good text editor for Android,
it's quite extensible and configurable and for the first time I don't
end up wishing it had some Emacs feature every time I use it.

-- 
Nuno Silva

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

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

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

csiph-web