zlacker

> Also /bin vs /sbin believe is that the latter is meant for statically linked binaries such that if your system is corrupted these at least will keep working.

My understanding is that sbin for system binaries, not necessarily statically linked. Normally /sbin is only in root's PATH, not normal user's. They are likely world executable, but in many cases you cannot actually run them as non-root since they usually touch things only root can access without special access (e.g. raw devices, privileged syscalls, /etc/shadow etc.). Not always though, like you can run /sbin/ifconfig as normal user in read-only mode.

>>buzer+(OP)
The s in sbin stood for static initially. Of course nowadays this is not enforced.

>>IgorPa+O9
What is the source for that? Some of the oldest references to sbin I can find are 4.3BSD Net/2 man pages (https://man.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sek...) and Filesystem Standard v1.0 (https://www.ibiblio.org/pub/Linux/docs/fsstnd/old/fsstnd-1.0...). Former doesn't mention anything about static binaries, latter only mentions that static ln (and even mentions sln being static version of ln) and sync can be useful.

>>buzer+4g
There are no contemporary sources for that because it is, as it was called here on Hacker News some years ago, an 'ahistoric retcon'.

* >>31338349

The 's' is for 'static' version of the explanation of the name of sbin is not actually supported by any 20th century Unix doco. The books on AT&T Unix System 5 (before which, things were in /etc) that actually give an explanation for sbin all say system binaries, or system administration commands; and none of them says anything about linkage.

The 'static link' story came from Linux people years afterwards. Here's Ian McCloghrie correcting this misconception in a Linux discussion back in 1993:

* https://groups.google.com/g/comp.os.linux.development/c/EKzL...

I pointed out the origins of sbin some years ago.

* https://lists.debian.org/debian-user/2019/02/msg00041.html