On the contrary. Given today's disk sizes, I think man pages should be stored inside executables, in a special section of the executable that doesn't get loaded when the executable is loaded. That makes it easier to keep executable and man page in sync, and would allow us to (eventually) get rid of the man page directories for non-programmers (there are some issues to solve here for zip/unzip, busybox and the like, but I think thise are surmountable. Also, users running with small disks could strip such sections from binaries)
I also think there should be another data section in each command-line program that contains an abstract layout of a dialog for entering arguments, as was customary in Macintosh Programmer's Workshop (http://en.m.wikipedia.org/wiki/Macintosh_Programmer%27s_Work...).
Shells could use that layout to make it easier for users to enter lesser used commands or command options. Some shells would use curses to layout these dialogs, others would choose to use a 'real' GUI. Alternatively, separate tools would be written, and shells would use a COMMANDO shell variable to pick the one the user prefers.
I think that the code to handle versioning and help text (except a brief usage message, which is often useful) shouldn't be included in each binary.
I agree that help text should be the purpose of the manpages.
A version number (or pointer to version string) could be one of the fields in the file header, to be read by a tool ("version"?) and displayed that way.
This way you still get versioning and documentation, without a massive duplication of functionality across every single binary.
Comments
Here's a link to the coreutils source for true if anyone's interested:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/true...
I think the argument can be made that command lines tools shouldn't provide versioning and help text at all - leave it up to the manual pages.
On the contrary. Given today's disk sizes, I think man pages should be stored inside executables, in a special section of the executable that doesn't get loaded when the executable is loaded. That makes it easier to keep executable and man page in sync, and would allow us to (eventually) get rid of the man page directories for non-programmers (there are some issues to solve here for zip/unzip, busybox and the like, but I think thise are surmountable. Also, users running with small disks could strip such sections from binaries)
I also think there should be another data section in each command-line program that contains an abstract layout of a dialog for entering arguments, as was customary in Macintosh Programmer's Workshop (http://en.m.wikipedia.org/wiki/Macintosh_Programmer%27s_Work...).
Shells could use that layout to make it easier for users to enter lesser used commands or command options. Some shells would use curses to layout these dialogs, others would choose to use a 'real' GUI. Alternatively, separate tools would be written, and shells would use a COMMANDO shell variable to pick the one the user prefers.
I'd have a real hard time agreeing with that. But I could make an exception for /bin/true.
I think that the code to handle versioning and help text (except a brief usage message, which is often useful) shouldn't be included in each binary.
I agree that help text should be the purpose of the manpages.
A version number (or pointer to version string) could be one of the fields in the file header, to be read by a tool ("version"?) and displayed that way.
This way you still get versioning and documentation, without a massive duplication of functionality across every single binary.
Also worth looking at is false.c, which is considerably shorter: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/fals...
That seems to be ~70 lines of code, not the 2k+ claimed by the article. Is he including statically linked libraries as well?
edit: Ah, I see he meant bytes, but mislabeled the graph.