> Agreed. One thing that would be very simple is to treat an empty PAGER > value the same as "unset". Sounds excellent. > Detecting whether a nonempty value is behaving > sanely seems a great deal harder ... I was thinking a check for existence and executability, but I guess that's covered already... if you use a random string as PAGER you get a sh error: export PAGER="nadatech" /usr/lib/postgresql/9.6/bin/psql --no-psqlrc --dbname=doom --username=doom -p 5434 --host=/var/run/postgresql --command="SELECT 'hello' AS world;" sh: 1: nadatech: not found So the empty PAGER value case is the only one that doesn't seem covered already. (I'm talented about finding these things...) On Tue, Dec 6, 2016 at 9:51 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Joseph Brenner <doomvox@xxxxxxxxx> writes: >> Looking back on the order of events, I think it went like this: >> [ careful postmortem ] > > Thanks for following up! > >> So yeah, some better messaging when PAGER is mangled wouldn't hurt, if >> that's possible. Falling back to "pager off" would make sense to me. > > Agreed. One thing that would be very simple is to treat an empty PAGER > value the same as "unset". Detecting whether a nonempty value is behaving > sanely seems a great deal harder; depending on what pager you're using > and how you stop it, nonzero exit codes from the called process might > be normal. I think it might be practical to issue a warning if we get > an exit code of 126 or 127, though. We have a comment in archive-command > invocation: > > * Per the Single Unix Spec, shells report exit status > 128 when a called > * command died on a signal. Also, 126 and 127 are used to report > * problems such as an unfindable command; treat those as fatal errors > * too. > > The relevant text in POSIX is > > If a command is not found, the exit status shall be 127. If the > command name is found, but it is not an executable utility, the > exit status shall be 126. Applications that invoke utilities > without using the shell should use these exit status values to > report similar errors. > > I don't believe we want to complain about exit on a signal, because > SIGTERM or SIGINT is a typical exit in some pager setups. But these > two codes strongly suggest something broken about your PAGER value. > > So I propose > (1) ignore PAGER if it's an empty string > (2) if pclose returns exit code 126 or 127, report that the PAGER > command didn't work. I'm not sure how complex that is, because IIRC > the pclose is at some remove from the popen call, but if it's not > unreasonably hairy we should do it. > > regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
