GNU bug report logs - #23206
25.0.92; dired-shell-stuff-it: wait until all parallel jobs finish

Previous Next

Full log

View this message in rfc822 format

From: Tino Calancha <f92capac <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Tino Calancha <f92capac <at> gmail.com>, 23206 <at> debbugs.gnu.org
Subject: bug#23206: 25.0.92; dired-shell-stuff-it: wait until all parallel jobs finish
Date: Mon, 4 Apr 2016 01:38:52 +0900 (JST)

> Thanks.  Can you elaborate on why such a wait is needed?

Let's assume COMMAND is "du -s"
and LIST contains the dirs foo bar baz:
foo is ~ Gb  with depth > 1
and bar and baz are few kB dirs with depth 1.

The effective shell command to run is:
du -s foo& du -s bar& du -s baz&

This creates a new process PROC in the system.
PROC returns with the return code of the last command in the list
(du -s baz):  this is a shell feature.
The output from the remaining jobs is still comming to stdout,
but is not associated to PROC, which already succeded.

With `dired-do-shell-command', we get all output only if foo
is the last dir in LIST.

POSIX shells provide the builtin 'wait' to change this behaviour:
it forces PROC to wait until all background jobs end.

You can run from terminal following scripts:
I)
#!/bin/sh
echo "id $$"
du -s foo& du -s bar& du -s baz&

II)
#!/bin/sh
echo "id $$"
du -s foo& du -s bar& du -s baz&
wait

Then list the process id of the scripts while you still have
output comming:
ps -f -p ID

I) No process in the system with ID.
II) There is a process with ID.


Well, maybe it can be solve in many other ways.  I just found
very simple: just adding 4 letters fix it; also very natural,
because we are building a shell command, so its logical to use the
shell sintaxis.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.