11–20 of 30 posts
Earlier quoted context omitted.
If all programmers did what you are doing, we would not have the problems we do. I hope someone gives you a medal and merit badge and a cookie. [1] have begun
Agreed; I now always run a minifier before committing.
Reducing lines doesn't matter. Reducing logic is what matters.
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.
I'd have a real hard time agreeing with that. But I could make an exception for /bin/true.
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.
edit: Ah, I see he meant bytes, but mislabeled the graph.
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.
> 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.
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.
http://www.youtube.com/watch?v=jB0vBmiTr6o
There's more here: http://www.pouet.net/prodlist.php?type[]=4k
The demoscene is basically the exact opposite of mainstream software culture, and although it's focused on multimedia shows, I think some of their techniques and underlying motivation could be applied more generally...
I wonder if /bin/true and /bin/false in their most simplest forms even meet the minimum "requirement for creativity" to be copyrightable, and if the reason why it has bloated significantly is so that it could be.
I created an empty file, a la the original true, named truth and placed it at the beginning of my $PATH.
$ time truth
real 0m0.002s
user 0m0.000s
sys 0m0.003s
$ time /usr/bin/true
real 0m0.001s
user 0m0.000s
sys 0m0.000s
$ time /usr/local/sbin/truth
real 0m0.003s
user 0m0.000s
sys 0m0.000s
$ time true # The builtin
real 0m0.000s
user 0m0.000s
sys 0m0.000s
This post is not intended to be a serious performance comparison.
"OMG, /bin/sh increased in size by 191x from 1974 to 2015!" seems like the byte-counting equivalent of people who lose their minds about "YOUR FOOD HAS CHEMICALS IN IT WITH COMPLICATED NAMES!". Both sound impressive and might make you worry - and both omit important facts that would greatly reduce that effect. For instance, 191x growth since 1974 seems steep until you realize that the corresponding storage has grown…
The original 486 had 8kb of L1 cache. My laptop now has (2x)32k.
So, I found this very interesting to read. I created an empty file, a la the original true, named truth and placed it at the beginning of my $PATH. $ time truth real 0m0.002s user 0m0.000s sys 0m0.003s I then realized that since true is a builtin, I'd need to call the true binary with its full path. I'd hate to give one an unfair advantage by having to search the path vs being called by name. So.... $ time /usr/bin/t…
$ time /usr/bin/true
real 0m0.003s
user 0m0.001s
sys 0m0.002s
$ time /usr/bin/truth
real 0m0.001s
user 0m0.000s
sys 0m0.001s
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.
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.