Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.os.misc
Subject: Re: UNIX mind-set  -> OK, OK!
Message-ID: <1991Jan18.175917.28766@Think.COM>
Date: 18 Jan 91 17:59:17 GMT
References: <1991Jan16.063253.2834681@locus.com> <1991Jan16.182106.1758@Think.COM> <59451@aurs01.UUCP>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 48

In article <59451@aurs01.UUCP> throop@aurs01.UUCP (Wayne Throop) writes:
>> barmar@think.com (Barry Margolin)
>> None of these changes are feasible in current Unix, 
>> but they are ideas for future OSes.
>I mildly disagree.
>If, for example, one developed a shell where argument types and
>relevant coersions could be specified INDEPENDENTLY of commands,
>fitting "old" commands into a more intelligent shell would not
>be prohibitive.  It is only when the command has to do its own
>coersions that things become unworkable.
>
>Unless of course Barry sees some difficulty I don't?

Well, I'm not a big fan of command processors where the syntax descriptions
are separate from the commands themselves, so I often inadvertently forget
about them when making statements like the above one.

The problem with a separate syntax DB is that it may be hard to update or
find the DB entry.  If there's a single, central database then it's hard
for users to put their personal commands into it.  If the database is keyed
off command names then links with different names have trouble.  If there
is a per-directory DB then links across directories don't work.

Probably the best place to put the syntax description is in the executable
file's header, in some portion that is normally ignored by the exec*()
system calls but can be examined by the shell.  And for shell scripts it
could be put in specially-marked comments right there in the script.

Portability is also a problem.  Commands that expect the shell to parse
arguments in the new way might not be easy to run on old-style systems.
When getopt() was first getting popular, the solution to the problem that
not all systems have getopt() was that software packages often contained
their own copy of the PD getopt() implementation, for use on systems
that don't already have it, or the installation instructions contained
information on getting the PD getopt().  During the transition period for
these new shells would they have to be distributed along with the software
that depends on them?  There are also quite a few different shells, and
users would need a new-style version of every one.

This is why I prefer library-based approaches rather than shell-based
approaches.


--
Barry Margolin, Thinking Machines Corp.

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