Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.fortran Subject: Re: Command line arguements? Message-ID: <6069@goanna.cs.rmit.oz.au> Date: 1 Jun 91 08:46:04 GMT References: <24632@lanl.gov> <24784@lanl.gov> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 95 In article <24784@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: > 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. In _any_ context? That would be radically unlike other programming languages. How, for example, can you quote a Fortran character literal so that no subroutine it is passed to will treat the chracters other than "_literally_ ... _any_ context"? In all the programming languages I've used, quotation marks and escapes mean that the quoted or escaped characters won't be treated literally in THIS context, with no guarantees being made or possible for any other. Why should a command language be different? > So, in my phone example: > cochiti => phone "S*m" > > 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. If you're not asking for the shell to do filename expansion, you are in big trouble. There are at least three circumstances I can think of in which file name expansion will do nasty things to you: a) There is no file matching the pattern in question. Some shells report this as an error. Users who found that they were forbidden to use wild cards in names unless there was at least one matching _file_ would be very surprised by this. The alternative is to demand that every shell maintainer forsake backwards compatibility just in case one of your users wants to use his shell. b) There may be so _many_ file names matching the pattern that the command is aborted. Again, someone who doesn't intend his pattern to refer to files _at all_ is going to be very surprised when cochiti => phone S*m results in a message like "phone: not done: argument list too big". Again, the only way to prevent this is to require that all shells are changed so as to go ahead with the command anyway, somehow. c) On a networked file system, if a server is heavily loaded or down, the execution of the command may be delayed until the server is ready again, despite the fact that the user does not intend the pattern to have any reference to that server. There are other problems. Different shells have different wild-card conventions, and _none_ of them matches what you get in a tool like egrep, awk, or sed. This would mean that either a.1) Users of your program may not use wild cards in names unless there is at least one *file* matching the name! a.2) OR > 4) The comment has been made that if I get the raw command line I would > have to (horrors) parse it myself! There is a much worse problem. There may never have BEEN any wretched command line. If I do execlp("phone", "kill", "S*m S*e", (char*)NULL); then what is the command line that you expect to see? > 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. Uh, do you _really_ want file name expansion to be done by having people load into their programs one string for every file in the system? And it is rather strange for someone who insists on NOT doing things the way the existing tools do it to suggest that everyone should use ONE pattern matcher. > 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. It is not a bogus argument. It was observably the case that TOPS-10 programs didn't even agree on the syntax of file names, let alone anything else. And UNIX is a _model_ of consistency compared with MS-DOS or VM/CMS. > c) I can get the same inconsistent behaviour by just > _ignoring_ the command line entirely and reading directives to the > utility from stdin. No you can't. There may not BE any such thing as stdin. Again: close(0); execlp("phone", "kill", "S*m S*e", (char*)NULL); If you want VM/CMS you know where to find it. -- Should you ever intend to dull the wits of a young man and to incapacitate his brains for any kind of thought whatever, then you cannot do better than give him Hegel to read. -- Schopenhauer.