i'm pretty sure this is because bash and tcsh create their own process group at startup, and zsh doesn't... so zsh shares the same process group as the su process.
suppose we have this pstree fragment: zsh(4782,dean)---su(4788,root)---zsh(4789) both pids 4788 and 4789 have pgrp 4788. when zsh suspends itself it sends SIGTSTP to -4788. this TSTP hits both zsh(4789) and su(4788) -- which causes zsh(4782) to finish its waitpid (it was waiting on su(4788)). note that su(4788) has been stopped here *before* it issues raise(SIGSTOP). then a while later when you type "fg" in zsh(4782), it sends a CONT to -4788, which wakes both 4788 and 4789... now unfortunately the su continues on in the new 356_su-stop_cont-proxy patch ... it finally gets to do its raise(SIGSTOP)... and presto, that wakes up zsh(4782) again... and now both zsh processes are awake and fighting for the tty. i think su should be creating a new process group for its child... unfortunately when i throw in a setpgrp() in the child it's still not sufficient -- after a couple suspend/fg cycles i get into the same problem. hmm. -dean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]