[ 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>