Xref: utzoo comp.sources.wanted:2700 comp.sys.ibm.pc:9531 Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!husc6!bu-cs!madd From: madd@bu-cs.BU.EDU (Jim Frost) Newsgroups: comp.sources.wanted,comp.sys.ibm.pc Subject: Re: Need LOGIN Shell for MS-DOS Keywords: MSDOS Message-ID: <17389@bu-cs.BU.EDU> Date: 13 Dec 87 18:56:34 GMT References: <145@tsdiag.UUCP> Reply-To: madd@bu-it.bu.edu (Jim Frost) Organization: Boston University Distributed Systems Group Lines: 57 In article <145@tsdiag.UUCP> tom@tsdiag.UUCP writes: >I am looking for a shell that will let me force users of our office PC >to login (hey, they understand it better that way :-) >What would be nice (i can modify it, i could write but i'm lazy) >is for the system to boot and run \autoexec.bat and then go into >a login loop and when the users login run a "autoexec" from their >home directory to set up the commands and vars they need... I did this for a system of ours at home, and it turns out that it's considerably harder than you think, unless you want to hack command.com. Here's what you have to do. It's simple enough to make your login program start up with the shell= command in config.sys. The login program must exec command.com, which is also simple enough. The hard part is that there's no way to specify an autoexec.bat file specifically, and even if there was, you don't want the shell to be permanent (so that you can just drop back to your login program when they exit) which is currently the only way MS-DOS allows you to run a batch file and then go interactive. The way I did it was to exec command.com with the name of the autoexec file in their home directory. This is fine except that brain-damaged MS-DOS command.com doesn't provide any way to make the batch file stop executing and go into interactive mode. The only way I could get it to do this was to put a "command" command at the end of the autoexec.bat file. This invokes yet another command interpreter and puts it in interactive mode. The new command interpreter inherits the parent's environment, so everything's peachy. Problems: You have 2 command interpreters and your login program in memory at once. If properly designed, this isn't a big deal. The login program can be extremely small and command.com doesn't load all of itself in at once. Generally our system used about 40k. Our login program was large and sophisticated, though, performing accounting and usage functions as well as login functions. I could easily see an assembler login program taking up only 5 or 10K, including overhead. If you do this kind of set up, it will turn out to be a good idea to create programs that do such things as bring a user to his/her home directory. In over a year, we haven't had problems with this system. We have about 30 users in the passwd file (hey, I LIKE the way UNIX is set up :-) and our system is multiuser multitasking, allowing 5 logins at once. The only problem you are likely to encounter is with memory. If your machine is less than 640k, I'd recommend expanding it. After all, memory is pretty cheap nowadays. If you have any questions, comments, or ideas, please email to me. Good luck, jim frost madd@bu-it.bu.edu