> 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, whi

> 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. Perhaps, but, also, on a source based unix system (i argue the only real unix system, since this is what unix was from the v5 research days, and continued to be for source license holders through the dawn of PC-BSD and then in open-source BSD onwards), one can do something like this: $ which ls /bin/ls $ man ls > /dev/null # output hidden for example purposes $ ls /usr/src/bin/ls CVS cmp.c ls.1 ls.h obj utf8.c Makefile extern.h ls.c main.c print.c util.c $ grep include /usr/src/bin/ls/ls.c |sed -ne 2p #include <sys/stat.h> $ ls /usr/src/sys/sys/stat.h /usr/src/sys/sys/stat.h $ grep ^sys_statfs /usr/src/sys/kern/*.c /usr/src/sys/kern/vfs_syscalls.c:sys_statfs(struct proc *p, void *v, register_t *retval) $ less /usr/src/sys/kern/vfs_syscalls.c # oh so that's how it works in the kernel.. $ (cd /usr/src/bin/ls && cp ls ls.c.orig && $EDITOR ls.c && make && make install && ls -Q) # yay! my new option -Q works $ (cd /usr/src/bin/ls && diff -urw ls.c.orig ls.c |Mail -s 'new patch' developers@some-mailing-list.org) whereas, for example, on a binary package based linux or proprietary UNIX, this would entail either separate download of N different tools and disparate compilation steps in the former, or not being able to do it in the latter. While there is nothing constraining a linux or proprietary unix from being made available in such a way, they quite simply arent, and the 'culture' and concept of having a single binary+source+documentation tree which is fully self hosting with a single build system managing the build combined as a single unit as 'what the unix system is' is lost..