On Fri, Oct 21, 2005 at 05:06:45PM -0700, Kevin Brown wrote: > > I disagree that psql should make *any* assumptions about what SIGINT > > means to the child process. Consider less again, and Control-C used > > to abort a search. You are suggesting that Control-C should not only > > abort the search, but should also cut off the input from less. Less > > won't die. Less will just see a terminated input stream. What has been > > gained from this? Is this intuitive behaviour? > It's behaviour that's consistent with every other pipeline application > set I've ever seen.
I think you are looking at 'every other pipeline application that does nothing', and treating them as role models. :-) I'm completely writing off applications that don't handle SIGINT in some way, as psql already does this, and wouldn't need *any* change to work this way. Psql already works the way you are saying every other application you know of does. So, I'm not seeing your point. If psql is to change, it is because the current behaviour is impractical, and not for any other reason. What is the practical behaviour? I think there are other, better ways, to know that the pager is dead. One is SIGPIPE/EPIPE. A write to the pipe to the pager will error with EPIPE, and throw a SIGPIPE signal. The parent will also be notified with SIGCHILD when the child exits. In this way, we have two ways of knowing that the child is dead, without preventing SIGINT from being handled fully by the child, in a pager such as less, that defines SIGINT to mean something *different* than die or abort reading the input stream. The case that this would be a problem for me is - psql is outputting pages and pages of data. The pipe buffer becomes full (8192 bytes on Linux?), and psql blocks. The rest of the data is available, however, it has not yet been transferred to less. The user does some operation in less that might take some time, and then hits control-C. Less continues, but under your scheme, is faced with a terminated input stream. I'm not seeing why this is practical. I don't see the benefit of this. Other than the argument that other applications don't handle Control-C at all, and you think this is compatible with their behaviour, do you have any practical arguments for doing it this way? How is it working better than it does today? Why won't we have the same situation of less and psql both waiting for STDIN from the user exist after your suggestion to make psql close off the input stream sooner? I might just be really dense. But I want you to show me where I'm wrong before I give in. :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster