Home / server / Questions / 187182
Accepted
davidparks21
Asked: 2010-10-04 17:34:45 +0800 CST

Need script to redirect STDIN & STDOUT to named pipes

  • 772

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)

shell-scripting named-pipes

2 Answers

  1. 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).

    • 1
  2. Best Answer

    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.

    • 0