Re: [PATCH] difftool: always honor "command not found" exit code
- From
David Aguilar <davvid@gmail.com>
- Date
- Aug 13, 2016, 22:59 UTC
- Message-ID
- <20160813225939.GA21057@gmail.com>
- In-Reply-To
- <20160813113028.uwedje6fzuc3cuzr@john.keeping.me.uk>
On Sat, Aug 13, 2016 at 12:30:28PM +0100, John Keeping wrote:
Show 17 quoted lines
> At the moment difftool's "trust exit code" logic always suppresses the > exit status of the diff utility we invoke. This is useful because we > don't want to exit just because diff returned "1" because the files > differ, but it's confusing if the shell returns an error because the > selected diff utility is not found. > > POSIX specifies 127 as the exit status for "command not found" and 126 > for "command found but is not executable" [1] and at least bash and dash > follow this specification, while diff utilities generally use "1" for > the exit status we want to ignore. > > Handle 126 and 127 as special values, assuming that they always mean > that the command could not be executed. > > [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02 > > Signed-off-by: John Keeping <john@keeping.me.uk>
Looks good to me, thanks.
Acked-by: David Aguilar <davvid@gmail.com>
Show 12 quoted lines
> --- > On Sat, Aug 13, 2016 at 11:36:39AM +0100, John Keeping wrote: > > It would be nice if there was a way to differentiate between complete > > failure and just the diff tool exiting with a non-zero return status > > because the files differ, but I'm not sure whether we can do that > > reliably. POSIX uses 127 and 126 as errors that mean the command didn't > > run [1] so it may be sensible to to treat those as special values. > > Something like this perhaps? I think this is probably safe, but it's > always possible that some diff utility does use 126 or 127 as a "normal" > exit status. I'm not sure what we can do about that oaaaather than add a > "really, really don't trust the exit status" option!
We can always add a mechanism for tool-specific error codes later if we ever end up needing it, but this seems sufficient.
cheers,
-- David