News for hackers. Stuff that matters.
Re:Code Inflation [pdf] by matthewbauer on Friday April 17, 2015 @04:51PM (#9397133)
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.

Re:Code Inflation [pdf] by Someone on Friday April 17, 2015 @11:42PM (#9398236)
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.

Re:Code Inflation [pdf] by wyldfire on Friday April 17, 2015 @08:00PM (#9397825)
> 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.

I'd have a real hard time agreeing with that. But I could make an exception for /bin/true.

Re:Code Inflation [pdf] by userbinator on Friday April 17, 2015 @09:11PM (#9397988)
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.

Re:Code Inflation [pdf] by kardos on Saturday April 18, 2015 @04:41AM (#9398755)
Also worth looking at is false.c, which is considerably shorter: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/fals...
Re:Code Inflation [pdf] by Tossrock on Friday April 17, 2015 @08:13PM (#9397859)
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.