Decoded: GNU Coreutils

http://man7.org/linux/man-pages/man3/fts.3.html

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src

and some of their current decedents:

https://svnweb.freebsd.org/ http://cvsweb.openbsd.org/cgi-bin/cvsweb/ http://cvsweb.netbsd.org/bsdweb.cgi/src/?only_with_tag=MAIN https://gitweb.dragonflybsd.org/dragonfly.git

conveniently all in one source tree, self hosting, and buildable with a single command.

it is almost as if they were designed as part of a single coherent operating system along with the very C language itself..

as discussed previously, typically with more intelligible sources:

https://news.ycombinator.com/item?id=14542938

and usually with better man pages (https://www.freebsd.org/cgi/man.cgi)

unix came first. gnu and posix came later.

the unix way is the standard, not posix, and not gnu.

from stallman himself (https://stallman.org/articles/posix.html):

" It seemed to me that nobody would ever say "IEEEIX", since the pronunciation would sound like a shriek of terror; rather, everyone would call it "Unix". That would have boosted AT&T, the GNU Project's rival, an outcome I did not want. So I looked for another name, but nothing natural suggested itself to me.

So I put the initials of "Portable Operating System" together with the same suffix "ix", and came up with "POSIX". It sounded good and I saw no reason not to use it, so I suggested it. Although it was just barely in time, the committee adopted it. "

so, as can be seen, posix is RMS's way of keeping people from calling unix unix, and as a result today, now that AT&T Unix is nearly dead, people lose track of the fact that BSD is Unix, and don't know what Unix actually is, and are forced to 'decode' the sometimes deliberately less clear cloned sources not knowing to look at the simpler original.

"This resource is for novice programmers exploring the design of command-line utilities. It is best used as an accompaniment providing useful background while reading the source code of the utility you may be interested in. "

^ "best used as an accompaniment"

I posit that GNUs intentionally obfuscated code design[1]^ requires the use of such a site, whereas, reading the originals and their decedents, provides a similar level of understanding program functionality in addition to the actual historical context in which most of the tools were developed and, also, typically occurs in the same source tree as the kernel, c library, and build toolchain implementing the OS side of the equation and so is a better and more productive thing to do with one's time that will still apply to reading and understanding coreutils sources.

apologies if unclear. but kudos to the author for trying to do something positive to spread knowledge of system internals, lest I be misconstrued.

.. [1] https://www.gnu.org/prep/standards/standards.html#Reading-No...

.. ^: the design of a utlity like 'cat'+ has generally obvious direct implementation. coming up with something else to be different necessitates doing goofy stuff. see also other hn thread referenced.

.. +: see also: https://github.com/coreutils/coreutils/blob/master/src/cat.c vs https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/ca...

I also conclude the opposite from the cat implementations. I really don't see how the BSD cat is a more "pure" or straight forward implementation. I find the GNU cat to have way more options and easier to read source code. My guess is that novice programmers would find the GNU version easier to grok, which also probably aligns more to the goal of GNU. Or I just like to read obfuscated code.

Way more options is "cat -v considered harmful" not thought any more?