On Thu, Dec 7, 2017 at 9:16 PM, Ole Tange <[email protected]> wrote:
> On Thu, Dec 7, 2017 at 1:28 PM, 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 {} '
>
> Or shorter:
>
> yes | parallel cmd {#}
Thanks, on a related note isn't the following a bug:
This works as expected, quits soon after the 2nd job fails:
$ yes | parallel-20171122/src/parallel --jobs=2 --halt-on-error
soon,fail=1 'echo {#}; if test {#} -ge 2; then exit 1; fi'
1
2
parallel: This job failed:
echo 2; if test 2 -ge 2; then exit 1; fi
parallel: Starting no more jobs. Waiting for 1 jobs to finish.
3
parallel: This job failed:
echo 3; if test 3 -ge 2; then exit 1; fi
But If I change that to:
--jobs=1 --halt-on-error soon,fail=1
It'll go on forever, however this'll "work":
--jobs=1 --halt-on-error now,fail=1
Maybe I'm missing some subtlety here, but this doesn't seem to behave
as documented, and is certainly unexpected: "’soon’ which means wait
for all running jobs to complete, but start no new jobs".
The bug appears to be in this code:
if($Global::halt_when eq "soon"
and scalar(keys %Global::running) > 0) {
Which, not knowing the internals well, should be something like:
if($Global::halt_when eq "soon"
and $Global::max_jobs_running == 1 or scalar(keys
%Global::running) > 0) {
Or at least that makes this work for me.