Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!ncar!boulder!sunybcs!rutgers!bellcore!clyde!watmath!jagardner
From: jagardner@watmath.waterloo.edu (Jim Gardner)
Newsgroups: comp.binaries.ibm.pc.d
Subject: MKS Login
Keywords: MKS Toolkit login shell
Message-ID: <21629@watmath.waterloo.edu>
Date: 22 Oct 88 16:28:40 GMT
References: <824@kksys.UUCP> <930@proxftl.UUCP> <5410@sdcsvax.UCSD.EDU>
Reply-To: jagardner@watmath.waterloo.edu
Distribution: na
Organization: U. of Waterloo, Ontario
Lines: 21

In article <5410@sdcsvax.UCSD.EDU> hartung@amos.UUCP (Jeff Hartung) writes:
>The most disappointing feature was the login shell which I really wanted to
>work like a U*IX login shell, but which offered no file protection for
>individual users at all and seemed to be mostly a pain in the a**.  Sure, it
>might limit access somewhat, but it didn't seem to be worth the effort just to
>give different users a home directory and option of using "sh" vs COMMAND.COM.
>When I want to use the Korn shell, I run it from COMMAND.COM as a subshell.

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.

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).

No, DOS isn't Unix. There are still good uses for a login shell.

David Tanguay