Asri-unix.437 net.unix-wizards utzoo!decvax!ucbvax!menlo70!sri-unix!tjt@mit-vax Tue Jan 5 22:46:54 1982 Re: Reply to: On I agree that all programs should be consistent in the sense two commands with similar options should in fact have identical options activated by identical syntax in the command line. However, there is clearly a lot of disagreement as to how this should be accomplished. One example of consistency (or inconsistency) in user commands is exhibited by expanding "wildcard" file names. On systems I have used where individual programs must expand these names (most recently VMS), (even with operating system or subroutine library help) there have been programs that do not accept wildcards. I believe that this is because on these systems, the user is required to "roll his own" subroutine (at some level) to handle the wildcards. While it is true that VMS does have an extensive subroutine library for dealing with the command line interpreter, the complexity of this interface is intimidating. While this may be an extremely feeble excuse for deliberately designed utility programs, it ignores the fact that many useful utilities are not designed, but evolve from `hack' programs, which become de facto utilities without being reengineered (after all, they already work, and rule #1 of software maintainence is "don't fix it if it isn't broken). On the other hand, expanding all wildcard filenames in the command interpreter ensures that any program can make use of wildcards, without additional programming. However, the wildcard expansion performed by the shell is context-free (i.e. independent of the command that the wildcard names are intended for). The net result is that while wildcards in the UNIX shell are consistent, they aren't necessarily what you want (e.g. mv *.c *.c.old). While "consistency is not all it's crack up to be", in this case, my preference is for the simple-minded consistency supplied by the UNIX shell. The other main area of inconsistency among UNIX commands is inconsistent syntax for options. For example, some programs use -l66 to specify 66 lines per page, while others require -l 66, and some other may require pagesize=66. Part of this is fundamentally a management problem rather than a shortcoming of current programming technology, since programmers are free to choose any names they please for options. However, this problem is especially severe when the programmer has to "roll his own" argument interpreter for each program, since the simplest programs expose the most inconsistencies (e.g. requiring single characters options to be specified as separate arguments such as `ls -l -s -a' as opposed to `ls -lsa'). Implementing a table driven argument interpreter (as in VMS) is one approach to this problem, although I personally would prefer `templates' for main programs that interpret various options and invoke some function on other arguments. If the templates are properly coded, the action of the program should be easier to understand than a table driven interpreter. Yes, I realize that one could always make templates for the tables for the interpreter. However, the scenario I imagine is similar to using bravo on an alto starting from some predefined form: the editor would initially display a skeleton of the program, with the blanks highlighted in some way (e.g. enclosed in box comments, or underlined, or in a different typeface or color). Either of these techniques would make it easier for unix programs to be consistent. It is still necessary to decide what we should be consistent with, and to change the existing utilities. ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.