jagardner@watmath.waterloo.edu (Jim Gardner) (10/22/88)
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
hartung@amos.ling.ucsd.edu (Jeff Hartung) (10/26/88)
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
jagardner@watmath.waterloo.edu (Jim Gardner) (10/26/88)
In article <5427@sdcsvax.UCSD.EDU> hartung@amos.UUCP (Jeff Hartung) writes: >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? Actually, I haven't had this problem much. On the few occasions I do have it, I use two backslashes (from the shell) as a path separator. >(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. :-) I think earlier versions of MKS had a bug that made setup difficult. The version I have, 2.2, has a /etc/inittab file, which make setting up the login shell not much different from setting up an autoexec.bat. However, you do have to read the manual :-). David Tanguay
jans@tekgvs.GVS.TEK.COM (Jan Steinman) (10/28/88)
<...have you not also run into problems with programs that won't run when the Korn shell is used as command interpreter?...> Hey, if it won't run under ksh, I don't need it! I'm a Unix user first, and a MeSs-DOS user only when I must. Having similar environments is more important to me than being able to run every brain-damaged application. I've not found *any* commercial programs that don't run under ksh, and I don't need freeware/shareware/PD stuff so badly that I'll give up my environment. The biggest problem seems to be applications that make assumptions about memory use, which is not a problem with ksh, but a problem with *any* command interpreter used instead of COMMAND.COM. Why even have pluggable command interpreters if applications assume otherwise? I doubt that anything that flunks the ksh test would run under Windows, etc. :::::: Software Productivity Technologies -- Experiment Manager Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-383 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::