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