tom@tsdiag.UUCP (12/10/87)
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... if i come up dry and i get requests i will forward what i end up with to those who ask c'ya -- Thomas A. Moulton, W2VY Life is too short to be mad about things. Home: (201) 779-W2VY Packet: w2vy@kd6th Voice: 145.190 (r) Work: (201) 492-4880 x3226 FAX: (201) 493-9167 Concurrent Computer Corp. uucp: ...!ihnp4!hotps!ka2qhd!w2vy
wheels@mks.UUCP (Gerry Wheeler) (12/11/87)
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... > -- > Thomas A. Moulton, W2VY Life is too short to be mad about things. > Home: (201) 779-W2VY Packet: w2vy@kd6th Voice: 145.190 (r) > Work: (201) 492-4880 x3226 FAX: (201) 493-9167 > Concurrent Computer Corp. uucp: ...!ihnp4!hotps!ka2qhd!w2vy You'll find almost exactly what you want in the MKS Toolkit. By using our programs init, login, and sh, each user gets to log in, gets his own home directory, and gets his own profile. It's a neat solution for those PC's that are shared by several people. The only real change you would have to make is to translate autoexec.bat to a shell script. They're look different, but you should be able to do all the same things. You get to use three different scripts: /etc/rc.ksh is run once before the first login (for installing TSR's, setting comm ports, etc.), then each user's shell runs /etc/profile.ksh (for default path definition, etc.) and profile.ksh in the home directory (to personalize the environment). One extra feature is that init "memorises" the state of the machine, then restores it between logins. This means that a user can load his favourite TSR in his own profile.ksh, and it will be removed before the next user logs in. Send me a message if you need more details. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 43 Bridgeport Rd. E. BIX: join mks Waterloo, Ontario N2J 2J4 CompuServe: 73260,1043
dave@westmark.UUCP (Dave Levenson) (12/13/87)
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... There are a number of PC Security systems on the market. Some of these not only enforce a login, but protect the hard disk from access by anyone who has not logged in, even if they reboot the system from a floppy! Watchdog(tm) is one such package. Check out PC Magazine's back pages for advertisements. Westmark includes such a capability in our MONEY-ROOM(tm) package (an MS-DOS based banking application) but it is tied to the menuing system and the application database. I don't know if it's available separately. -- Dave Levenson Westmark, Inc. A node for news. Warren, NJ USA {rutgers | clyde | mtune | ihnp4}!westmark!dave
wtm@neoucom.UUCP (Bill Mayhew) (12/13/87)
The latest release of MKS Toolkit includes the Korn shell. It is a pretty clean port of the Unix version. The whole toolkit is somewhere around $US 200. I think it is possible to get the toolkit unbundled, but getting the whole thing is probabably the most cost effective. It also includes a nice port of the vi editor and awk. A while back somebody (from MKS I believe) posted an 8088 assembler written in awk. You can run the korn shell from command.com (my choice), or if you are hard core, you can rig command.com to enter ksh directly and set it up for a login prompt. It isn't unix, but it ani't too bad. Add uupc (pc mail) from the net, and you've got a pretty neat environment. I think you can correspond with them at tookit@mks.UUCP. I case you wondered, I don't have any financial (or other) intereset in MKS. Only have used the product. --Bill
madd@bu-cs.BU.EDU (Jim Frost) (12/14/87)
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
ugfailau@sunybcs.uucp (Fai Lau) (12/14/87)
In article <17389@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >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. > Why don't you do this? Issue a "rename" at the end of the *default* autoexec.bat to change its name, and issue another "rename" to change the name of another bat file to autoexec.bat, which is to be brought in for another command shell. If you want to bring the default batch file back, you can still issue another pair of rename at the end of the other batch file. By manipulating the name of the autoexec.bat within autoexec.bat, you can control which batch file is to be used when the next command shell is invoked. You can even copy the autoexecs in the user directories to the default autoexec.bat and then load up the shell, and stick another copy at the end of the file to undo the copy. Of course, this doesn't solve the problem of having two shells in the system. If there is a way to "substitute the current shell with a new shell...., but then the login program in the first shell may have to be lost. I only have experience in UNIX multitasking in PC, so I can't say much about MS-DOS multi- user environment. >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. > No problem. Fai Lau SUNY at Buffalo (The Arctic Wonderland) UU: ..{rutgers|ames}!sunybcs!ugfailau BI: ugfailau@sunybcs INT: ugfailau@cs.buffalo.EDU
madd@bu-cs.BU.EDU (Jim Frost) (12/14/87)
In article <7216@sunybcs.UUCP> ugfailau@joey.UUCP (Fai Lau) writes: >In article <17389@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: [method of doing a login... see referenced articles] > > Why don't you do this? Issue a "rename" at the end of >the *default* autoexec.bat to change its name, and issue >another "rename" to change the name of another bat file to >autoexec.bat, which is to be brought in for another command >shell. [stuff on restoring the original autoexec.bat and related topics deleted] >Of course, this doesn't solve the problem of >having two shells in the system. If there is a way >to "substitute the current shell with a new shell...., >but then the login program in the first shell may >have to be lost. I only have experience in UNIX multitasking >in PC, so I can't say much about MS-DOS multi- >user environment. Ok, one thing at a time. This is a dandy idea but it has several flaws. Our system is multitasking. What would happen if two users logged on at once? It wouldn't even have to be too close, either, given the amount of time it'll take command.com to get through an autoexec.bat file of any complexity. (BTW, we don't have UNIX multitasking. We have one PC running 5 processors. Basically a bus-oriented LAN with diskless workstations.) This wouldn't matter if you have a single-user system, but there are other problems. Also, issuing a command.com /p (permanent) to allow a shell to become permanent and to allow the shell to switch to interactive mode makes life real difficult when you're trying to log out. The only easy way to do it is to reboot, often a painfully slow process. Another flaw is that we wanted to keep things simple. Each user has his/her own directory. We wanted their autoexec.bat file THERE so that they could always see it and modify it to boot. Essentially their home directory was "root" so far as they were concerned. All we have to do with our system is make sure they know that that last line in the autoexec.bat file (command.com) is SUPPOSED to be there. You might note that my system of doing things makes it easy to run programs as you log out, too, since anything after the line that calls command.com will be run when command.com exits. Basically .login and .logout in a single file.... >Fai Lau jim frost madd@bu-it.bu.edu "I wasn't wrong. Just inaccurate."
walt_waldo_novinger@cup.portal.com (12/16/87)
I would heartily recommend the MKS Toolkit from Mortise Kern Systems
({allegra,decvax,ihnp4}!watmath!mks!toolkit) for those users who want
a true login shell capability. The shell provided *replaces*
command.com (rather than supplementing it as another responder
suggested). The Toolkit comes with a vi look-alike, awk, grep, and
at least 60 other Unix-style tools. I work on Unix systems every
day (Sys 3 and 5) and am *very* impressed at the job MKS has done
in reverse engineering these programs.
I was a beta tester for MKS, and can attest to their orientation
toward users and their *fast* response to problems and (especially)
suggestions. Other than being a satisfied user, I have no stake in MKS.
======================================================================
Walt Novinger sun!cup.portal.com!waldo "The real world is
InterFile Corp. waldo@cup.portal.com NOT user-friendly"
755 N. Mary Ave. (408) 738-3900 W Kelvin Throop
Sunnyvale, CA 94086 (415) 964-9377 H
GMT
References: <145@tsdiag.UUCP>
Reply-To: madd@