4

In the following test script I run an elementary coprocess to which the echo built-in, run in background, attaches its standard-output:

#!/bin/bash
# TEST 1
coproc /bin/sleep 100
echo >&${COPROC[1]} &

The script always fails, for no apparent reason, giving the output:

./test.sh: line 4: ${COPROC[1]}: Bad file descriptor

I wonder if the correct syntax should be rather this one (ampersand moved before redirection):

#!/bin/bash
# TEST 2
coproc /bin/sleep 100
echo & >&${COPROC[1]}

This second example seems to work since it reports no errors during execution, but with this syntax, the redirection is not performed in practice; in fact, consider this other test:

#!/bin/bash
# TEST 3
/bin/echo abc & >xfile

Test 3 creates the file xfile, but does not write anything into it. Curiously, trying again to position the ampersand after the redirection make the echo work fine:

#!/bin/bash
# TEST 4
/bin/echo abc >xfile &

Test 4 creates the file xfile with inside the string abc.

Have some idea on what is causing the coproc redirection error or what the correct syntax is?

imz -- Ivan Zakharyaschev
  • 4,921
  • 6
  • 53
  • 104
davide
  • 2,082
  • 3
  • 21
  • 30
  • In TEST 2 and TEST 3, the & terminates the preceding command, so the output redirections are applied to following (null) command, not the backgrounded processes. Since TEST 1 is fine without the terminating &, I wonder if it might be a parsing error in bash iteself. – chepner Aug 05 '12 at 15:42

2 Answers2

3

As noted elsewhere, coproc arranges for its filedescriptors to be closed in subshells. You can get around that using

coproc { whatever; }
exec {WHATEVER[0]}<&${COPROC[0]}- {WHATEVER[1]}>&${COPROC[1]}-

If using Bash prior to version 4.3 you'll have to use separate variables for the input & output variables:

exec {IN}<&${COPROC[0]}- {OUT}>&${COPROC[1]}-

If using Bash prior to 4.1, you'll have to make do with fixed filedescriptor numbers:

exec 4<&${COPROC[0]}- 5>&${COPROC[1]}- ; IN=4 OUT=5

For an interactive shell you might want to consider disown.

This arrangement also has the benefit that you can use more than one coprocess, even though the Bash man page says that it's not supported.

And as discussed elsewhere, be aware of the limitations of sharing pipes between processes.

Martin Kealey
  • 546
  • 2
  • 11
2

You've got the answer elsewhere http://lists.gnu.org/archive/html/bug-bash/2012-06/msg00027.html:

Coproc file descriptors are not available to subshells. They're implemented using pipes, and leaving pipe file descriptors open in subshells causes processes to hang and not terminate properly, which results in very hard-to-track-down-and-reproduce bugs.

imz -- Ivan Zakharyaschev
  • 4,921
  • 6
  • 53
  • 104
  • After that email of mine, I was already satisfied google could provide an answer for the other (very few) seekers. – davide Aug 30 '12 at 08:19
  • 1
    Named pipes (with `mkfifo`, and `mktemp` for temporary pipes in scripts) are probably more robust/predictable: hence easier to use in scripts without problems. I've failed to implement a working simple reaction to the info read from a command run over `ssh` with `coproc` -- https://gitorious.org/rpush-cat/rpush-cat/blobs/continue-coproc/rpush-continue , so I've used `mkfifo` instead. – imz -- Ivan Zakharyaschev Aug 31 '12 at 16:21