Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!wuarchive!udel!rochester!kodak!uupsi!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Command line arguements?
Message-ID: <24784@lanl.gov>
Date: 31 May 91 16:41:58 GMT
References: <eesnyder.675543629@beagle> <24632@lanl.gov> <5513@dftsrv.gsfc.nasa.gov>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 61

Here are some clarifications on command line arguments.

1) I can't write my own shell because I can't be sure the end users of
   my utilities will be using my shell.  Writing utilities that only work
   under one specific shell is unprofessional.

2) Quote and escape marks _should_ mean that the quoted or escaped
   characters will be treated _literally_: that no 'globbing'  or
   other reprocessing will be applied to them in _any_ context. 
   So, in my phone example:

      cochiti => phone "S*m"

   This _should_ look up any company, organization, or individual whose
   phonebook entry contains the letters S and m separated by an asterisk.
   Since this is the proper meaning for escapes and quotes, the use of
   them to get the characters past the gauntlet of the shell is not 
   acceptable.

3) I am _not_ asking for the shell not to 'glob'.  The modification I 
   want is completely backward compatible.  I want the unparsed command
   line _in_addition_ to the normal parsed arguments.

4) The comment has been made that if I get the raw command line I would 
   have to (horrors) parse it myself!  Since this is _exactly_ what I
   _want_ to do, I don't see the problem.  I thought the standard reply
   from UNIX supporters defending how arcane and clumsy it is was "it 
   empowers the programmer, it assumes that the programmer knows what 
   he's doing."  Is that _not_ the case here.  Is parsing a command line 
   something that you want the system _not_ to assume that you know how 
   to do?  In any case the matter is easily settled: write a single 
   wildcard matching function which takes the pattern and a list of 
   strings and returns a list of those strings which match the wildcard
   pattern.  Then, everyone could use the same tool.

5) The have been references to the bogus argument that if the raw command
   line is passed to the program, then the command line syntax will become
   incompatible from one tool to the next.  There are three reasons this
   argument is bogus: a) UNIX tools (and those on any other system) are 
   _already_ inconsistent; b) consistency is better maintained by discipline
   among the authors of system utilities, not by arbitrary constraints on
   the environment; c) I can get the same inconsistent behaviour by just
   _ignoring_ the command line entirely and reading directives to the 
   utility from stdin.  In view of (c), the constraint on the command
   line visibility gains _nothing_ in terms of compatibility.  For example, 
   the phonebook tool could work like:

      cochiti => phone (arg list ignored, I can put anything here)
         Name? S*m s*de
            Sam Spade: (505) 677-7111
            Slim Shade: (505) 678-1234
         Name? quit
      cochiti =>

I guess it's only slightly less convenient.  And after all, that's the
whole point of UNIX isn't it?  To be just _slightly_ less convenient
(or _slightly_ less efficient, or _slightly_ more of a disk/memory 
hog, or _slightly_ harder to learn, or - wait a minute: some of these
aren't _slight_!).

J. Giles            (UNIX: the OS of Dorian Grey - ttw)