Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!yale!cmcl2!lanl!cochiti.lanl.gov!jlg From: jlg@cochiti.lanl.gov (Jim Giles) Newsgroups: comp.os.misc Subject: Re: Globbing Message-ID: <18365@lanl.gov> Date: 19 Mar 91 17:05:41 GMT References: <17602@lanl.gov> <18205@lanl.gov> Sender: news@lanl.gov Reply-To: jlg@cochiti.lanl.gov (Jim Giles) Organization: Los Alamos National Laboratory Lines: 78 In article , peter@ficc.ferranti.com (Peter da Silva) writes: |> In article <18205@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: |> [...] |> > Only in the _rare_ case when the arguments contain wildcard characters |> > that you don't want expanded. |> |> No, this is the common case, when you're passing a string to a program |> that you got from somewhere else. You *have* to assume that it might be |> expanded. It is a bug to do anything else. No, you don't. If no tool but the ultimate consumer _ever_ expands wildcards, then quoting need be used only if you have wildcard chars that you don't want the ultimate consumer to expand. No intermediate tool, shell, processor, path, parser, or program has any business altering an argument that it's supposed to be just passing along. |> [...] |> > Exactly what I just said: DON'T quote multiply - quote once and for |> > all!! |> |> And that means, you quote in the shell. No, it means that the shell doesn't do _anything_ to command line arguments so that the quotes arrive at the tool still intact. If the shell handles quoting, then complicated scripts have to count how many times each argument will need to be escaped to prevent being mangled. I've seen scripts with 8 consecutive backslashes (\) because the programmer wanted _one_ to be literally present in the ultimate context of the argument - and it was only going through 2 intermediate commands. I thought that was ample evidence of the stupidity of shell oriented argument parsing until someone told me of a similar program with 64 consecutive backslashes!! He had only 5 intermediate commands (the ultimate, being the sixth, reduced the last pair to a single backslash). This is what I _DON'T_ want to have to do. I _DON'T_ want to have to multiply quote an argument that should be simply passed unchanged through the command language until it reaches its ultimate consumer tool. |> [...] |> > Quoting should mean what people intuitively think it means: |> > the quoted argument will be used literally. No matter how many levels |> > deep it's passed and no matter where it goes, the end use of the string |> > will use the exact literal contents of the string. |> |> I see, so if you're writing a Fortran program you shouldn't have to quote |> the file name in the following statement: |> |> OPEN(NAME='JGTEST.TXT',TYPE=UNKNOWN) Good example! Note how the ultimate consumer of the string "JGTEST.TXT" will get exactly that string - no matter how deep in the I/O library this string is passed, it will never be globbed, sludged, mangled, or trashed at any intermediate step. Meanwhile, the variable UNKNOWN will be evaluated _once_ and not changed afterword either. The proper context for evaluating Fortran variables is in the routine to which they are local - that is, in the caller as is done here. The proper place to evaluate wildcards in a command language is in the context of the ultimate consumer of the argument. |> [...] |> > And consistent syntax is achieved by programmer discipline, not |> > monstrous shell design. |> |> Why should the shell be different from any other programming language? Because the shell has a different function and different problem domains. Still, the difference between what I want and what other programming languages do is trivial - I just pointed it out: The arguments should only be evaluated _once_ in either the command or the programming language. The arguments should be evaluated in the context where the _meaning_ of the argument is known - by the _caller_ in a programming language, by the ultimate destination in a command shell. In _both_ cases, the argument passing mechanism doesn't know what the argument means and should not alter it _at_all_! _YOUR_ recomendation is much further from programming language design that mine. J. Giles