Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!hsdndev!cmcl2!lanl!cochiti.lanl.gov!jlg From: jlg@cochiti.lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: Command line arguements? Message-ID: <24889@lanl.gov> Date: 1 Jun 91 23:24:41 GMT References: <24632@lanl.gov> <24784@lanl.gov> <6069@goanna.cs.rmit.oz.au> Sender: news@lanl.gov Organization: Los Alamos National Laboratory Lines: 125 In article <6069@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: |> In article <24784@lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes: |> > [...] |> [...] 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? Exactly. So, in the context of my phone command, the meaning of the parameter(s) is a pattern to match _phonebook_entries_, not file names. So, the quotes should mean to treat that pattern literally in _this_ context. |> [...] |> 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: You left one out, so I'll fill it in before addressing your other cases: 0) File name expansion is already doing nasty things to me by happening at all and not _at_least_ letting me get around it without arcane and non-intuitive syntax conventions. |> [...] |> a) There is no file matching the pattern in question. |> Some shells report this as an error. [...] This is a problem whether you let me see the raw command line or not. Letting me see the command line won't fix or aggravate this failing of the shell. Frankly, I would recommend that user's of such a shell either switch or lobby whoever sold it to them to fix it. |> [...] |> b) There may be so _many_ file names matching the pattern that |> the command is aborted. [...] Again, this is a problem whether you pass me the raw command line or not. |> [...] |> 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. True, I didn't claim that my solution was as efficient as it ought to be. The ideal solution would be to let each utility decide for itself whether 'globbing' should take place and not to have the shell _always_ do it. But, that wouldn't be upward compatible. Passing the raw command line in _addition_ to the 'globbed' arg-list _is_ upward compatible despite its other faults. |> [...] |> 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. Yet, later you go on and on about how consistent UNIX is. |> [...] |> 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? If I document a program with the condition that it expects to see a raw command line somewhere (say, as an environment variable), and you exec the program without providing a command line - that's _your_ problem. The whole thing is a convenience issue for interactive users. I see no reason that an intended _interactive_ utility should be expected to work the same as the "batch mode" commands that UNIX is saddled with. |> [...] 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. Not at all. I was addressing the bogus concern that people raise that 'utter chaos' will arise if the shell isn't granted exclusive rights over command line parameter parsing. It's bogus because consistency comes from planning and discipline among the systems programmers - not arbitrary and arcane constraints on the environment. Providing a common tool to do pattern matching is _one_ way of allowing that planning and discipline to be practiced. For example, if such a tool existed, I could use it for _both_ file name 'globbing' and for matching the names in the phonebook program. That way I would _know_ that the wildcard syntax that each used was identical. |> |> > 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. I've never used VM/CMS (I don't even know what type of hardware it runs on). MS-DOS has a number of inconsistencies because of a lack of communication between implementors (much less any planning and discipline). UNIX is a model of chaos compared to the mainframe systems I'm used to. From your comments above: I can't count on the same 'globbing' syntax (from one shell to the next), I can't count on the same regular expression syntax (from one tool to the next), I can't assume a legal command line will even cause a program to be executed (if the pattern doesn't match or matches too much), etc.. |> > [... workaround using 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 I don't have a way of getting the raw command line, I _will_ write tools which use stdin. This is _already_ done (for exactly the same reason) by tools such as dc and write. If you close stdin before you start up a program which reads stdin, that's _your_ problem. Like your other example involving direct exec() calls, this is _irrelevant_ to the issue at hand. |> [...] |> If you want VM/CMS you know where to find it. Actually, no I don't. J. Giles