The shell, glob expansion, and all that

[utzoo!decvax!yale-com!leichter]

There has been a great deal of discussion (a while back - I've been away...)
of where "glob" processing etc. should take place, whether there should be
escapes for programs whose arguments look like (but are not) file specs, and
so on.  I think it's worthwhile to look at other solutions to the same problem.

DECUS C is a C compiler available from DECUS which runs (compiler and resulting
code) on everything from LSI-11's to VAXen (in compatibility mode).  There is
a run-time support library that provides emulation of most UNIX I/O as well as
the other common functions we all know.  All this works under RT-11, RSX, RSTS,
and VMS.  (BTW, there is also a nice - and growing - set of tools similar to the
UNIX set.  Why not just use the UNIX set?  Ah, these are all in the public do-
main and come free, like the compiler.)

Because of the variety of operating systems under which DECUS C runs, some of
them (all of them?) quite inflexible, there is no easy way to implement a
shell that would provide a UNIX-like interface - unless, like the Berkely VOS,
you are willing to ignore the underlying operating system interface and dupli-
cate services it already provides.  Nevertheless, for C programs, one would
really like at least I/O redirection and argv/argc to work.

And, indeed, they do.  The mechanism is totally different from UNIX's; the
standard prolog, linked into all C programs, analyzes a command line passed
to it by the host operating system, does I/O redirection, and sets up argv/argc
so that DECUS C programs can see a reasonable environment.  (Getting the various
OS's to pass the command line ranges from trivial (VMS) to difficult (RSX).)

The prolog does NOT expand wild-carded arguments.  Instead, a pair of library
routines, fwild() and fnext(), are available.  fwild() is an alternative to
fopen(); it accepts a file spec that contains wildcards (using the conventions
of the host operating system) and opens the first matching file.  fnext(),
applied to a file pointer opened with fwild(), closes the currently open file
and opens the next one.  Files opened this way are normal in all other respects.

Coding using these functions is generally straightforward.  (My chief criticism
is that fwild() on some operating systems will not accept a non-wild spec, which
complicates your code for no good reason.)  You end up with a double loop over
all specs in argv and then through all matching files; if you think that this
is too complicated, I would suggest either (1) doing an fwild() that is passed
an array terminated in some known way and returns the next matching file of
the next entry when it finishes some entry or (2) simpler and just as good,
creating a file with that double loop once and for all and plugging code into
it from there on - an obvious extension of getopt().

What are the tradeoffs involved in doing things this way?  The main advantage
is generality - a program can do expansions only exactly where appropriate.
It can also do expansions on file specs that it generates itself in exactly the
same way.  The disadvantages are two-fold:
	o The program is bigger.  This turns out to be insignificant for DECUS C
	  because the various operating systems provide wild-card matching as a
	  kernal operation.  (RT-11 is an exception; in this case the code must
	  do the work itself.)  This is the price you pay for not having some
	  way of sharing code other than kernal-code...
	o There is (in principle) some loss of uniformity of user interface.
	  I find this argument rather specious, since there is nothing else
	  uniform about the argument structure of UNIX programs - and, in any
	  case, I find the statement "all FILE arguments have their wild-cards
	  expanded" no less uniform than "ALL arguments have there wild-cards
	  expanded" - when I type a pattern argument to grep, I know damn well
	  that it isn't a file spec!

							-- Jerry