peggy@pyr.gatech.EDU (Cris Simpson) (02/12/90)
I heard someplace (don't remember where) that root should not have /bin/ksh as the login shell. Is this true? Why? This may have come from a(n?) HP publication. Thanks, cris
jc@minya.UUCP (John Chambers) (02/13/90)
In article <9872@pyr.gatech.EDU>, peggy@pyr.gatech.EDU (Cris Simpson) writes: > > I heard someplace (don't remember where) that root should not > have /bin/ksh as the login shell. Is this true? Why? > > This may have come from a(n?) HP publication. It may be because of problems like I've seen recently on some DECstations where we installed tcsh. Several users liked it so much that they made it the login shell of all the system pseudo-users, including root. Then they tried editing the password file with vipw. When they said to :w their changes, vipw refused, on the grounds that root had an illegal shell. It seems that vipw likes to "protect" you from producing a bogus root account, and it does so by having hard-coded names of allowed shells. Investigation showed that vipw is a compiled program, so unless you have the source, you can't use any shells for root except those on its very short list. Or you can do as most of these users have done, and just change the passwd file with vi or emacs. So much for that attempt to hold the users' hands. [Now let's see if this newly-installed level 18 news will post a followup correctly...] -- John Chambers ...!{harvard,ima,mit-eddie}!minya!jc [Sorry, no clever saying today.]
jws@hpcljws.HP.COM (John Stafford) (02/14/90)
There was a version of the HP-UX operating system that had a "misfeature" in ksh that would make your life unpleasant when you tried to shut the system down as root, if ksh was your shell, and job control was enabled. I don't remember the exact details, but you ended up, I think with two shells trying to talk to your terminal. It wasn't the most horrible of defects, but it wasn't any fun to run into when trying to shut your system down, especially if you were trying to deal with some other sort of problem. The current version of HP-UX (version 7.0) does not have this defect (to the best of my knowledge). Other than that, if HISTFILE is defined, and you are logged in as root using ksh to repair file systems, the writing of the history file could interfere with your repair. By default, ksh being run by root is not supposed to write history, you have to set HISTFILE before ksh starts (or in .profile) to make it happen (and you obviously don't want to do it if your filesystems are sick). Don't everybody tell me that ksh doesn't handle history files right and/or that root can write history files without HISTFILE set but can't edit them; I believe you, I just suspect that some ksh's are buggier than others (and I still like it).