I don't recall if these boxen were then supposed to act as X-terminals, with only GUI display happening locally, and all execution happening on another box on the network, or if that was its own hey-wouldn't-it-be-cool-to-build-this-useless-but-nifty-thing-I-don't-need kind of project.
The /bin and /sbin directories would be on the boot partition/disk and would contain the programs needed to get to multiuser state.
I still use multiple partitions, even on a 1TB disk.
> The default action, if not overridden by command line options, is to compare the file hierarchy rooted in the current directory against a specification read from the standard input. Messages are written to the standard output for any files whose characteristics do not match the specification, or which are missing from either the file hierarchy or the specification.
It can also be used to create a hierarchy:
I believe Arch takes it further and combines /bin and /sbin (and /usr/sbin) by symlinking them to /usr/bin.
On 16.04 you can usrmerge your system by installing the usrmerge package:
Wait no more, MacPorts installs to this by default.
/opt is for programs that don’t follow any sort of FHS and need to be installed in their own world. Google Chrome and Mathematicia come to mind.
/opt/local makes total logical sense as the counterpart to /usr/local.
> A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store.
[Insert obligatory xkcd quote about competing standards.]
So if bash wants to load up a library, it doesn't say "dearest operating system, please provide me with a convenient version of libdl.so.2". Instead, it says "dearest operating system, please provide me with a convenient version of /nix/store/blahblahblah-glibc-2.27/lib/libdl.so.2".
I do have a profile folder, symlinked as ~/.nix-profile where some programs I've specifically requested to install are symlinked, but that's not sufficient and all encompassing - every program there still refers to the hardcoded /nix/store locations. I guess they also launch programs from $PATH. But I've never seen or heard of a pseudo-FHS nix view of the store.
But on the case of nix, your view is the set of packages you installed. It can not be a full Unix for obvious reasons, and the dependencies are not part of the view (so the packages themselves are not installed in a normal Unix).
I only briefly tried out Nix a while back, but doesn't /usr/bin/env also exist (to facilitate shebangs)?
Edit: No, I’m wrong. /opt/<provider name>/...
b1c4a5629703d4fd.d /usr ffs rw,nodev 1 2
b1c4a5629703d4fd.e /usr/local ffs rw,wxallowed,nodev 1 2
Another fun fact is that execve() (which executes shebangs) only allows a single argument to the shebang program. Meaning if you use '#!/usr/bin/env sh', you can't specify arguments to 'sh' in the shebang. In any case, the name of the file being executed is appended as an additional argument at the end of the shebang.
See also my Stack Exchange answer on the advantages and disadvantages of the "#!/usr/bin/env ..." convention:
The advantage of "#!/usr/bin/env INTERP" is that it will use the first INTERP in the user's $PATH.
The disadvantage is that it will use the first INTERP in the user's $PATH.
You would be correct about that. And that sucks.
If I am writing a script that needs to be that portable, then I'll use #!/usr/bin/env sh but otherwise /bin/sh will work in all the cases I need it to.
Since bash's path might vary more, I might consider calling env to locate it then more often.
I believe that in Solaris before Solaris 10, /bin/sh was the original Bourne shell (which didn't comply with POSIX), and in Solaris 10 it's ksh (which isn't either, but is way closer): https://unix.stackexchange.com/questions/538844/does-posix-g...
Also, I don't think that "#!" is specified in POSIX. It's extremely common, it's just not in the specification. This is similar to find's "-print0" option, which also isn't in the POSIX specification but basically everyone implements it.
If you want a specification of "where things go", the closest one in practice (and one that most modern distributions try to follow) is the Filesystem Hierarchy Standard (FHS): https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
POSIX specifically calls out that it doesn't guarantee that the path is "/bin/sh":
107271 Applications should note that the standard PATH to the shell cannot be assumed to be either
107272 /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by
107273 getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell
POSIX mentions "#!" several times, but doesn't require it; saying things like "on systems that support executable scripts (the "#!" construct)".
As the lack of a hard-codable path is frustrating, it recommends setting the shebang at install-time:
107279 Furthermore, on systems that support executable scripts (the "#!" construct), it is
107280 recommended that applications using executable scripts install them using getconf PATH to
107281 determine the shell pathname and update the "#!" script appropriately as it is being installed
107282 (for example, with sed). For example:
For example, on my (Mac) laptop, /bin/bash is bash 3.2.57 (released in 2007), while "/usr/bin/env bash" gets the version installed by homebrew which is 4.4.19 (released in 2016).
Eventually though the new programs started pushing up against the limits of the PDP-11. I propose that virtually anything that seems like magic in Unix or C, from filesystem organization to page sizes, traces its origin directly back to the PDP-11.
We are still living in the world of microcomputers, no matter how far we may seem to have ventured away.
And according to Dennis M. Ritchie, the B language that preceded C was also first implemented on the PDP-7, whose auto-increment memory cells "probably" inspired Ken Thompson to create B's ++ and -- operators.
My system does it like this.
/bin - static linked basic user commands
/sbin - static linked system commands (incl. important daemons)
/usr/bin - dynamic linked user commands
/usr/sbin - dynamic linked system commands and system daemons
/usr/local/bin - user commands installed via package
/usr/local/sbin - system commands installed via package
So, I suppose it's really both. The statically linked shell would allow you to upgrade the shared libc, for example. Which is both "system" and "static" related.
edit: Clearly I'm missing something in the linked article because I'm being downvoted. Could someone show me what I'm missing?
I don't know what the correct historical explanation is. "s" like in super user, system program or statically linked or is there yet another theory?
"Understanding the split between (/bin, /sbin, /lib) and (/usr/bin, /usr/sbin, /usr/lib)"
Not perfect but maybe clearer
So sbin is reserved for system binaries concerned with booting, administrative tools, repairing/restoring (the system), and the like.
Since these essential utilities by their very nature require superuser privileges, it's tempting to think that sbin simply means "superuser binaries" or something.
Someone else mentioned "statically linked", which is also true, but again just a side-effect of being for system programs. The programs in sbin need to be able to run without /usr, /lib, or /bin being mounted or even existing is the idea here.
To me personally - and this is just my uniformed(!) opinion - the only split that makes sense across all circumstances is /bin vs /sbin and /var vs /.
Simply because anything but /var could safely be considered read-only, while /var exists explicitly for writable data ¯\_(ツ)_/¯
Platform-specific files are stored in /$architecture and binaries in /$architecture/bin. Shell scripts are stored in /rc/bin. For the home directory, traditionally, this style is reversed so your shell scripts would be in $home/bin/rc.
The namespace for any process can be enumerated, so in my default shell, I can see which directories are currently bound (and how) on /bin:
tenshi% ns | grep 'bind' | grep '/bin'
bind /amd64/bin /bin
bind -a /rc/bin /bin
bind -b /usr/seh/bin/rc /bin
bind -b /usr/seh/bin/amd64 /bin
bind -a /sys/go/bin /bin
bind -a /usr/seh/go/bin /bin
It's like having fond memories of Hillary Clinton's inauguration speech.
I don't think “vapourware” means what you think it means.
To elaborate, the comparison with an alternative universe is
silly, since there are actually papers that people can read and there is
actually code that people can use. So saying that “it never happened”
I'd say it's closer to the DMC DeLorean: short production run, works but has short comings, more of a meme than an actual commodity.
It's not vaporware though, they definitely delivered something that works. It's just that there wasn't a good reason to use it compared to other options.
Also, gobolinux tries to mimic this behavior as well.
(Links for the curious. Reposts are ok after a year: https://news.ycombinator.com/newsfaq.html)
I consider it to be a warning about the importance of refactoring and renaming things sooner rather than later, because the longer that something sticks around, the more dependencies it develops and the harder it is to change.
I put this page into Firefox's reader mode and I get lines breaking all over the place as it's now got a mix of soft and hard line breaks.
Should presentation of line length not be up to the client?
This email would display at full-width in a client that respects format=flowed (many modern email readers, except for, notably, Outlook and Gmail). But as others have pointed out, this is literally just the plain text of the email wrapped in a <pre> tag, so you get the hard line breaks.
But as someone who has bash aliases for extracting text from a website so I can read it in my terminal (or page it with `less -r`), yes, this is something that bugs me too.