Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!bria!mike
Newsgroups: comp.arch
Subject: Re: UNIX mind-set  -> OK, OK!
Message-ID: <360@bria>
Date: 16 Jan 91 05:25:52 GMT
References: <1991Jan14.013815.11419@ims.alaska.edu> <11314@lanl.gov> <5340@idunno.Princeton.EDU> <1991Jan14.170115.17178@Think.COM>
Reply-To: mike@bria.UUCP (Michael Stefanik)
Organization: Briareus Corporation, Los Angeles, CA
Lines: 82
Followup-To:

In article <1991Jan14.170115.17178@Think.COM> think.com!barmar (Barry Margolin) writes:
>I've used several systems (Multics, ITS, TOPS-20) where the commands
>invoked the globbing routine, and rarely found it confusing.  There's a
>simple rule: if an argument is a filename, and it makes sense in the syntax
>of the command to refer to multiple files at once, then it is processed for
>wildcards.  Non-filename arguments (e.g. the first argument to grep) are
>never processed for wildcards.  Filename arguments that don't make sense to
>be wildcards (e.g. the last argument to mv) are scanned for wildcard
>characters, and generate an error if any are seen (there's generally a
>syntax to override this, to allow you to access files with wildcard
>characters in their names when you *really* need to).
>[...]
>In the "one tool = one job" approach, I think the shell should handle the
>job of parsing command lines.  Since part of this philosophy is that the
>tool should do this one job *well*, I don't think the shell should expand
>wildcards.  It doesn't know which arguments are filenames, so it shouldn't
>blindly expand wildcards in all of them.

What you seem to be suggesting is something along the order of how VMS
handles commands: you create a text file (which describes the command
in various details), "compile" it into a database and tell the shell that
the new command is available, and how to parse that command.  Thus, under
VMS, when you enter a command, the shell breaks it down into components
that are read by the program when it executes.  The alternative is that the
shell does no globbing.  Either approach doesn't sit too well with me
for a few reasons:

1. It complicates code design by adding an extra "level" of complexity
   to the problem being solved.  Now, not only do you (as a programmer)
   have to worry about coding just the solution, but also how the
   shell will interact with it.  If I want to add a feature to a program,
   I can easily throw in a switch option, write the code to go along
   with it, and compile.  Under what you are proposing, I would additionally
   have to tell the shell that the program has been changed.  This is a
   real hassle.  When I was writing code under VMS, I was constantly
   changing this interaction between program and shell, and having to
   recompile the command definition and enter SET COMMAND all the time and
   this was a significant pain.  This functionality may have marginal benefits
   for the user, but it would be a *real turnoff* for UNIX programmers.

2. In my view, it is the job of the shell to parse (and glob) args, not the
   programs that are being given the arguments.  The idea of having a
   routine that would process command arguments would be used in an
   inconsistent fashion (as the DOS world shows us), and would either
   increase the size of every program unreasonably (unreasonable in the
   sense that the program shouldn't *have* to do this), or prevent
   these programs from being statically linked (and remember, not all
   flavors of UNIX support sharable libraries; what happens when you
   have two machines, COFF compatable, but one has the library, the
   other doesn't?  What happens when this function, because it would be
   new, is defined seven different ways by seven different vendors?)
   A standard becomes such because it stands the test of time; just
   throwing some subroutine in libc.a and insist that everyone use it
   just ain't reasonable.

3. If you don't go the command database route, and simply let the program
   do *all* globbing, then what if I want to change the way the command
   processes the arguments *on the fly* (ie: as I am entering the command);
   shall the program then be responsible for quoting, etc?  What if your
   program says "well, they'll *never* use this argument as a file (therefore
   globbing is not done), and I come up with a unique solution that would
   facilitated by globbing?  By putting globbing in the program, and not
   giving me the source to change what you think should be done, you take
   a freedom away from me.  On the otherhand, the shell expands wildcards
   in a predictible fashion (some may argue that it is obscure, but none-
   theless, it is predictable), and I have complete control over how it's
   done (to use quotes, or not to use quotes, that is the question ...)

If you don't like globbing, then turn it off, use quotes, or escape it.
The point being that, if globbing confuses you, you're not *forced* to
use it; forcing programmers to take on that responsibility, IMHO, is
unreasonable at this late date.

BTW, I speak not for end users (for how many users care about the
many variations of globbing, or whatever?)  They just want to select
their application from a menu, and not be bothered.
-- 
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
--
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."