Why Can't the Command-Line be More Standardized?

dschl asks: "Just because something does not appear to be broken, is no reason to leave it the way it is. Unix has been developed over the course of decades, and has several inconsistent legacy commands, for tools developed by different people at different times. I get tired of hearing some long-term unix users just tell newbies to "RTFM", and complain about how people do not want to use the command line. As a relative newbie, I have an problem with this: the command line is a *itch to learn. Once, when upgrading to a newer version of Gnome, I had to check (and upgrade) a dozen libraries. A part of life, and that did not bother me. However, a different flag argument was required to check each version number - this ranged from -v, -V, --V, -version, and so on. Why can't the following be done: have a standardized superset of flags for the most common and widespread options, such as verbose (-v), version (-V), recursive (-r), all (-a), force (-f). This could lead to a brutal transition period for those who use command line every day, but would ultimately make the command line more accessible (by lowering the learning curve, which would make it easier for people to see what a useful tool it really is). This would have to be a limited superset, in order to allow for a full range of non-common flag options for all commands. Would this be feasible / possible? Would it be worthwhile? "

Comments

Re:Maybe....

[BrianUofR]

*NIXes aren't tougher than any other OS-- they just require a different mentality. One company doesn't control the entire market. *NIX is the end result of thousands of code hackers' work over the course of several deacades of use. We all have the ability to improve on an app when we think we can do better. This has good and bad results- Good: they evolve quickly, they are scalable and rock solid due to the continuous decentralized development, and bug fixes occur quickly. The bad part is that its not like Windows- it is not uniform and consistent from one distro to another. I'd rather buy the O'Reilly book and master a few esoteric commands than be forced into doing it ONE way. I'd rather have the luxury of being able to develop a solution for my needs than have that right taken away with reverse engineering copyright laws all for the convenience of a consistent interface.

The Amiga approach

[Matts]

Even better was the approach the Amiga took. It had standardised on a single library to parse all command lines, and allowed you to always know how to get at least the list of arguments to a particular command. It told you the names of parameters, whether they were mandatory or optional, the type of a parameter (e.g. number, filename, etc) and so on. Made life very easy for command line users.

Sadly I think there's too many tools out there that you just couldn't change now - even if you tried. Take perl for example. I'm willing to bet you wouldn't get -v to be changed from "brief version" to "verbose" because it has no meaning in perl.

By now the value of changing is low

[Chris Siebenmann]

This might have been something that could have been done when Unix had few users. By now there is almost certainly too much water under the bridge to make it worthwhile to switch; the cost in pain and breakage would far exceed the gains.

Why's it so painful? Because switching the meaning of existing command-line switches means more than existing Unix users having to change their habits. It means that all existing uses of these commands have to change: from shell scripts to things embedded in Makefiles. That's a lot of work, especially since you pretty much have to look at everything, every script and Makefile, to make sure that it's still OK.

Worse yet, you're highly unlikely to get a majority of people to switch at the same time. This means that portable scripts, Makefiles, and users have to cope with having it both ways, which just increases the pain even more.

Standardising options: the cons

[tartarus]

There are two main problems that I see here. Actually, one is only relevant because of the other.

If you standardise short options (-h et al), you've effectively locked them out for programs that don't need them. Okay, so everything should support help and version requests - but not everything has a use for -a to mean 'all', or -r to mean 'recurse'. If I don't need a recursive option, but I have an 'open read-only' option, I can't use -r to select it - the short options become less easy to remember. And there are only a limited number anyway (I'm generally opposed to having -V and -v, for instance, doing different things - it's easy to forget which is which).

The other issue is that of deciding on the list of standard options. This isn't such a big problem if you're standardising on long options - saying that --help, --version, --recursive, --all, --reverse, and so on are standard words to use to identify certain actions/options is fine. I don't think it would really make life any easier (most GNU applications using reasonably standard naming of their long options), because most people prefer to use short options.

Just my views ...

It *is* being done

[Enervator]

Why can't the following be done: have a standardized superset of flags for the most common and widespread options, such as verbose (-v), version (-V), recursive (-r), all (-a), force (-f).

The GNU Project does define such a set of standard options for long options such as --verbose, --version, etc. Of course, there's no hope of completely standardising the wild array of differing interpretations of short options. As others have said: that's fine; trying to do it would constraint lots of utilities, annoy lots of people, and take away some of the fun! :-)

[Someone else:]
Even better was the approach the Amiga took. It had standardised on a single library to parse all command lines, and allowed you to always know how to get at least the list of arguments to a particular command.

GNU short and long options are always (by sane programmers anyway!) parsed using the getopt_long library routine. Potentially one day someone will get around to integrating this with readline in some way to get option completion and lists of arguments and all the good stuff the dear old Amiga had.

And what about backward compatability?

[DrWiggy]

OK, so we now change all of the flags passed to applications that were in use when you were still in short pants, and everything will break. But that's OK, because at least you know why it's broken. :)

As an example, you specified -f to mean 'force'. OK, so we'll change that, and then every time I want to tar/untar something I'll just have to do it a tape device, as I can't specify the file. :)

To be honest, although I can see why standardisation around the kiddies flags (--version and so on) is useful, I really don't see the pain in typing 'man cmd' to find out what 'cmd' does and what flags it takes. If people aren't prepared to accept that, I suggest that they have chosen the wrong OS, and should think instead about something 'easier' to learn such as MacOS or Windows.

I honestly think that if you want to fight the cause of usability in unix environments, you should be pushing for standardisation of X apps that should all carry some sort of familiarity in them (we've all seen the File/Edit/View standard of Windows). This is less likely to break things from a backwards-compatability front, is going to appeal to those that need it (the sort that will want to work exclusively in a windowed environment), and could still be done before it's too late! :)