Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!math.fu-berlin.de!fub!tmpmbx!scuzzy!src
From: src@scuzzy.in-berlin.de (Heiko Blume)
Newsgroups: comp.unix.shell
Subject: Re: seperate the command language and interactive she
Message-ID: <1991Apr23.182237.13839@scuzzy.in-berlin.de>
Date: 23 Apr 91 18:22:37 GMT
References: <2219@optima.cs.arizona.edu> <585@lysator.liu.se> <1991Apr22.210153.16143@gpu.utcs.utoronto.ca>
Organization: Contributed Software
Lines: 21

jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes:
>	Yes, I think it isa good idea, but I think it should be done by a
>USER LEVEL process.  Either the controlling process on a PTY, or
>somehting like the emacs shell window.  Please, PLEASE, *PLEASE* don't
>put BASH or EMACS into the Kernel.  Please!  :-)

well, since we'll all have a MACH based OS soon :-), where the 
now-kernel-builtins will be in seperate system processes, it should
be relatively easy to give each user his choice of interaction style.
even the users own code could be used, since it will be a normal
process, and not part of the kernel.
no kernel bloat, no security horror, no memory hogging, easy fixing
and improving etc, etc.
perhaps a new field in /etc/passwd, or a .discipline file which
tells login what to put between the user and his (other) processes
for providing <put your feeping-creaturism-capabilities here>.
-- 
   Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!]
                  public UNIX source archive [HST V.42bis]:
        scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
                     uucp scuzzy!/src/README /your/home