Subject: Re: bin/10879: su does not reset terminal settings after Ctrl-C
To: Robert Elz <kre@munnari.OZ.AU>
From: Greywolf <>
List: tech-userlevel
Date: 08/24/2000 10:29:01
On Fri, 25 Aug 2000, Robert Elz wrote:
#     From: (Greg A. Woods)
#   | #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.

For some reason, I'm inclined to disagree.  On a normal exit, yes it will
be restoring terminal modes, but not on a signal.  I think that's the
responsibility of the caller.  You could see that as a PITA, but right now,
libraries don't handle signals like that, not even curses.

# That and that getpass() is just blocking signals now, instead of
# catch, cleanup, and return.

...which seems to this dinosaur-by-osmosis to be completely wrong.

For me it was pretty much a fact of life whenever I aborted 'su' with
an interrupt or quit that I would have to reset my terminal.  I didn't
even see this nonsense in the mtXINU 4.3/more distribution (of which
the last distribution we received was just pre 4.3-reno :-).

#   | Of course users of getpass() must be fixed up to catch SIGINT and to
#   | properly reset the terminal modes when it is triggered....
# No, if getpass() is going to meddle it is getpass()'s job to unmeddle.

Not in the case of signals.  It clutters up the code.  getpass() should
be a clean quick manner of getting a password.  I mean, okay, I've
written getpass() from scratch before (because I didn't know about
getpass() :-).  I didn't even take signal handling into account inside

#   | The code in 4.3BSD-Reno has the comment:
#   | 
#   |         /*
#   |          * note - blocking signals isn't necessarily the
#   |          * right thing, but we leave it for now.
#   |          */
# That's also true - it is just the easy way, and close enough...

It's annoying as hell, though.

#   | beginning of the line so now I have to use ^U^D instead.
# Or ^D^D perhaps.   But ^C\n works for me (it is certainly close enough).

See notes on csh, sh.  ^D^D does different things there.

[but then, that's not exactly the tty driver at work, there; cat and grep
and sed and awk are probably better examples of this...]

"Never mind the bollocks, here's BSD!"