Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site circe.UUCP Path: utzoo!watmath!clyde!burl!ulysses!circe!gsp From: gsp@circe.UUCP (Gary Perlman) Newsgroups: net.cog-eng,net.unix Subject: name=value or -n value? Message-ID: <44@circe.UUCP> Date: Wed, 21-Mar-84 02:39:51 EST Article-I.D.: circe.44 Posted: Wed Mar 21 02:39:51 1984 Date-Received: Wed, 21-Mar-84 08:42:43 EST Organization: AT&T Bell Laboratories, Murray Hill Lines: 122 I am impressed with the suggestions for standards which concentrate on the name=value pair system. While this is contrary to UNIX tradition, it seems more consistent and allows multi-character names for options. My own support for such a standard has changed over time and I will tell why. At first I rebelled against the traditional "convention" for the more clear name=value convention, but with some convincing by some analysis of usage and some results of implementation, I have come to respect both. I think the attempts at replacing the current "convention" with another is an over-reaction. What is needed is a consistent standard that gets followed; the lack of any (or software supporting it) has resulted in poorly implemented programs that give people grief they don't deserve. I think that the recently proposed system (mostly consistent with tradition) is as good as any, and that poor and inconsistent implementations are to blame for the problems so many have observed. One of the problems with UNIX commands is that the use of command line options is inconsistent. Some of the `rules' to which there are numerous exceptions are: Options are preceded by a dash (-) Options can be bundled Options are single characters Option letters must be immediately followed by a value Flagged options must precede others Commands without arguments print their options (dangerous) The exceptions are everywhere: ps (some versions) does not allow a - nroff does not bundle flags stty takes multi character options cc option values must be preceded by a space (cc -o file) nroff values must follow option flags (nroff -man is really the "an" macros!) dd uses name=value format find has brain damaged syntax cc doesn't care about where options to the loader go Looking over these, one has to say: "If there were ONE way to do it, things would be better," and "What way is the best way?" Anyone can see that UNIX command line arguments are a mess, but what to do about it is more difficult to determine. In the 1984 Winter USENIX conference, Hemenway and Armitage presented a proposed standard for options. It looked a lot like traditional UNIX command line handling, except that standards were introduced: options are preceded by a dash options are single characters options taking values must be preceded by a space boolean options can be bundled There are 13 rules, which are pretty easy to follow. At first glance, I said "Ugh!" I wanted to see name=value pairs to allow multi-character option names. I almost fully supported Brad Templeton posting of the Waterloo system (I referred to have ALL args as name=value pairs so that alphanumeric option names for logical flags could be specified as name=t or name=false, and + and - would be synonymous with true and false, respectively so that name+ and name- would be parsable and fall out of the same name=value convention). This is a standard on some systems inside Bell Labs where a common computing environment for several systems is needed. I further supported name=value pairs because I too had written software for parsing them in command lines and files. But then I learned about the work of Hemenway and Armitage. They looked at hundreds of commands on UNIX and categorized the full range of usage exemplified by the exceptions above. Their goal was to come up with recommendations about what to do about UNIX and its command line problems. Their conclusion was that consistency was highly desirable, but so was compatibility with existing programs. Their analysis, which I consider to be the most sane I have seen, points out that backward compatibility is not only with command usage by people, but also by shell scripts. People at Bell Labs use shell more than anywhere else, especially since ksh, the new shell by Dave Korn (See Summer USENIX, 1983) is so much faster. I found it hard to believe, but there are system here with thousands of lines of shell. To admit total defeat and say "Scrap the -options for name=value pairs" would mean that a lot of systems depending on shell scripts would not work any more. This would not fare well with management concerned with giving support to a naive user community; you can't say "Everything is changed (for the better)" without alienating a lot of people (I cite BSD 4.2). Hemeway and Armitage were not naive. They realized that people would not react well to old commands being changed to fit ANY standard, not matter which. They have stated that standards would apply to new commands; old ones might be reworked to make them more robust, but not different. To maintain good terms with programmers, they surveyed to find out what people liked about the - system. They found that people liked to bundle logical flags: ls -ltr ps aux Imagine typing: ls +long +temporal +reverse (abbreviated ls +l +t +r) The amount of typing, using abbreviations, is not much greater, though any mnemonic enhancements of multi-character options are lost. Another problem pointed out about name=value pairs is that global file expansion of the shell might not work correctly (ls file=* passes * to ls) though the name=value convention could be programmed in the shell so that anything after = would be expanded. This would work except that the shell already has options to take name=value environment variables anywhere on the command line; little known, but there all along. At this point, you probably feel as I did. There seems to be no complete solution. For every suggestion, there is an opposite as well founded. I worked on an enhanced version of getopt (the little known standard parser for UNIX command lines; little known because it was not released to the public [To make a standard fail, keep it a secret]). The main point of the new parser was to enforce the simple standards of Hemeway and Armitage. As an exercise, I rewrote some of my own commands. I found that my programs had exceptions to every rule, and that few commands were consistent with others. After doing the retrofitting, I found that I could use my own commands more easily than before. I was impressed because it demonstrated to me that CONSISTENCY was so important, even with my own programs. I was also impressed that the use of "-X value" instead of X=value no longer seemed to be much of an issue. When the parser allowed on-line help phrases for options, the advantage of multi-character option names seemed less of an issue. My conclusion is that the syntax does not matter much, so long as there really is a syntax. To call the current usage of flag options in UNIX a "standard" is dangerously mistaken; thus far on UNIX, the exception is the rule. Given good implementations of a simple rule, whether the rule is -X value or X=value, or maybe even if the rule were value#X, users should fare about equally well. I conclude that conventions like the Waterloo system are successful because the rule is simple and well implemented, not because there is any advantage to their particular rule. This is a hypothesis that is relatively easy to support with data and I would like to see some or maybe even collect it myself. Until then, it seems like the Hemenway and Armitage analysis and proposal is the most practical because it incorporates simple standards with the highest degree of backward compatibility. Gary Perlman BTL MH 5D-105 (201) 582-3624 ulysses!gsp