Joseph Brenner <doomvox@gmail.com> 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