"R. Diez" <[email protected]> writes:
>>> That is a first step. I would also guess that enabling "pipefail"
>>> should be similarly unproblematic.
>> Well, sure, it you want something like:
>> last-two-commits:
>> git log --oneline | head -n 2
>> to start failing (or not, depending on how many commit you have and how
>> large you pipe buffer is ¯\_(ツ)_/¯). pipefail is situational at best
>> and I am somewhat skeptical about enabling it by default.
>
> You got that wrong. The only purpose of 'pipefail' is to prevent ignoring
> errors from pipeline commands. The pipe buffer size does not affect it at all.
Are you sure about that? If, in the example above, whatever git wants
to output fits into the buffer (== you have few commits), it can output
it without SIGPIPE (and hence the pipeline succeeds), since the pipe
buffers it.
Compare writing out a single line (exits with success):
--8<---------------cut here---------------start------------->8---
$ ( set -o pipefail; git log --oneline -n1 | { sleep 5; true; }; echo $? )
0
--8<---------------cut here---------------end--------------->8---
with writing out 100000 lines (exits with error):
--8<---------------cut here---------------start------------->8---
$ ( set -o pipefail; git log --oneline -n100000 | { sleep 5; true; }; echo $? )
141
--8<---------------cut here---------------end--------------->8---
I am far from domain expert here however, so please do point out what is
wrong with the demonstration above.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
