Newsgroups: comp.os.misc
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!ubc-cs!alberta!arcsun.arc.ab.ca!arcsun!kenw
From: kenw@skyler.arc.ab.ca (Ken Wallewein)
Subject: Re: Globbing
In-Reply-To: peter@ficc.ferranti.com's message of 19 Mar 91 23:16:22 GMT
Message-ID: <KENW.91Mar20162655@skyler.arc.ab.ca>
Sender: nobody@arc.ab.ca (Absolutely Nobody)
Organization: Alberta Research Council, Calgary Alberta, Canada
References: <17602@lanl.gov> <WG0A148@xds13.ferranti.com> <18205@lanl.gov>
	<A23AFH9@xds13.ferranti.com> <18365@lanl.gov>
	<B.3A_=8@xds13.ferranti.com>
Date: 20 Mar 91 16:26:55

In article <B.3A_=8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:

   In article <18365@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
   > 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.

   But you don't *know* that only the ultimate consumer is going to expand
   wildcards. We're talking about random programs written by random people
   at random times for random purposes with random levels of debugging. At
   least in UNIX you know that anything you get has been expanded already,
   and there is no reason to do so again.

   What you're saying makes perfect sense in an ideal world, but that's what
   I've been saying all along. In the real world, you have to assume that
   the program you're passing stuff to might decide to glob it.

So what you're saying is that it's better for programs not to glob, because
that way you can totally bypass the globbing mechanism if you want to.
That makes a lot of sense.  But it has a lot of limitations, too, as have
been well described in this discussion.

Unless we are just having a religious war about whether shell or program
globbing is better, let's be constructive.  What can be done, in both the
long and short term, to improve this situation?

It seems to me that we must consider shell globbing to be a tool somewhat
separate from the shell per se, which assists us in giving file names to
programs.  So here's my constructive thought:

The clobbing mechanism should be recognized as the preprocessor it is, and
unbundled from the shell.  It should made accessible, controllable, and
extendable like C preprocessor 'cpp' (...poor though that preprocessor is).
Globbing needs to be more controllable; perhaps such a mechanism might
help.

   > 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.

   Sounds like the programmer screwed up somewhere. I've never had to nest
   more than two quotes. Of course using backslashes instead of quotes to
   quote the argument is probably a mistake.

I agree that quoting/backslashing can be a royal pain -- especially when
one is trying to define aliases.  However, I think that it is a broader
issue that globbing; rather, that it is a shell design issue which affects
the use of metacharacters in general, not just those used for globbing.
Once that is removed, the problem of when expansion occurs is greatly
reduced, although not eliminated.

   > |> 	OPEN(NAME='JGTEST.TXT',TYPE=UNKNOWN)

   > Good example!  Note how the ultimate consumer of the string "JGTEST.TXT"
   > will get exactly that string

   But that's not the string he started with. He started with "'JGTEST.TXT'".
   He quoted it at the top level (the language) and it then went all the way
   down with no further quotes because none of the levels in the way did any
   globbing. Your argument that tools should glob is like expecting OPEN to
   glob.

What's wrong with that?  As far as I'm concerned, the file system calls
_should_ be able to expand expressions, "~", variables, etc., the same way
thay handle soft links and (in VMS and AmigaDOS) logical names.

What seems to be missing in most environments is a well-planned syntax
which allows one to say clearly and unambiguously what one means -- to say
what is a wildcard expression, what is a command option, and what is
literal data -- and be sure both that a program gets exactly the command we
want it to get, and that it interprets that that command the way we want.

--
/kenw

Ken Wallewein                                                     A L B E R T A
kenw@noah.arc.ab.ca  <-- replies (if mailed) here, please       R E S E A R C H
(403)297-2660                                                     C O U N C I L

