In any case it sounds like the theme of "stop blocking any signals, fix
the man page and except userland code to cope if they want to worry about
terminal state" is the way to go.

Any other solution involves signal handlers in library code which is
disgusting or just plain non-obvious behavior when trying to abort from su.

Patching this (and the relevant userland code) shouldn't take more than a
couple of hours so I'll take a crack at a patch sometime this weekend and
send it in.

James

>
>[ On Thursday, August 24, 2000 at 12:37:22 (-0400), James Chacon wrote: ]
>> Subject: Re: bin/10879: su does not reset terminal settings after Ctrl-C
>>
>> >
>> >  | #2 is possible, but a little yucky as you say.  It's also probably about
>> >  | as hard to get right as my #5 too.
>> >
>> >It shouldn't be, that way (have getpass() catch signals and DTRT) is
>> >the correct solution.
>> >
>> >Anything which is messing with the terminal state should be doing that.
>> 
>> Actually I disagee that any library routine should start engaging signal
>> handlers. Absolutely nothing in the libary does so today (that I could find
>> with a quick scan) so this would be a pretty radical departure to start doing.
>
>That's partly why I didn't like the idea, and the way you say it makes
>it an even more powerful reason.
>
>> Plus, what are you going to do with a SIGINT? Clean up and then either call
>> the old handler or exit? Exiting from a library routine is even worse. That's
>> a prime example generally of bad bad design.
>
>For the purpose of academic discussion I think that in the case of
>getpass() the best thing to do would be to clean up and then call the
>old handler, or if there was no old handler to just return NULL.
>
>> Actaully no. By blocking it creates behavior that I've never seen on any 
>> other system I've tried to run su on. Everything else either su catches the
>> signal and fixes stuff or it leaves the terminal in non-echo mode. But, it
>> doesn't require ^C\n anywhere else I've seen to abort.
>
>I don't even remember encountering any version that didn't restore the
>terminal modes, certainly not of the AT&T derrived variants subsequent
>to System V Release 3 or so.  I've just experimented with SunOS-5.6 and
>it seems to restore terminal modes just fine.  Someday I should
>re-install my 3B2 so it's handy for such tests....
>
>-- 
>							Greg A. Woods
>
>+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
>Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
>
>
>
>