That said, Posix by itself isn't enough, and this was the next most -comprehensive standards effort for Linux so far, so we salvage what we can. +
Posix by itself isn't enough, and this was the next most +comprehensive standards effort for Linux so far. A lot of historical effort went into producing the standard before the -Linux Foundation took over.
+Linux Foundation took over. But LSB was much more prominent when toybox +started, and is now noticeably obsolete. The main reason it hasn't +been removed is toybox command implementations are sorted into directories +(which become menuconfig sub-menus) and moving toys/lsb/*.c elsewhere means +you'd have to say git log --follow to see the history. The churn probably +isn't worth it, despite LSB's modern irrelevance.Where posix specifies one of those commands, LSB's deltas tended to be -accomodations for broken tool versions which ween't up to date with the +accomodations for broken tool versions which weren't up to date with the standard yet. (See more and xargs for examples.)
@@ -272,44 +277,50 @@ su sync tar umount useradd userdel usermod zcat -They're very nice, but there's thousands of them. The signal to noise -ratio here is terrible, and neither is a good indicator of whether a linux -system should or should not include a given command in its basic command set.
- -Discussion of standards wouldn't be complete without the Internet -Engineering Task Force's "Request For Comments" collection and Michael Kerrisk's -Linux man-pages project... -except these aren't standards, they're collections of documentation with -low barriers to inclusion. They're not saying "you should support -X", they're saying "if you do, here's how". -Thus neither really helps us select which commands to include.
- +Unix's first production deployment in 1970 was a typesetting system for -AT&T's internal patent and trademark licensing office (providing the +AT&T's internal patent and trademark licensing office, providing the budget for Bell Labs' engineers to port their prototype system from a -surplus PDP-7 fished out of an attic to a newly purchased PDP-11), and +surplus PDP-7 fished out of an attic to a newly purchased PDP-11. Unix has retained a robust documentation tradition ever since, albeit still written in the old "troff" typesetting language designed to control 1970's daisy wheel printers, and in a terse style intended to save both memory and paper. Still: every command in a descendant of unix should have an -entry in the unix instruction manual, with section 1 (ala "man 1 ls") listing +entry in the unix instruction manual, with +section 1 +(ala "man 1 ls") listing commands available to normal users and section 8 ("man 8 mount") listing system administration commands for use by the root account. Run "man -k ." to see every manual page currently installed onthe system.
-The modern Linux man pages project has loosened up a bitwebsite includes commands from git, yum, perf, postgres, -flatpack... It's useful for examining the features of a command you've -already decided to include, but useless for deciding _what_ to include.
+The modern Linux man pages project is maintained by +Michael +Kerrisk and Alejandro Colomar. +I've never looked at the PDF version, but the website includes commands from +git, yum, perf, postgres, flatpack... It's useful for examining the features +of a command you've already decided to include, but useless for deciding +_what_ to include.
-The RFCs are mostly about protocols and file formats, not commands. +
The Internet Engineering Task Force's "Request For Comments" collection +started when the early internet pioneers wrote up documentation and proposals +about the network they were building, and a man named Jon Postel collected +and archived them (until his death in 1998 when a committee took over). The documents are numbered based on the order they were received, with no real attempt at coherently indexing the result. -The noise level is also extremely high: there's thousands of RFCs, many -describing a proposed idea that never took off, and most of the rest are -extensions to or replacements for earlier RFCs. Less than 1% of the resulting +As with the man-pages, they're very nice, but there's thousands of them, +the signal to noise ratio here is terrible, and nothing here is a good +indicator of whether a linux system should or should not include a given +command in its basic command set. This is another collection of documentation +with a low barrier to inclusion. They're not saying "you should support +X", they're saying "if you do, here's how", which does not +help us select which commands to include.
+ +RFCs are mostly about protocols and file formats, not commands. +The noise level is extremely high: there's thousands of RFCs, many +describing a proposed idea that never took off, most of the rest are +extensions to or replacements for earlier RFCs, and even a few April Fool's +entries. Less than 1% of the resulting documents are currently relevant to toybox. As with man pages they can be long and complicated or terse and impenetrable, @@ -323,10 +334,10 @@ and excellent documents have no obvious modern alternative.)
-That said, RFC documents can be useful (especially for networking protocols) -and the four URL templates provided by the recommended starting files -for new commands (hello.c and skeleton.c in the toys/example directory) -point to example posix, lsb, man, and rfc pages online.
+That said, RFC documents can be useful (especially for networking protocols +and data compression/archive formats) and the four URL templates provided by the +recommended starting files for new commands (hello.c and skeleton.c in the +toys/example directory) point to example posix, lsb, man, and rfc pages online.