Joseph Brenner <doomvox@xxxxxxxxx> writes: >> Agreed. One thing that would be very simple is to treat an empty PAGER >> value the same as "unset". > Sounds excellent. Actually, after thinking about it a bit longer, should PAGER-set-but- empty be treated as equivalent to "pager off", rather than as a request to use the default pager? I could see arguments either way for that. >> 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 Hm, so you do; so my thought that this needs explicit code on our end seems wrong. [ experiments... ] It seems like the specific case of PAGER being empty or all-white-space causes the shell to think that it's executing an empty line and just do nothing (in particular, not print any error). pclose then returns EPIPE, at least on my platform, which we could report but it doesn't seem like a very useful report. Any other case seems to provoke a shell complaint that's probably sufficient for diagnosis. So what I'm thinking now is that if PAGER is empty or all white space then we should not try to use it as a shell command; we can either treat the case as "pager off" or as "use default pager". Everything else we can leave to the invoked shell to complain about. Comments? 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
