Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an app that launches an authentication helper (my script) and uses STDIN/STDOUT to communicate.

I want to re-direct STDIN and STDOUT from this script to two named pipes for interaction with another program.



Here is the flow I'm trying to accomplish:

[Application] -> Launches helper script, writes to helpers STDIN, reads from helpers STDOUT (example: STDIN:username,password; STDOUT:LOGIN_OK)
[Helper Script] -> Reads STDIN (data from app), forwards to PIPE1; reads from PIPE2, writes that back to the app on STDOUT
[Other Process] -> Reads from PIPE1 input, processes and returns results to PIPE2

The cat command can almost do what I want. If there were an option to copy STDIN to STDERR I could make cat do this with a command (assuming the fictitious option -e echos to STDERR rather than STDOUT):

cat -e PIPE2 2>PIPE1 (read from PIPE2 and write it to STDOUT, copy input, normally going to STDERR to PIPE1)

share|improve this question

Here's a script that finally does what I want. It reads STDIN and outputs it to PIPE1, and takes from PIPE2 and outputs it to STDOUT.

exec 3>../pipes/PIPE1
exec 4<../pipes/PIPE2
{ cat; } <&4 >&1 &
{ cat; } <&0 >&3

The purpose of this is to redirect input/output for a helper app to two pipes which can be handled by a 3rd party app (this is a typical authentication helper).

share|improve this answer

I don't see what you mean. Wouldn't ./script_name <input_pipe >output_pipe work?

share|improve this answer
Your note has been very helpful in forcing me to understand this better. Ultimately I've updated the question to be more clear. – davidparks21 Oct 4 '10 at 12:07
up vote 0 down vote accepted

My previous answer was not an ideal solution as I later discovered. It has three failings: One it doesn't shut down when stdin is closed (eof on stdin). Second, cat (and other utilities like tee and such) have some bizarre characteristics when it comes to closing the reading end of the pipe it's writing to (if you close and re-open the read end of the pipe that this script is writing to it will start to buffer all the data and only flush it when this proces stops, clearly a show stopper for me). And Third, the background process in this case can be orphaned.

After dealing with those issues here is my new script which addresses all three of the above problems. Hope it does someone some good.


# helper <path_to_CLIENT_TO_SERVER_pipe> <path_to_SERVER_TO_CLIENT_pipe>


exec 3>&0

trap 'exit;' CHLD

while read LINE; do             #STDIN -> CS
   print $LINE >>$CS;
} <&3 &

while true; do                  #SC -> STDOUT
        read IN <$SC;
        if [[ $retCode -eq 0 ]]; then
                print $IN;
                sleep 1;

In this case we only have one background process, the one reading stdin. If stdin closes it will exit and we trap that and exit the foreground script. The foreground script never needs to exit because it's reading from a pipe which it should always do regardless of what happens on the other end of that pipe. The use of read, while less efficient, doesn't encounter buffering issues when external processes that are reading/writing to the given pipes come up or down. This script only exists when stdin is closed.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.