Thread: psql screen size
I'm using psql mainly in putty window. I have a problem while resizing the window. When changing the window size (and those chars per row) psql output becomes mess, the only rescue is to exit and run the psql again. It looks like it's initializing the output params at startup and don't refresh it in runtime. Is there any way to deal with it? Or maybe some patch to psql could be applied? If shell console or vi can work this way why not psql?
wstrzalka wrote: > I'm using psql mainly in putty window. > > I have a problem while resizing the window. > When changing the window size (and those chars per row) psql output > becomes mess, the only rescue is to exit and run the psql again. It > looks like it's initializing the output params at startup and don't > refresh it in runtime. > Is there any way to deal with it? Or maybe some patch to psql could be > applied? If shell console or vi can work this way why not psql? It appears to work fine for everyone else. You'll have to do some more research and/or provide more details about the platform and package at the other end of the putty connection.
On Mon, Oct 27, 2008 at 01:59:42AM -0700, wstrzalka wrote: > I'm using psql mainly in putty window. it's pretty much always just worked with me. I'm using a very old version of putty, but it all hangs together as well as anything else does > When changing the window size (and those chars per row) psql output > becomes mess, the only rescue is to exit and run the psql again. It > looks like it's initializing the output params at startup and don't > refresh it in runtime. Resizing the window when entering SQL works OK for me, but resizing when inside my pager (normally the "less" utility, when you get more results than will fit on the screen) causes psql to be confused when I return to it. Exactly the same bug occurred in various shells a while ago and was fixed (I believe) by getting them to inquire about the screen dimensions far more than they strictly ought to be doing. I'd also guess that psql doesn't know or care about the screen size as it's all handled by the "readline" library. Sam
On 27 Paź, 13:16, s...@samason.me.uk (Sam Mason) wrote: > On Mon, Oct 27, 2008 at 01:59:42AM -0700, wstrzalka wrote: > > I'm using psql mainly in putty window. > > it's pretty much always just worked with me. I'm using a very old > version of putty, but it all hangs together as well as anything else > does > > > When changing the window size (and those chars per row) psql output > > becomes mess, the only rescue is to exit and run the psql again. It > > looks like it's initializing the output params at startup and don't > > refresh it in runtime. > > Resizing the window when entering SQL works OK for me, but resizing when > inside my pager (normally the "less" utility, when you get more results > than will fit on the screen) causes psql to be confused when I return to > it. > > Exactly the same bug occurred in various shells a while ago and was > fixed (I believe) by getting them to inquire about the screen dimensions > far more than they strictly ought to be doing. I'd also guess that psql > doesn't know or care about the screen size as it's all handled by the > "readline" library. > > Sam > > -- > Sent via pgsql-general mailing list (pgsql-gene...@postgresql.org) > To make changes to your subscription:http://www.postgresql.org/mailpref/pgsql-general Yes. This is exactly the case. When I browse large paged query result and resize during that, the screen is messed up.
wstrzalka <wstrzalka@gmail.com> writes: > On 27 Paź, 13:16, s...@samason.me.uk (Sam Mason) wrote: >> On Mon, Oct 27, 2008 at 01:59:42AM -0700, wstrzalka wrote: >> >> > When changing the window size (and those chars per row) psql output >> > becomes mess, the only rescue is to exit and run the psql again. It >> > looks like it's initializing the output params at startup and don't >> > refresh it in runtime. At least in CVS HEAD it checks before every query output. However... >> Resizing the window when entering SQL works OK for me, but resizing when >> inside my pager (normally the "less" utility, when you get more results >> than will fit on the screen) causes psql to be confused when I return to >> it. > > Yes. This is exactly the case. When I browse large paged query result > and resize during that, the screen is messed up. Could you define "messed up"? What I see is that the query output is formatted correctly but readline still thinks the screen is the old size. (This is in CVS HEAD -- this code was definitely different in 8.3 and before so the behaviour may be different). Perhaps we need to tell readline whenever we run a subprocess and it may have missed screen resize signals. It's easy enough to work around, just resize the window again a little bit once you're at the prompt. Readline notices that and adjusts. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
Gregory Stark <stark@enterprisedb.com> writes: > Could you define "messed up"? > > What I see is that the query output is formatted correctly but readline still > thinks the screen is the old size. (This is in CVS HEAD -- this code was > definitely different in 8.3 and before so the behaviour may be different). > > Perhaps we need to tell readline whenever we run a subprocess and it may have > missed screen resize signals. Hm, this Bash FAQ seems to indicate this shouldn't be a problem -- the whole process group is supposed to get the window size. Psql isn't doing the job control stuff the FAQ entry talks about so the pager ought to be in the same process group. So I'm puzzled. http://tiswww.case.edu/php/chet/bash/FAQ -> E11) If I resize my xterm while another program is running, why doesn't bash -> notice the change? -> -> This is another issue that deals with job control. -> -> The kernel maintains a notion of a current terminal process group. Members -> of this process group (processes whose process group ID is equal to the -> current terminal process group ID) receive terminal-generated signals like -> SIGWINCH. (For more details, see the JOB CONTROL section of the bash -> man page.) -> -> If a terminal is resized, the kernel sends SIGWINCH to each member of -> the terminal's current process group (the `foreground' process group). -> -> When bash is running with job control enabled, each pipeline (which may be -> a single command) is run in its own process group, different from bash's -> process group. This foreground process group receives the SIGWINCH; bash -> does not. Bash has no way of knowing that the terminal has been resized. -> -> There is a `checkwinsize' option, settable with the `shopt' builtin, that -> will cause bash to check the window size and adjust its idea of the -> terminal's dimensions each time a process stops or exits and returns control -> of the terminal to bash. Enable it with `shopt -s checkwinsize'. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
On Mon, Oct 27, 2008 at 3:59 AM, wstrzalka <wstrzalka@gmail.com> wrote: > I'm using psql mainly in putty window. > > I have a problem while resizing the window. > When changing the window size (and those chars per row) psql output > becomes mess, the only rescue is to exit and run the psql again. It > looks like it's initializing the output params at startup and don't > refresh it in runtime. > Is there any way to deal with it? Or maybe some patch to psql could be > applied? If shell console or vi can work this way why not psql? I see this once in a while with ssh sessions from linux to linux. But usually everything is worse on windows :-). merlin
Gregory Stark escribió: > Hm, this Bash FAQ seems to indicate this shouldn't be a problem -- the whole > process group is supposed to get the window size. Psql isn't doing the job > control stuff the FAQ entry talks about so the pager ought to be in the same > process group. So I'm puzzled. How do you know that the pager is in the same process group? Is the process group something that's inherited automatically on fork()? The setsid() manpage says so, but maybe we're missing something else. I can confirm that when the pager is open, psql does not resize properly. Maybe psql is ignoring signals while the pager is open, or something. Hmm, a quick experiment (8.3) reveals that psql doesn't seem to do anything if I SIGWINCH it manually while the pager is open ... -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> How do you know that the pager is in the same process group? Is the
> process group something that's inherited automatically on fork()?
It certainly should be.
> I can confirm that when the pager is open, psql does not resize
> properly. Maybe psql is ignoring signals while the pager is open, or
> something.
If the pager is running, psql's not going to do anything anyway, no?
What behavior are you expecting?
regards, tom lane
Tom Lane escribió: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > I can confirm that when the pager is open, psql does not resize > > properly. Maybe psql is ignoring signals while the pager is open, or > > something. > > If the pager is running, psql's not going to do anything anyway, no? > What behavior are you expecting? I am expecting that when control gets back to it, it has updated its notion of terminal size. Obviously I don't want anything _visible_ to happen at that point to psql. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>> Alvaro Herrera <alvherre@commandprompt.com> writes: > >> > I can confirm that when the pager is open, psql does not resize >> > properly. Maybe psql is ignoring signals while the pager is open, or >> > something. Hm, system() is documented to ignore SIGINT and SIGQUIT I wonder if it's (erroneously?) ignoring SIGWINCH as well. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
Gregory Stark <stark@enterprisedb.com> writes:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> I can confirm that when the pager is open, psql does not resize
>> properly. Maybe psql is ignoring signals while the pager is open, or
>> something.
> Hm, system() is documented to ignore SIGINT and SIGQUIT I wonder if it's
> (erroneously?) ignoring SIGWINCH as well.
So far as I can see, psql itself doesn't cache screen dimension info
anyplace --- it does an ioctl(TIOCGWINSZ) every time it wants the
numbers. So if there is a problem here, it's not our bug; must be
readline's fault.
regards, tom lane
Messed up - I mean when going "up" and scrolling command history it shows long queries (eg 2 line long) in single line and the exceeding part overwrites the beginning of the query), or when writing long SQL at some point I'm starting to overwriting it from the beginning of the line. Sometimes when editing query from the history and appending some conditions at the end I'm starting to write in upper lines and some query parts are duplicated there. Each key press moves me up and shorter part of query is duplicated there.