The growth of command line options, 1979-Present
The first of McIlroy's dicta is often paraphrased as "do one thing and do it well", which is shortened from "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new 'features.'" [ . . . ]
If you open up a manpage for ls on mac, you'll see that it starts with
ls [-ABCFGHLOPRSTUW@abcdefghiklmnopqrstuwx1] [file ...]
That is, the one-letter flags to ls include every lowercase letter except for {jvyz}, 14 uppercase letters, plus @ and 1. That's 22 + 14 + 2 = 38 single-character options alone.
On ubuntu 17, if you read the manpage for coreutils ls, you don't get a nice summary of options, but you'll see that ls has 58 options (including --help and --version).
To see if ls is an aberration or if it's normal to have commands that do this much stuff, we can look at some common commands, sorted by frequency of use.
(see article for interesting table.)
We can see that the number of command line options has dramatically increased over time; entries tend to get darker going to the right (more options) and there are no cases where entries get lighter (fewer options).
Everything was small and my heart sinks for Linux when I see the size [inaudible]. The same utilities that used to fit in eight k[ilobytes] are a meg now. And the manual page, which used to really fit on, which used to really be a manual page, is now a small volume with a thousand options... We used to sit around in the UNIX room saying "what can we throw out? Why is there this option?" It's usually, it's often because there's some deficiency in the basic design -- you didn't really hit the right design point. Instead of putting in an option, figure out why, what was forcing you to add that option. This viewpoint, which was imposed partly because there was very small hardware ... has been lost and we're not better off for it.
[ . . . . ] Another reason commands now have more options is that people have added convenience flags for functionality that could have been done by cobbling together a series of commands. These go all the way back to v7 unix, where ls has an option to reverse the sort order (which could have been done by passing the output to tac).
Over time, more convenience options have been added. For example, to pick a command that originally has zero options, mv can move and create a backup (three options; two are different ways to specify a backup, one of which takes an argument and the other of which takes zero explicit arguments and reads an implicit argument from the VERSION_CONTROL environment variable; one option allows overriding the default backup suffix). mv now also has options to never overwrite and to only overwrite if the file is newer.
mkdir is another program that used to have no options where, excluding security things for SELinux or SMACK as well as help and version options, the added options are convenience flags: setting the permissions of the new directory and making parent directories if they don't exist.
[ . . . ] unlike with a GUI, adding these options doesn't clutter up the interface.
(emphasis added)
No worry, systemd will guide us back to the true Unix Microsoft way.
(Score: 2) by NotSanguine on Wednesday March 04 2020, @11:51PM (2 children)
If I'm not scripting, it's irrelevant, as I'll confirm the results manually.
If I am scripting, something like
tar cf - foo 2>script.log |bzip2 -9 > foo.tar.bz2 2>>script.log
If the process is automated, there should be a log, and a responsible party (or a script) should be checking that log, no?
As such, something similar should do the trick.
Alternatively, using the integrated compressor would work just fine too.
That's one of the nice things about *nix, there's never just *one* way to do things. If I want to use a compressor that's not supported by tar, I can do that too, if I want.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0) by Anonymous Coward on Thursday March 05 2020, @09:01PM (1 child)
This (or a variant thereof) is a reasonable approach to solve the problem. In fact the "portable posix shell" way of getting the exit status of earlier commands is essentially to do just that -- each command in the pipeline must squirrel away the pass/fail status somewhere, so that the script can check the command status afterwards.
In the above pipeline, the script.log file is opened twice: once in regular mode and once in append mode. This is going to produce interesting (i.e., corrupt) results if both commands print errors because the file position is not shared between the two processes.
The above pipeline as written will not record any error whatsoever if "tar" is killed by a signal, so there will be no way to detect if that happened by looking at the log file.
Dealing with all of this makes scripts substantially more complex than just using an integrated compressor. Since tar is very frequently used with compressors, it makes a lot of sense to integrate commonly-used compressors into "tar" itself so these problems can all be solved in one place (in tar) rather than having to deal with this issue in every single script that ever uses tar.
And that is why I consider integrated compressor options to be a good addition to the "tar" utility.
(Score: 2) by NotSanguine on Thursday March 05 2020, @10:22PM
I shan't disagree, as you make lots of sense.
Rather I'll just reiterate that it's good that there's always more than one way to do things in *nix.
No, no, you're not thinking; you're just being logical. --Niels Bohr