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? "
*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
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.
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.
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
So, in order to make all programs perfect for you, we shall:
1. force everyone who codes for free to use only one standard... or else?
and
2. make everyone who is used to the paramaters of a program, learn a whole new set.
sounds good enough to me...
lets do it... oh, and while we are at it, lets standardise on a common gui toolkit, and a standard windowmanager.
Its spelt "L-I-N-U-X", but pronunced as "Free Beer"
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
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
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!. :-)
-- VVB (v@w.cl)
as others have pointed out, GNU is implementing something like this with --version and so on. Others have addressed many of the other problems, leaving me with only one point to add.
If we standardize and document the command line interface, there'd be that much less to keep weak minded pathetic little goons like, say, Paul McCartney or Al Gore, from gaining the godlike sysadmin powers we revel in every day.
People keep saying "steep learning curve" and "barriers to entry" like those are bad things...
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
I'm sure CORBA already supports this, but I'm more familiar with Windows. If you fire up OLEView on a peecee, you can ask an object what its grammar is. If we had a standard "command builder" that would use a graphical interface that allowed users to build a command, they would immediately discover the power of the command line.
This would be similar to what Apple's been doing for years with AppleScript, only you'd want something that guaranteed proper grammar. AppleScript's big weakness is that it's easy to read but really hard to get the grammar quite right. This program would build a bash style pipeline, with immediate access to info pages and suggestions for frequently used commands. It should build functions for the user, and store them in a bookmarks-type file.
All this could be done in a telnet session, but a proper GUI could handle the help windows nicely.
I think we have two extremes right now. One is the sendmail style program that is incredibly powerful in the hands of an expert, but can't be touched by a newbie. The other is the Macintosh Finder that anyone can sit down and use, but is useless for advanced tasks.
I don't think a command builder would be aiming at lusers. We shouldn't code for stupid people, rather we should understand that many times our programs are going to be used once or twice and then forgotten. Did you ever visit the gzip website? It's one thing for you or I to know its options intimately, but why should a typical user care? After all, it's just a compression program!
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!
I think there's a benefit to forcing "newbies" (not meant derogatorily) into the good habit of RTFM. Namely, fewer headaches down the road when they actually understand what they are doing before they do it.