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 a
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
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
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 ide
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 Duns
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 co
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
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 kill
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 an
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
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 wr
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 :quit 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
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
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
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 :quit 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
type CONT
[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 y
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 t
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
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,
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. Settin
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 Wed, Oct 19, 2005 at 04:24:21AM -0700, Kevin Brown wrote:
> It does? It looked to me like it was setting the signal handler to
> SIG_IGN before doing the popen(), and resetting it to the internal
> signal handler after doing the pclose().
Oops, you're right. It works because less sets it's own
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 i
Martijn van Oosterhout wrote:
> On Tue, Oct 18, 2005 at 09:32:25PM -0700, Kevin Brown wrote:
> > 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 lo
On Tue, Oct 18, 2005 at 09:32:25PM -0700, Kevin Brown wrote:
> 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 anyt
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.
M
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
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
>>> Mar
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'
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 qu
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.
--
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 shou
On Sun, Oct 16, 2005 at 02:44:41PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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 els
Martijn van Oosterhout 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 sure I agree
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.
Reproducing it is easy:
1. Set PAGER=less
2. Start psql
3. Type: \df
4. When output appears, hit
35 matches
Mail list logo
