Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!alberta!arcsun.arc.ab.ca!arcsun!kenw
From: kenw@skyler.arc.ab.ca (Ken Wallewein)
Newsgroups: comp.arch
Subject: Re: shell architecture (to glob or not to glob)
Message-ID: <KENW.91Feb26134115@skyler.arc.ab.ca>
Date: 26 Feb 91 18:41:15 GMT
References: <378@bria> <19062@cbmvax.commo
	<KENW.91Feb25170431@skyler.arc.ab.ca> <5615@awdprime.UUCP>
Sender: nobody@arc.ab.ca (Absolutely Nobody)
Organization: Alberta Research Council, Calgary Alberta, Canada
Lines: 62
In-Reply-To: tif@doorstop.austin.ibm.com's message of 26 Feb 91 16:33:20 GMT


In article <5615@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes:

> In article <KENW.91Feb25170431@skyler.arc.ab.ca> kenw@skyler.arc.ab.ca (Ken Wallewein) writes:
> >  As a trivil but amusing example, the other day I had a file whose name
> >started with '-'.  There was no way to tell programs which expects shell
> >globbing that "this is not a command option; this is a filename".
> 
> This seems to be a trivial and slightly amusing example of the problems
> of standardizing switch notation with a legal filename character.  Anyone
> that understands the concepts of switch parsing would know that this has
> nothing to do with globbing.

  It has _everything_ to do with globbing.  Certainly, if "-" wasn't a
valid filename character, the parser could use that as a parsing guide.
But even then, it shouldn't matter.

> The current way of doing this in Unix is almost always intuitive and
> is close to infinitely flexible.  A basic knowledge of simple quoting,
> globbing behavior, and switch parsing goes a long way.

  You are referring to the use of a './' prefix, I presume?  I don't find
that intuitive.  The existence of a hack workaround does not invalidate my
point.

  Because globbing changes the command line before the program sees it, the
program has _no way_ of determining the syntax of the original command.
The program must _assume_ that anything it sees in the command that _looks_
like a command option _is_ a command option.  It has no way of knowing
whether that "option" was entered by the user, or is actually a filename.
It must make an assumption which is _usually_ correct.

  Sure, one can apply escaping and quoting, etc.  But programs which rely
on shell globbing generally can't handle such arguments anyway.

  Consider another case (what the heck, I'm brave :-)

	> mv cmp* compress*

as a file rename operation, without shell hacks?  Same problem: how can the
program parse it properly?  It has simply no way to know what the original
command was.  It would see two lists of "deglobbed" filenames, with
no way to know which was which, or even that it wasn't a single list.
Sure, mv can check the last one to see if it is a directory, but that's an
inelegant kludge.

  Handling such a command requires either preventing globbing of the
original command line so that the program (script or otherwise) can see the
original version, or some "intuitive" syntactical trick such as interposing
a "place-holder" like "-" between the two arguments, and hoping there
aren't any files by that name.

  Don't get me wrong -- I'm not saying globbing is a bad idea.  It's slick.
But command line preprocessing which removes syntactical information _does_
sometimes make it hard to be unambiguous.  

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


Brought to you by Super Global Mega Corp .com