dmr (07/21/82)
Mark Horton's solution to problems he finds with csh deserve some comment. The problems, as I remember them, were 1) that csh is sometimes noisy when executing su, and 2) that the history in the main shell is not transmitted to the su subprocess. The proposed solution was 1) write a program that scribbles on /dev/kmem, and 2) hack the system so that the scribbling would actually do what it was intended to do. The proposed solution is terribly objectionable on a number of accounts. First, and most important, it uses very powerful medicine in the wrong place and for the wrong reason. If csh has bugs or misdesign, fix it or live with it. Don't change the operating system to evade the issue. Second, writing on /dev/kmem is in fact quite dangerous, as well as nonmodular, unclean, and all the other nonbuzzwords. (Renice is not one of the loveliest parts of the Berkeley system) Third, the dangerous, powerful technique is being used to do something that is already quite possible (namely su). The renice command has at least the modest virtue of performing a new function. Fourth, I am dubious about the actual change that was made to the system. (copy p->p_uid to u.u_uid in the wait system call. Can you imagine the amazing comment that must surely be present here?). It is by no means obvious that the change is harmless to the functioning of the system, though possibly it is. Fifth, doing things like this in order to make su quick and easy to use is heading in the wrong direction. If anything, su should be made more clumsy and harder to use, in order to encourage people to arrange user and group IDs in appropriate ways. If you find that you have to spend a lot of time in su, you are doing something wrong. All in all, a thoroughly bad deal. If I were system administrator on his machine, I would change the su password instantly. Dennis Ritchie
ARPAVAX:mo (07/23/82)
Dennis is exactly right. Scribbling on memory, or even rooting around in there is WRONG. If the renice function is useful, why not make it a system call; it has been in the Purdue version of Unix for over 4 years now. Even more disgusting is having to recompile thins w ~v
greep@Rand-Unix@sri-unix (08/19/82)
Date: Sunday, 8 Aug 1982 00:33-PDT Re: "If anything, su should be made more clumsy and harder to use..." The fact that running as su is risky is a good reason for making it easy to go in and out of su mode when you are doing things that require it, such as modifying programs that run suid-root, since the alternative is just staying in su mode for long periods of time (which some people do). (My solution to this is simply to run su once, then do "su greep" to get out of su and control-D to get back in, but that doesn't handle the environment problem.) [Other than this, I agree completely with your message.]
thomas (08/20/82)
If your su runs csh, then the 'suspend' command will stop the shell and return you to the parent csh (don't do it under sh, though). =Spencer
kiessig (09/21/82)
#R:sri-unix:-277700:fortune:11600004:000:409 fortune!kiessig Aug 19 13:26:00 1982 The way I handle su seems to work fairly well: su once, and then say "stop $$" (only on 4.1BSD, of course), which returns me to my non-su csh. "fg" then makes me su again. This can be carried levels of shells (i.e. "su user" from the su shell, followed by another "stop $$"). The only disadvantage is that you can loose context if you have too many shells. Changing their prompts helps... Rick Kiessig