Re: Tesing a fifo without opening it?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 13,  1:43am, Dominik Vogt wrote:
} On Sun, Sep 12, 2010 at 12:02:23PM -0700, Bart Schaefer wrote:
} > On Sep 10,  8:35am, Dominik Vogt wrote:
} > } ---- sub script
} > } 01 read REQUEST < "$1"
} > } 02 echo answer > "$2"
} > 
} > Of course with the coproc, these are stdin/stdout so you don't need
} > $1 and $2 and redirections.  If for some reason you're counting on
} > the script to have inherited the parent's stdin/out, you can't use
} > coproc.
} 
} Actually, the script may exec a c-program that can not use stdin
} and stdout for the command channels.  Is it possible to have the
} coproc use separate descriptors for stdio and the coproc pipes?

Ah, I wondered.  First let me note that c-programs, unless specifically
designed to, e.g., use non-blocking I/O, are highly likely to encounter
the deadlock situation I described previously.  The standard set of
text utilities (cat, sed, et al.) are very difficult to use in these
circumstances.

That said ... the coprocess when first started will always have its
stdin and stdout connected to the pipes.  However, you can use exec
with redirection to juggle that any way you wish.  E.g.,

    # Copy shell stdio
    exec {s_in}<&0 {s_out}>&1
    # Start coprocess
    coproc {
	# Save coprocess stdio
	exec {c_in}<&0 {c_out}>&1
	# Reconnect to shell stdio
	exec <&$s_in >&$s_out
	# Now do the original work 
	read -u $c_in command
	eval "$command"
	print -u $c_out "all finished"
    }
    # Try it
    print -p 'echo IN COPROCESS' ; read -E -p

You could do all four redirections in a single "exec" but it's a bit
more obvious what's happening if you use two.