Subject: Re: bin/10879: su does not reset terminal settings after Ctrl-C
To: Robert Elz <kre@munnari.OZ.AU>
From: Greywolf <greywolf@starwolf.com>
List: netbsd-bugs
Date: 08/24/2000 10:29:01
On Fri, 25 Aug 2000, Robert Elz wrote:
# From: woods@weird.com (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
getpass().
# | 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...]
--*greywolf;
--
"Never mind the bollocks, here's BSD!"