On Sun, Nov 13, 2016 at 08:40:02PM -0500, James McCoy wrote:
> The relevant part of the script is just looking for whether patch
> numbers are applied or marked NA in neovim's src/nvim/version.c:
>
> is_missing="$(sed -n '/static int included_patches/,/}/p'
> "${NVIM_SOURCE_DIR}/src/nvim/version.c" |
> grep -x -e "[[:space:]]*//[[:space:]]${patch_number} NA.*" -e
> "[[:space:]]*${patch_number}," >/dev/null && echo "false" || echo "true")"
Playing with this some more, I attempted to change this to use “grep -q …”
instead of the redirection to /dev/null. This exhibited the same
problematic behavior, regardless of which version of grep I was using
(back to 2.22).
So, the problematic behavior seems to be related to the "immediate exit"
behavior of -q (and now also when output is redirected to /dev/null)
causing the left-hand side of the pipe to get a SIGPIPE. Since the
script has “set -o pipefail”, this causes the "sed … | grep …" to be
considered a failure and echo the wrong value.
I'm not sure if the above snippet from the script was intentionally
using redirection to /dev/null to avoid the SIGPIPE, but if so I can
assume that it isn't the only script to do so. The redirection was,
prior to the upstream commit, an escape hatch for avoiding SIGPIPE when
the exit code was the important data, not the output.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
