jce (06/22/82)
our 4.1bsd csh always seems to prompt when spawned from other processes, even when we don't want it to. For instance, when we do ~|fmt inside mail, we have to look at two gross csh prompts. I suspect it comes from incorrect handling of -c or checking for interactive input incorrectly. Has anybody fixed this already? John Eldridge harpo!floyd!jce
mark (06/22/82)
This is a well known misfeature of csh. The offical fix is to fix your .cshrc, as follows: if ($?prompt) then set prompt='My Prompt ' set mail=/usr/spool/mail/me endif that is, only set prompt and mail if you already have a prompt set. Otherwise shell escapes cause all sorts of interesting things to happen. Mark
G:tut (06/22/82)
There is another fix besides "if ($?prompt) set prompt = "myprompt". You can set the prompt in your .login file, in which case only your login shell has a custom prompt. This fix is OK for those (like me) who do most of their work in the login shell. It has the advantage of making your .cshrc file faster, which results in faster shell escapes and faster execution of csh scripts. Not only that, you can tell the difference between the login shell and subshells. Bill Tuthill
Physics:crl (06/22/82)
We had the same problem with csh prompts in non-interactive mode a while ago, and we did eventually figure it out. If you set your prompt explicitly in your .cshrc, then csh will output it even if it is a non-interactive shell. The correct way to do this is: if ($?prompt) set prompt = . . . In fact, I use the 'if' statement to enclose almost all of my .cshrc. That way, all the initialization i do doesn't occur when I run a shell script. Charles LaBrec Purdue Univ.
gb (06/22/82)
There is yet another way to avoid .cshrc problems. Don't have one. I have been operating for about a year without a .cshrc with no ill effects. I just use ^Z to escape into my login shell rather than activating subshells.
trb (06/23/82)
Suspending to login shell is fine with no .cshrc, but what do you do when you spawn superuser shells? That brings up the real question. Wouldn't it be nice if su just changed the state of the current shell rather than spawning a new one. History, etc would be preserved thru the transitions. Ooh ah. That's what I want. And then I could chuck my .cshrc forever. Andy Tannenbaum Bell Labs Whippany, NJ (201) 386-6491
mark (06/23/82)
Andy has an interesting idea. It ought to be trivial for the su command to, instead of exec'ing a subshell, to scribble on /dev/kmem to make itself a new uid. Then to get back you would have to do another su, or maybe have an alias for it or have a link "unsu" for going back. Has anybody out there tried this, with good or bad results? Seems to me that, in addition to the history advantage Andy cites (how many times have you tried to do something, have the system deny permission, su, and have to type it in again?) it should be faster (no .cshrc or hashing for the shell). It would be harder to toggle back and forth, however, than using "suspend" and "%su". Maybe it could set a bit in the proc table someplace so you wouldn't have to give the password again. Mark
ARPAVAX:CAD:ESVAX:Cory:cc-18 (06/27/82)
I also use no .cshrc, and no .logout file (I alias 'logout' to '...; ...; exec cat .logo'. Not only do I not have ugly prompts showing up, but my subshells run a lot faster! Michael Chastain ucbvax!Cory:cc-18 (UUCP) Cory.cc-18@Berkeley (ARPA)