view tests/test-ancestor.py.out @ 31478:9335dc6b2a9c

pager: avoid shell=True on subprocess.Popen for better errors (issue5491)

man(1) behaves as poorly as Mercurial without this change. This cribs
from git's run-command[0], which has a list of characters that imply a
string that needs to be run using 'sh -c'. If none of those characters
are present in the command string, we can use shell=False mode on
subprocess and get significantly better error messages (see the test)
when the pager process is invalid. With a complicated pager command
(that contains one of the unsafe characters), we behave as we do today
(which is no worse than git manages.)

I briefly tried tapdancing in a thread to catch early pager exits, but
it's just too perilous: you get races between fd duping operations and
a bad pager exiting, and it's too hard to differentiate between a
slow-bad-pager result and a fast-human-quit-pager-early result.

I've observed some weird variation in exit code handling in the "bad
experience" case in test-pager.t: on my Mac hg predictably exits
nonzero, but on Linux hg always exits zero in that case. For now,
we'll work around it with || true. :(

0: https://github.com/git/git/blob/cddbda4bc87b9d2c985b6749b1cf026b15e2d3e7/run-command.c#L201

% lazy ancestor set for [], stoprev = 0, inclusive = False
membership: []
iteration:  []
% lazy ancestor set for [11, 13], stoprev = 0, inclusive = False
membership: [7, 8, 3, 4, 1, 0]
iteration:  [3, 7, 8, 1, 4, 0, 2]
% lazy ancestor set for [1, 3], stoprev = 0, inclusive = False
membership: [1, 0]
iteration:  [0, 1]
% lazy ancestor set for [11, 13], stoprev = 0, inclusive = True
membership: [11, 13, 7, 8, 3, 4, 1, 0]
iteration:  [11, 13, 3, 7, 8, 1, 4, 0, 2]
% lazy ancestor set for [11, 13], stoprev = 6, inclusive = False
membership: [7, 8]
iteration:  [7, 8]
% lazy ancestor set for [11, 13], stoprev = 6, inclusive = True
membership: [11, 13, 7, 8]
iteration:  [11, 13, 7, 8]