Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!bzs@bu-cs.bu.EDU
From: bzs@bu-cs.bu.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: more rm insanity
Message-ID: <10683@brl-adm.ARPA>
Date: Sat, 5-Dec-87 18:21:02 EST
Article-I.D.: brl-adm.10683
Posted: Sat Dec  5 18:21:02 1987
Date-Received: Thu, 10-Dec-87 20:10:36 EST
Sender: news@brl-adm.ARPA
Lines: 31


I think we've just come back to the age-old problem of "standards vs
innovation". At what point will the shell no longer be the shell and
we may as well just leave the old one (and its documentations) intact
and go on to the Nsh or whatever we want to call it. This is
essentially what the Korn shell is, its intense resemblence to
previous shells is merely a design decision rather than a mandate the
author was required to work with (ie. a modifier of the bourne shell
should probably feel much more pressure for backward compatability
before offering a replacement rather than an alternative.)

I could certainly see Roger Klorese's idea which he brings in from
Multics implemented in a Macintoshian sort of way with resource files,
a one line text pattern a la getopt would probably suffice for
starters.

A program (shell) with such facilities could then be distributed and
the community might decide. That's all the ksh did and it seems to
have been quite successful in attracting fans.

I don't see any other magic way to introduce features like this,
nothing gets incorporated into standards for Unix without first coming
into common use, this isn't OSI where one gets a promise from everyone
in the world to remove the risk inherent before any implementation
occurs, I think many of us question that sort of approach.

Of course, sounding out ideas for reaction is certainly not harmful,
but its value is somewhat muted, it's hard to intelligently judge the
utility of software without being able to actually put it to use.

	-Barry Shein, Boston University