This:

    seq 300000 | parallel --pipe 'echo {1}-{2}; md5sum' ::: 1 2 ::: A B

gives:

    1-A
    1490f57cc8cedc0f3c9c6b26d29ac58a  -
    1-B
    20fbf3f07d8e81789f78b3906d951f09  -

But I think it would be better if it gave:

    1-A
    1490f57cc8cedc0f3c9c6b26d29ac58a  -
    1-B
    1490f57cc8cedc0f3c9c6b26d29ac58a  -
    2-A
    1490f57cc8cedc0f3c9c6b26d29ac58a  -
    2-B
    1490f57cc8cedc0f3c9c6b26d29ac58a  -
    1-A
    20fbf3f07d8e81789f78b3906d951f09  -
    1-B
    20fbf3f07d8e81789f78b3906d951f09  -
    2-A
    20fbf3f07d8e81789f78b3906d951f09  -
    2-B
    20fbf3f07d8e81789f78b3906d951f09  -

So the input chunk is given to all combinations of the command.

The code for retrying --pipe chunks already exists in --retries, so it
is probably doable.

It would mean some backwards incompatible changes:

It would mean that --cat/--fifo must be changed into something like:

    seq 300000 | parallel --pipe --cat 'echo {} {1}-{2}; md5sum {cat}'
::: 1 2 ::: A B

(currently if {} is used in --cat, it will be replaced with the name
of the temporary file. But if {} should mean the same as it does
everywhere else in GNU Parallel, we need to rename the {} used in
--cat. A suggestion would be {cat}).

--roundrobin could work like --tee: all jobs must be started at the
same time, except every chunk is only given to one job - not given to
all jobs:

    seq 300000 | parallel --pipe --roundrobin --cat 'echo {} {1}-{2};
md5sum {cat}' ::: 1 2 ::: A B
    seq 300000 | parallel --pipe --tee --cat 'echo {} {1}-{2}; md5sum
{cat}' ::: 1 2 ::: A B

But should --jobs then just be ignored when used with --pipe and ::: ?
I would expect the --tee example here to run 4 jobs in parallel and
give all input to all 4 of them. The --roundrobin example would also
start 4 jobs, but the input will be spread between them.

Comments?


/Ole

Reply via email to