Newsgroups: comp.os.misc
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Subject: Re: Globbing
Message-ID: <VJ5ARH2@xds13.ferranti.com>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
References: <17602@lanl.gov> <WG0A148@xds13.ferranti.com> <18205@lanl.gov> <A23AFH9@xds13.ferranti.com> <18365@lanl.gov> <B.3A_=8@xds13.ferranti.com> <KENW.91Mar20162655@skyler.arc.ab.ca>
Date: Thu, 21 Mar 91 17:58:24 GMT

In article <KENW.91Mar20162655@skyler.arc.ab.ca> kenw@skyler.arc.ab.ca (Ken Wallewein) writes:
> 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.

Exactly.

> That makes a lot of sense.  But it has a lot of limitations, too, as have
> been well described in this discussion.

It means that you have to be able to tell the shell not to glob, for the
relatively uncommon case where file globbing is not what you want.

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

A standard library routine for performing globbing is a must, but I don't
see that it changes the arguments in favor of doing shell globbing.

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

Agreed. Globbing is a side issue: it changes the magnitude of the "problem",
but it hasn't created it.

> Once that is removed, the problem of when expansion occurs is greatly
> reduced, although not eliminated.

Once what is removed? The use of metacharacters in shell syntax? I don't
think you can do away with that without abandoning the idea of having
the shell as a programming language altogether. I am not prepared to do
that.

You can always abandon shell programming, and have (as you say) a separate
preprocessor that does the preprocessing and calls the "real shell" to do
the work, but I would say the resulting pair of programs will continue to
be used as the shell. The "new shell" will be little but a loop calling
execv... and you already have that tool available.

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

But the semantics of file system calls are different. "Open" returns a single
file token (handle, LUN, whatever). Which of the 47 matching files foes it
open for "*.c".

I've used a system (on CP/M) where the runtime did this very thing, and
the resulting program behaviour was confusing to say the least.

As for a complete syntax for command arguments, see "parseargs", recently
posted to comp.sources.misc.
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"
