Re: proposal - psql - use pager for \watch command - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: proposal - psql - use pager for \watch command |
| Date | |
| Msg-id | CAFj8pRCSjkCD+Lq-1Hk69x=kPKnPqT1VJ+3x+F9yEe+ieHorKA@mail.gmail.com Whole thread Raw |
| In response to | Re: proposal - psql - use pager for \watch command (Thomas Munro <thomas.munro@gmail.com>) |
| List | pgsql-hackers |
po 22. 3. 2021 v 22:07 odesílatel Thomas Munro <thomas.munro@gmail.com> napsal:
On Tue, Mar 23, 2021 at 1:53 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> po 22. 3. 2021 v 13:13 odesílatel Thomas Munro <thomas.munro@gmail.com> napsal:
>> The problem is that Apple's /dev/tty device is defective, and doesn't
>> work in poll(). It always returns immediately with revents=POLLNVAL,
>> but pspg assumes that data is ready and tries to read the keyboard and
>> then blocks until I press a key. This seems to fix it:
>>
>> +#ifndef __APPLE__
>> + /* macOS can't use poll() on /dev/tty */
>> state.tty = fopen("/dev/tty", "r+");
>> +#endif
>> if (!state.tty)
>> state.tty = fopen(ttyname(fileno(stdout)), "r");
>
>
> it is hell.
Heh. I've recently spent many, many hours trying to make AIO work on
macOS, and nothing surprises me anymore. BTW I found something from
years ago on the 'net that fits with my observation about /dev/tty:
https://www.mail-archive.com/bug-gnulib@gnu.org/msg00296.html
Curious, which other OS did you put that fallback case in for? I'm a
little confused about why it works, so I'm not sure if it's the best
possible change, but I'm not planning to dig any further now, too many
patches, not enough time :-)
Unfortunately, I have no exact evidence. My original implementation was very primitive
if (freopen("/dev/tty", "rw", stdin) == NULL)
{
fprintf(stderr, "cannot to reopen stdin: %s\n", strerror(errno));
exit(1);
}
{
fprintf(stderr, "cannot to reopen stdin: %s\n", strerror(errno));
exit(1);
}
Some people reported problems, but I don't know if these issues was related to tty or to freopen
In some discussion I found a workaround with reusing stdout and stderr - and then this works well, but I have no feedback about these fallback cases. And because this strategy is used by "less" pager too, I expect so this is a common and widely used workaround.
I remember so there was a problems with cygwin and some unix platforms (but maybe very old) there was problem in deeper nesting - some like
screen -> psql -> pspg.
Directly pspg was working, but it didn't work from psql. Probably somewhere the implementation of pty was not fully correct.
> Please, can you verify this fix?
It works perfectly for me on a macOS 11.2 system with that change,
repainting the screen exactly when it should. I'm happy about that
because (1) it means I can confirm that the proposed change to psql is
working correctly on the 3 Unixes I have access to, and (2) I am sure
that a lot of Mac users will appreciate being able to use super-duper
\watch mode when this ships (a high percentage of PostgreSQL users I
know use a Mac as their client machine).
Thank you for verification. I fixed it in master branch
>> A minor problem is that on macOS, _GNU_SOURCE doesn't seem to imply
>> NCURSES_WIDECHAR, so I suspect Unicode will be broken unless you
>> manually add -DNCURSES_WIDECHAR=1, though I didn't check.
>
> It is possible -
>
> can you run "pspg --version"
Looks like I misunderstood: it is showing "with wide char support",
it's just that the "num" is 0 rather than 1. I'm not planning to
investigate that any further now, but I checked that it can show the
output of SELECT 'špeĉiäl chârãçtérs' correctly.
It is the job of ncursesw - pspg sends data to ncurses in original format - it does only some game with attributes.
pgsql-hackers by date: