Re: Question about Ctrl-C and less

Martijn van Oosterhout wrote:
> Very well, patch attached. It's quite simple actually. However, there
> seems to be some push back from people suggesting that jumping back to
> the main loop before the pager has quit is not buggy behaviour.
> Assuming that a ^C will kill the pager is just folly.

Making assumptions about what the pager will do upon receipt of SIGINT
is folly as well.

Setting up SIGINT to be ignored may be the right answer (I don't
believe it is -- see below), but if so then it needs to be done
properly.  If it gets ignored prior to the popen(), then the child
will also end up ignoring it by default, because signal disposition is
inherited by child processes.  If we ignore SIGINT, it should be after
the popen(), not before.


When the user sends SIGINT, he means to interrupt whatever processing
is currently occurring.  He expects to regain control of the
terminal.  If psql is in the process of sending data to the pager,
then a SIGINT should cause psql to stop doing so.

So I think the right answer here is for psql to handle SIGINT
internally by doing a pclose() first (and at this point, it probably
should ignore SIGINT altogether), then returning to the main loop
(and, of course, cleaning up anything that needs it along the way).
If the child hasn't exited then pclose() will block until it has.  The
end result should be the semantics you want: if psql is in the middle
of sending a bunch of rows of output to the pager, this will interrupt
that process.  If the pager remains running then it will hopefully
give the user the ability to scroll through whatever results were sent
to it.


> Tom asked if we should be blocking SIGQUIT and SIGHUP too. Standard
> procedure for spawning external interactive processes includes blocking
> SIGQUIT too (see system() manpage).

SIGQUIT has a different standard meaning in Unix than SIGINT: it
causes the process to drop core.  We should not be blocking it -- we
should be leaving it alone.  The reason is that it's quite possible
that the user wants to have psql generate a core file while it's
writing output to the pager.


> Logically speaking, when the user sends an interrupt from the
> keyboard they expect to interrupt the currently active *interaxtive*
> process.

They expect to interrupt the currently active processing.  Not quite
the same thing.


> Hence, once psql has spawned
> the pager, it should ignore such interrupts until control is returned
> (after pclose). So yes, I would suggest blocking SIGQUIT also, if only
> to prevent terminal corruption problems. Interactive programs like less
> trap SIGQUIT to restore the terminal settings on exit, but the exit
> anyway.

They should be dropping core upon receipt of SIGQUIT.  It might be
nice if they cleaned up the terminal first, but receipt of a SIGQUIT
generally means that the user wants to run the resulting core file
through a debugger, and trapping the signal could alter the stack such
that the resulting core would be less useful.  I'd rather have to
clean up the terminal manually than have an unusable core file.





-- 
Kevin Brown                          kevin@sysexperts.com