Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!samsung!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.os.misc
Subject: Re: UNIX mind-set -> OK, OK!
Message-ID: <1991Jan16.002146.6818@Think.COM>
Date: 16 Jan 91 00:21:46 GMT
References: <5371@idunno.Princeton.EDU> <1991Jan15.053904.2881@Think.COM> <1991Jan15.222146.9697@lingua.cltr.uq.OZ.AU>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 64

In article <1991Jan15.222146.9697@lingua.cltr.uq.OZ.AU> root@lingua.cltr.uq.OZ.AU (Hulk Hogan) writes:
>Besides, aren't you overstating the importance of this? In my experience,
>the only times I've ever had to worry about this is with the "-name" option
>to find (find -name pattern .....),  wildcards as arguments to the grep(1)
>family  and not being able to use "-?" as a help option.  This is at worst,
>a minor annoyance, and may be relieved by the ability to tell the shell
>which commands you don't want globbed, as is done in "zsh" by Paul Falstad
>(pfalstad@phoenix.Princeton.EDU).

Please don't construe my remarks as implying that this is a major flaw in
Unix, or that I am suggesting that any attempt be made to fix this aspect
of Unix.  The current scheme works well enough, and it would be impossible
to change it because it would affect nearly all Unix programs.

No, I am merely pointing out that I think this part of Unix was a poor
design choice, and that a glob(3) library would have been better (I
wouldn't even think of suggesting that commands do their own globbing
without aid from a library that does the hard part).  The most annoying
thing about it is that it has such pervasive effects that it can't possibly
be redesigned.  Compare this with the original design that didn't provide a
library interface to directories; when the directory library came out years
later, programs could slowly migrate to it, but programs based on the old
design didn't immediately break (but eventually they did, when things like
NFS came out).

Had Unix been originally designed with all commands calling glob(3), and
then someone decided that it would be better to move globbing into the
shells, such a change would have been possible.  One possibility would be
to replace glob(3) with a version that simply returns its argument as the
only match, on the assumption that all shells would glob.  Another
possibility would be to have a quoting convention that glob(3) recognizes,
and have the globbing shells quote the resulting pathnames so that glob(3)
wouldn't reglob them.  This second design would allow an easy migration to
globbing shells, as users of non-globbing shells wouldn't be scrod
immediately (but as new programs that expect the shell to glob come out
they would be).

Unix is riddled with designs that would be impossible to change because so
many programs are dependent on them.  Things like pathname syntax (lots of
programs know about the "/" delimiter), the special filenames "." and "..",
the pathnames of terminal devices, etc.  It would at least have been nice
if all these special strings were defined in standard header files.  On
Multics, very few programs need to know anything about pathname syntax, and
the user-visible pathname syntax isn't even the same as the kernel's
pathname syntax (they're similar, but the kernel doesn't accept relative
pathnames, and requires the directory name to be separated from the entry
name for some reason); there's a library routine that takes a pathname in
user syntax and parses it into the kernel's syntax (many users, myself
included, used dynamic linking to access customized versions of the
pathname parser, to extend the syntax in various ways).

By the way, to be fair, we didn't get all this right in Multics, either.
Not all useful pathname operations were embodied in library routines, so
some programs did have to manipulate them directly.  And there were some
magic numbers that found their way into many programs.  But Unix, being the
progeny of Multics, should have done *better*, not worse.  I can understand
the corners that were cut to allow Unix to run on smaller boxes than
Multics, but some of these are straightforward software engineering
principles that have nothing to do with the runtime horsepower.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar