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