Having problems redirecting stderr to a subshell created w/process substitution

Question

~ bash --version
GNU bash, version 3.2.51(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2007 Free Software Foundation, Inc.

The following command works as expected:

~ ls hdfhdfhdhfd 2> >(wc -l)
1

... but this doesn't work, and I'm running out of ideas to figure out why:

~ truss -eaf bash -c 'true' 2> >( some command to process text)

The command inside the >() ends up blocking waiting for input.

If I do this instead:

~ (true; truss -eaf bash -c 'true') 2> >( some command )

... it works as expected, though this doesn't work:

~ (      truss -eaf bash -c 'true') 2> >( some command )
#  ^^^^^ ... note the 1st command is missing

If I make some command = dd bs=1, it consumes and prints all text truss would've spat out on stderr, then blocks.

I cannot reproduce similar behavior in Linux, only when using truss in solaris.

Maybe some shell / default shell combination difference between Solaris and Linux box produces those different behaviors. — Efren, Jun 20 '13 at 07:51
ccarton, You should post that as an answer. It does solve the problem, however I'm still very curious why this happens in the first place. `truss` is the only terminal app I've seen this sort of behavior with. — Brian Vandenberg, Jun 20 '13 at 18:39

score 1 · Accepted Answer · answered Jun 20 '13 at 21:02

Based on @ccarton's response I've come up with a rough idea of what's happening. To illustrate:

~ truss -eaf /usr/bin/perl -e 'print "Test\n"; sleep 5' 2> >(dd bs=1 | wc -l)

In another terminal I could see this parent/child hierarchy:

truss is waiting on the shell, but dd won't exit until its stdin is closed ... so they deadlock.

~ truss -eaf -o >(some command) another command

... causes some command to execute under the current shell so truss is never its ancestor.

I saw the same hierarchy in Linux, but it doesn't deadlock.

1 Answers1