On Thu, Dec 7, 2017 at 9:33 PM, Ævar Arnfjörð Bjarmason <[email protected]> wrote: > On Thu, Dec 7, 2017 at 1:35 PM, Martin Møller Skarbiniks Pedersen > <[email protected]> wrote: >> On 7 December 2017 at 13:28, Martin Møller Skarbiniks Pedersen >> <[email protected]> wrote: >>> >>> On 7 December 2017 at 00:37, Ævar Arnfjörð Bjarmason <[email protected]> >>> wrote: >>>> >>>> I recently had a use-case for: >>>> >>>> parallel 'cmd {}' ::: {1..Inf} >>>> >>> >>> Maybe something like this: >>> >>> yes | cat -n | cut -f1 | parallel ' cmd {} ' >>> >> >> There are of course many variants but if you prefore perl: >> yes | perl -ne ' print "$.\n" ' > > Thanks. That's very clever, I didn't think of that. > > I have no idea why and don't have time to reproduce it, but if I do: > > yes | cat -n ... parallel --halt ... > > Inside a /bin/sh script the yes continues trying to write to the > broken pipe ven though parallel has exited, although I couldn't > produce it interactively. So I went with this: > > perl -E '1 while say ++$_' | parallel --halt ... > > Which also counts up to infinity, but stops as soon as the write() > call to a broken pipe fails.
The root cause of this is that signals are inherited from parent processes, and the parent was setting SIGPIPE to SIG_IGN.
