Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

E.g.:

SCRIPT_STDIN > pipe1
SCRIPT_STDOUT < pipe2

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
add comment

3 Answers

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.

#!/bin/ksh
exec 3>../pipes/PIPE1
exec 4<../pipes/PIPE2
{ cat; } <&4 >&1 &
{ cat; } <&0 >&3
wait

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
add comment

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

share|improve this answer
1  
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
add comment
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.

#!/bin/ksh

#
# USAGE
# helper <path_to_CLIENT_TO_SERVER_pipe> <path_to_SERVER_TO_CLIENT_pipe>
#

CS=$1
SC=$2

exec 3>&0

trap 'exit;' CHLD

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

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

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
add comment

Your Answer

 
discard

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.