parallel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bad example: GNU Parallel as dir processor


From: Ole Tange
Subject: Re: bad example: GNU Parallel as dir processor
Date: Thu, 15 Mar 2012 20:30:57 +0100

On Thu, Mar 15, 2012 at 3:33 PM, Thomas Sattler
<sattler@med.uni-frankfurt.de> wrote:
> Hi there ...
>
> The manpage says, when grouping is disabled, "Output is printed
> as soon as possible" and "the outputs from different commands
> are mixed together".
>
> As far as I understand, that means not only lines might appear
> in quite a funny oder, it might also be, that one line of out-
> put is a mixture of several lines of different jobs.

That is correct. Unless you redirect the output:

  ... | parallel -u echo '>' {}.out '2>' {}.err

The above will work just fine.

> And than there is this example:
>
> |
> | GNU Parallel as dir processor
> |
> | [...]
> | The -u is needed because of a small bug in GNU parallel. If
> | that proves to be a problem, file a bug report.
> |
>
:
> In case the mentioned bug has not already been fixed, I'd vote
> for removing the whole example, as it's just working.

The bug has not been fixed. To see it in action try:

inotifywait -q -m -r -e CLOSE_WRITE --format %w%f . | parallel -j 2 echo &
sleep 2
touch nooutput1
sleep 2
touch nooutput2
sleep 2
touch now_two_outputs
sleep 2
touch now_one_more_output

Compare that to the same with -u:

inotifywait -q -m -r -e CLOSE_WRITE --format %w%f . | parallel -u -j 2 echo &
sleep 2
touch nooutput1
sleep 2
touch nooutput2
sleep 2
touch now_two_outputs
sleep 2
touch now_one_more_output

I will consider fixing the bug when someone shows it is a real problem
to them or if someone provides a beautiful patch.

However, the dir processing is being used by some users so removing it
as an example does not sound like a good idea.


/Ole



reply via email to

[Prev in Thread] Current Thread [Next in Thread]