Modified version of this patch applied by Tom.
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Oct 16, 2005 at 04:06:04PM -0400, Andrew Dunstan wrote:
Martin,
Let's see the patch. I assume
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Oct 16, 2005 at 04:06:04PM -0400, Andrew
On Mon, Oct 24, 2005 at 08:20:07AM -0400, Bruce Momjian wrote:
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Is this official blessing for the idea that psql should ignore SIGINT
while the pager is running? Or does this mean the idea
Martijn van Oosterhout wrote:
On Mon, Oct 24, 2005 at 08:20:07AM -0400, Bruce Momjian wrote:
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Is this official blessing for the idea that psql should ignore SIGINT
while the pager
Andrew Dunstan [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
On Mon, Oct 24, 2005 at 08:20:07AM -0400, Bruce Momjian wrote:
This has been saved for the 8.2 release:
Is this official blessing for the idea
AFAIK it's Bruce's way of not losing track of the patch,
Exactly. Held for
On Sat, Oct 22, 2005 at 02:48:53PM -0700, Sean Utt wrote:
Except that if I am in less, and I do CONTROL-C, it doesn't do anything at
all.
It doesn't exit.
If I send a kill -2 to the process, it doesn't exit. less ignores SIGINT
completely.
Not quite, It interprets it as abort command.
Sean Utt wrote:
If you send a recent version of vim a CONTROL-C, and you're just sitting
there at a prompt, it gives you a hint:
Type :quitEnter to exit Vim
Any reason not to just trap the CONTROL-C in psql when paging and offer a
hint? Especially since we don't really know that the
On Fri, Oct 21, 2005 at 05:28:49PM -0700, Kevin Brown wrote:
When a pager is being used, we check for the flag immediately after
doing a write()/fwrite() to the pipe. If it's set, we pclose(), clear
the flag, and then manually invoke the non-pager signal handler.
SIGINT should cause the
On Sun, Oct 16, 2005 at 03:25:49PM +0200, Martijn van Oosterhout wrote:
This behaviour has been around so long that I've gotten used to it but
I've always considered it a bug. Yet it has never been fixed so I'm
going to ask if anybody else has issues with this behaviour.
I've posted a patch to
On Sat, Oct 22, 2005 at 09:46:32PM +0200, Martijn van Oosterhout wrote:
I've posted a patch to -patches which fixes all the memory leak and
file descriptor leak issues and well as making psql handle ^C more
gracefully in general. It doesn't address this particular issue though,
thats for
It won't work properly that way. SIGINT gets sent to all the members
of the process group, not just the child. Psql isn't responsible for
sending ctrl-c through to the child.
Except that if I am in less, and I do CONTROL-C, it doesn't do anything at
all.
It doesn't exit.
If I send a
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
On Thu, Oct 20, 2005 at 08:11:14PM -0400, [EMAIL PROTECTED] 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
On Fri, Oct 21, 2005 at 01:53:32PM +0200, Martijn van Oosterhout wrote:
On Thu, Oct 20, 2005 at 08:11:14PM -0400, [EMAIL PROTECTED] 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
On Fri, Oct 21, 2005 at 08:48:31AM -0400, [EMAIL PROTECTED] wrote:
Which other ones? I can't think of one. The ones that don't handle
SIGINT, or that are not designed for this scenario certainly don't count -
as that is how psql works right now without the patch. Of the remaining
programs that
[EMAIL PROTECTED] wrote:
On Thu, Oct 20, 2005 at 03:42:10PM -0700, Kevin Brown wrote:
Martijn van Oosterhout wrote:
You can't do a pclose in a signal handler, it's not one of the
reeentrant safe functions and could lead to deadlocks. The signal
manpage documents the ones you can use.
If you send a recent version of vim a CONTROL-C, and you're just sitting
there at a prompt, it gives you a hint:
Type :quitEnter to exit Vim
Any reason not to just trap the CONTROL-C in psql when paging and offer a
hint? Especially since we don't really know that the user really wanted to
Andrew - Supernews wrote:
On 2005-10-19, Kevin Brown [EMAIL PROTECTED] wrote:
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
I failed to mention that I also tend to type CONTROL-C when I forget that
putty acts like an xterm, and doesn't need CONTROL-C to copy text into the
clipboard. In that case, aborting the pager, and leaving the terminal
trashed requiring me to exit psql, stty sane, and start up psql again is
really
Martijn van Oosterhout wrote:
You can't do a pclose in a signal handler, it's not one of the
reeentrant safe functions and could lead to deadlocks. The signal
manpage documents the ones you can use. Just set a flag. Setting the
descriptor to NULL is worse because then we have check before
On Thu, Oct 20, 2005 at 03:42:10PM -0700, Kevin Brown wrote:
Martijn van Oosterhout wrote:
You can't do a pclose in a signal handler, it's not one of the
reeentrant safe functions and could lead to deadlocks. The signal
manpage documents the ones you can use. Just set a flag. Setting the
On 2005-10-19, Kevin Brown [EMAIL PROTECTED] wrote:
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
I run into this problem sometimes, especially when I realize that
the query I've just started is going to run for a very long time and
not really provide anything useful. I find that I have to close the
shell window to get out of it, and I'm always a bit uncomforatble
doing that.
-Kevin
On Tue, Oct 18, 2005 at 05:15:20PM -0500, Kevin Grittner wrote:
I run into this problem sometimes, especially when I realize that
the query I've just started is going to run for a very long time and
not really provide anything useful. I find that I have to close the
shell window to get out of
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.
Martijn van Oosterhout kleptog@svana.org writes:
This problem has been around for ever yet obviously not everybody runs
into it all the time like I do. Would patch to fix this be accepted or
is there a reason why not?
I guess everybody else uses q not control-C to get out of less ;-)
I'm not
On Sun, Oct 16, 2005 at 02:44:41PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
This problem has been around for ever yet obviously not everybody runs
into it all the time like I do. Would patch to fix this be accepted or
is there a reason why not?
I guess
Martijn van Oosterhout wrote:
The point is, less is still running but psql it pulling the keystrokes
from under it... When you finally quit less it does restore the
settings, but now readline doesn't expect that as it's changed them
again...
Martin,
Let's see the patch. I assume it
Martjin,
This problem has been around for ever yet obviously not everybody runs
into it all the time like I do. Would patch to fix this be accepted or
is there a reason why not?
Actually, I run into it fairly often when I'm being hasty. I'd imagine most
Linux-based newbies do as well.
--
On Sun, Oct 16, 2005 at 04:06:04PM -0400, Andrew Dunstan wrote:
Martin,
Let's see the patch. I assume it should be fairly small. If we could get
it in early in the 8.2 cycle we would have plenty of time to bang on it.
In principle this sounds reasonable to me, but psql can be broken quite
On Sun, Oct 16, 2005 at 01:57:13PM -0700, Josh Berkus wrote:
Martjin,
This problem has been around for ever yet obviously not everybody runs
into it all the time like I do. Would patch to fix this be accepted or
is there a reason why not?
Actually, I run into it fairly often when I'm being
31 matches
Mail list logo
