SoylentNews is people
SoylentNews
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: 3, Insightful) by Anonymous Coward on Wednesday March 04 2020, @05:02PM (2 children)
The first UNIX man page I ever seriously studied was fsck(8). The provided an excellent context for my future studies because almost everything else I studied was simple in comparison to fsck(8) and some of the other early UNIX commands.
As a systems administrator, I am something of a connoisseur of the command line. I've managed dozens of different SunOS and Solaris releases, BSD, DEC's Digital Unix, two or three attempts at porting UNIX to the Apple architecture, HP-UX from 7.0 through 11.3 or so, hundreds of Linux releases, IBM's POSIX-compliant releases, etc, etc, etc.
Much of the bloat comes from Linux. Other operating systems that are in the hands of vendors receive changes judiciously. They have a population of customers to whom they are responsible for maintaining interoperability with past versions. But Linux is wild and free - every semester there is a new crop of brand new commands that do the same thing as the old commands and, to add insult to injury, a lot of them are shell scripts, calling previous semesters' shell scripts, calling previous semesters' shell scripts, calling an executable somewhere that someone who knew what they were doing, wrote, a long time ago.
Consider apt(1). A perfectly good command line tool that spawned four or five or six or ten different tools that all call apt(1) to do any real work. Why not just learn how to use apt(1)?
Consider all of the package managers out there. They all do the same thing. They are all basically tar(1) with some fluff added. Why not just use tar(1)?
I think it's Raspian that has some sort of wireless access control manager. It's a command line utility. It promises more than it actually can deliver at this point in time and I think some of the command line options actually don't even work. But that hasn't stopped creeps from grabbing it and slapping GUIs on to it and coloring it pink and writing up articles about how great it is and posting Youtube videos prominently showing their names and faces - even though the fucking thing doesn't work.
Much of this is driven by ego. One's chances of getting hired and promoted are much better if one is seen to be a purveyor of the magic "Open Source", never mind that one's open source is a shell script that steals all of its brains and muscles from other programs, and that one's shell script is, basically, makeup - a skin, if you prefer - and nothing more.
So, basically, Silicon Valley is in the hands of people who got hired for their ability to sell themselves and their willingness to steal other peoples' creations, file off the serial numbers, and claim credit for it.
Been that way since about 2000 or so. It was starting to get bad in the 1990s.
I know there are real kernel driver programmers out there - but they are almost surely flipping burgers, because they can not compete with polished Indians and lying college graduates, and cannot hold the attention of the yuppie managers.
So it goes. Call me if things change.
~childo
(Score: -1, Offtopic) by Anonymous Coward on Wednesday March 04 2020, @09:43PM
When people can't marry adorable young girls, all that's good in life is money.
(Score: 0) by Anonymous Coward on Wednesday April 01 2020, @12:38AM
The reason for the package managers are there to parse the metadata of the package on top of getting tar to unpack its content. This so that a package can later be removed without leaving stray files everywhere.
And frankly i don't mind this, as it means that during everyday use my life is automated. But i can still fall back to the coreutils when shit goes sideways.
This in contrast to say RPM that uses a bespoke format.
And was not the initial concept of unix that of wrapping assorted binaries in shell scripts?