Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!ames!ucsd!sdcsvax!amos!hartung
From: hartung@amos.ling.ucsd.edu (Jeff Hartung)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: MKS Login
Summary: OK, but is it worth the hassle?
Keywords: MKS Toolkit login shell
Message-ID: <5427@sdcsvax.UCSD.EDU>
Date: 25 Oct 88 22:36:33 GMT
References: <824@kksys.UUCP> <930@proxftl.UUCP> <5410@sdcsvax.UCSD.EDU> <21629@watmath.waterloo.edu>
Sender: nobody@sdcsvax.UCSD.EDU
Reply-To: hartung@amos.UUCP (Jeff Hartung)
Distribution: na
Organization: Univ. of Calif., San Diego
Lines: 36

In article <21629@watmath.waterloo.edu> jagardner@watmath.waterloo.edu writes:
>How would you implement file protection and still allow regular DOS
>programs to work with the file system? They will do their file i/o
>through DOS (or BIOS), and there's nothing MKS can do (short of re-writing
>DOS) to make these programs obey any protection scheme.

Yes, you have a point.  However, with programs like login and chmod, etc. it
seemed to imply that this was the reason for the login shell.  Of course, if
one takes the time to read on, it is stated outright that this is not the case
and cannot be implemented, as you point out, under MS-DOS.  I guess it just
*seemed* that this should be so if one were to call it a login shell.

>I use the login shell to set up different environments for different projects.
>The home directory is set to a convenient place, aliases are set to make
>sense for that particular project (e.g., cc is aliased to the appropriate
>compiler with appropriate options), and environment variables can be set
>for the project (e.g., Microsoft C include and library paths).

I guess I'll have to admit that for this sort of application, the MKS login is
just what the doctor ordered, but have you not also run into problems with
programs that won't run when the Korn shell is used as command interpreter?  I
always seemed to be using COMMAND.COM rather than SH.EXE for this reason and
eventually gave up on setting up SH in either a login or AUTOEXEC.BAT and
simply invoke it when needed as a sub-shell, then exit when I'm done with it.
(Of course, this is why they give four ways to use the MKS Toolkit depending on
one's needs. :-)

Anyhow, thanks for enlightening me on applications that make sense with the
MKS login shell.  (By the ways, I think that you'll still have to agree that
*easy* is probably not the word one would use to describe the level of effort
needed to install the login. :-)

 --Jeff Hartung--  	
 Disclaimer: "Nobody here really cares what I think anyhow."
 ARPA - hartung@amos.ling.ucsd.edu          
 UUCP - !ucsd!ling!amos!hartung