Slashdot Mirror


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? "

3 of 23 comments (clear)

  1. The Amiga approach by Matts · · Score: 3

    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.

    --

    Matt. Want XML + Apache + Stylesheets? Get AxKit.
  2. By now the value of changing is low by Chris+Siebenmann · · Score: 3

    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.

  3. It *is* being done by Enervator · · Score: 3
    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.