Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
News

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

Posted by Cliff from the stuff-to-think-about dept.
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? "
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:
  • *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.
  • Change the QWERTY key layout, that's basically 'broken' as well.

    Sure, lots of typists will have a hard time, but that won't stop them, right? :-)

    -John

  • The Amiga approach (Score:3)

    by Matts ( 1628 ) on Tuesday January 25, 2000 @04:54AM (#1339447) Homepage
    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.
  • While you're standardizing flags, I'd propose that -n be standardized like make does it: don't actually do anything but instead tell me what you'd do. Granted this would be meaningless for information-only utilities that don't actually change things, but it would be nice to have on all other utilities. That way you could run your find | rm -rfn and find out what all actually would be removed before rerunning sans -n, for example.

  • We were all newbies once (expect the people who were not). This still applies to some people who have been using Unix for a long time. From my experience, reading the fine man page has given me a new insight into how the command works. Of course there are really bad man pages, but on the average, man pages are Informative, Interesting, Insightful, and sometimes even Funny. As well as getting the run-down on the command in question, the man page (sometimes) lists related commands. When I was a newbie, knowing only about 5 commands and none of them well, man would uncover a new, possibly useful, command that occasionally helped me but generally just made me feel more comfortable with my system. For example, I always wanted to log the output of, say, make, but also be able to see it at the same time. less can sometimes do this for me, but I discovered tee, a command specifically designed for this purpose, by following the related commands on many different man pages.

    For the AC: I would have moderated you up but I already used too many points in this discussion. Consider this a hint for any lazy moderator.

    Kenneth

  • well its not really a true analogy, all QWERTY keyboards are basically the same\ with a few function and special purpose key changes but the letters are in the same place. however the issue is that different programs have different ways to show certain bits of info.

  • By now the value of changing is low (Score:3)

    by Chris Siebenmann ( 14014 ) on Tuesday January 25, 2000 @08:53PM (#1339452)

    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.

  • 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 ...
  • Doesnt matter if the verbose option has a meaning in Perl or not. With standarized (does that word exist?) options and a reasonable amount of time, -v wouldnt exist, just -V.

    The main point here is that options being standard is a major help to those clueless newbies, and not only to them. I hope the effort GNU is doing bout that concludes with success.
  • true, but there's also dvorak and numerous chord key layouts, all of which are clearly better, and most owners of them will happily tell you this (me, I don't own one..)

    -John
  • I mainly agree with you. But does it hurt too much to have, let say, a dictionary of short options?. Yes, you could say that if I have the time to waste on making a dictionary, better work on the development of X. And yes, you're damn right!. :-)

  • It *is* being done (Score:3)

    by Enervator ( 87567 ) on Tuesday January 25, 2000 @11:32AM (#1339457)
    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 [gnu.org] 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.
  • cli is known for its compact form, as are many components of the unix OS (directory structure, for instance). In the hand of a skilled user (and probably with a good shell/emacs client), cli flies. Resorting to standardized interface would probably introduces unnecessary complexities to what's fundamental: efficiency in expression. Take the flags as examples: they are like prepositions. We call down a disobedient student, we call off a trip, but we put down important things in a notebook, and we put off doing homework until the last minute. See, much of a language's richness lies in the very flexibility in conveying alot of things with just a few words.

    HFF

  • If the set of "required" switches were suitably chosen, applications could keep all their old switches and just add new ones. No need to change what the old ones mean.

    Since the original switches are unchanged, there is no need to any scripts or makefiles that use them.

    No ones toes should be stepped on if the standard switches are along the lines of "---STDVersion", "---STDHelp", and the like. If a switch is not applicable, return an error.

    This would make compliant software a bit more friendly to unfamiliar users. I, for one, wasted a bit of time figuring out how to request version info last time I tried a kernel upgrade.

    -sig-

  • How about standardizing the representation of command lines in short form to indicate which option is optional and which is not or which one takes an argument/arguments and which does not or which options exclude each other.

    e.g. prog [ -a | -b ]

    is a widely accepted to mean that prog takes option -a or -b and not together. How about extending this for multiple option cases like -a can occur with -b and -c, -b can occur with -d and -a etc. I had need to do this recently to standardize the reading of meaning of those options across multiple departments of our company. Is any work being done on it anywhere?

  • 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! :)
  • Well, it wouldn't hurt, but yes there is the question as to whether it is really worth the time and effort, just to help people who sound as they would be happier in a windowed environment anyway (I just can't understand what is so difficult about man'ing the command to find out the options)

    My main argument is one of backward compatability with scripts, and the fact that those of us who have learnt all the standard command line flags for things like tar, gzip, sendmail and god knows what else will have to re-learn, as well as re-code our scripts. If the newbies want to have a standard set of the longer GNU-like options (--version, --force, etc.) then that's fine, but don't even think about changing the shorter options...

    There's also the point that options should be more intuitive to the function of the program, so that -f would mean 'filename' in one program but 'force' in another - this plan of standardisation means that filename suddenly becomes -X or something in later releases... uggghhhh...
  • Assuming you meant find | xargs rm -rfn, the find | xargs is redundant. rm -r is enough by itself to handle the recursion.

    Another thing: Getting used to using rm -rfn is a REALLY REALLY BAD idea. What happens when you help a friend who has an account on a Unix box which has a (non-GNU) version of rm which recursively deletes its arguments, then prints: "-n: unkown option". Guess it sucks to be you then. (granted, this is unlikely since most rm implementations don't do anything if they don't like their command line, but if you get used to putting -n as the _last_ option on the line, and going back to delete it later, then programs which use POSIX getline (and so consider all args after the first non-option arg to be non-options), then you are screwed.
    #define X(x,y) x##y

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close