Bash: Mutual interaction of processes via pipes

Question

ENVIRONMENT: Linux/Docker, bash version 4.2.

QUESTION:

server-app accepts commands with an interactive shell.
server-app receives commands originating from a client.sh through a pipe.
server-app writes to the standard output received by client.sh.
client.sh considers server-app's output to determine further commands.
server-app might also ask for a password => That is, the terminal's standard input must be forwarded to server-app along with the output of client.sh.

I tried multiple setups with coproc. However, I either run into a stalled situation or data has not been received. How can such a setup as, shown below, be implemented in bash?

                       .------>------------------------.
     .---------.       |         .------------.  stdin |       .-----------.
     | user    |-------'         | server-app |<-------+-------| client.sh |
     | console |<--+-------------|            |     .--------->|           |
     '---------'   |      stdout '------------'     |          '-----------'
                   '--------------------------------'

MY TRY:

coproc server.app

function expect { local expectation=$1
        # read from pipe until $expectation occurs in the input stream
        # when found, echo the line to 'stdout'
        echo "EXPECT: '$expectation'"
        while true; do
            read text <&"${COPROC[0]}"
            if [[ "$text" == *"$expectation"* ]]; then
                    echo $text 
                    break
            fi
        done
}

function send { local command=$1
        # send $command through pipe 
        echo "SEND: $command"
        echo "$command" >&"${COPROC[1]}"

}


expect "Conected to URL" 
send   "open"
expect "Session keepalive"
send   "session open"

# use the reported session identifier to setup the user command
session_n=$(expect "Identifier of Session created" | cut -d' ' -f5)    
command=$(echo "$user_command" | sed -e "s/SESSION/$session_n/g")

The last three lines only demonstrate a possible processing of the server-app's output. Again what is wrong with that? How can it be brought to work.

bash's `coproc` is quite buggy: https://lists.gnu.org/archive/html/bug-bash/2016-04/msg00014.html — pynexj, Feb 24 '21 at 13:48
That might be an explanation. Is there an alternative approach? — Frank-Rene Schäfer, Feb 24 '21 at 13:49
Does "terminal" represent some process or it's meant to be parent stdin/stdout? Reading input from multiple places makes little sense - what do you expect to happen when input interleave? Should the input to `server-app` come from terminal or from client.sh? — KamilCuk, Feb 24 '21 at 13:51
you can use [tag:expect] or similar tools. take a look at my [sexpect](https://github.com/clarkwang/sexpect/) if you prefer using shell. — sexpect - Expect for Shells, Feb 24 '21 at 13:52
Well, is `user console` some program, or it's meant to represent parent stdin/stdout? — KamilCuk, Feb 24 '21 at 13:54
note that its not easy to feed password to a prog unless it supports getting passwd in an insecure way. — sexpect - Expect for Shells, Feb 24 '21 at 13:55
@ Expect for Shells: Would you, please, pinpoint a solution and post it as an answer? — Frank-Rene Schäfer, Feb 24 '21 at 13:55
Sure. So what should happen with that input interleaving? Imagine I type `something\n` and then __at the same time__ client.sh outputs `else\n`? Should the input be `soelthing\nse\n`? — KamilCuk, Feb 24 '21 at 13:57
https://stackoverflow.com/questions/65771885/ has examples for both expect and sexpect. — sexpect - Expect for Shells, Feb 24 '21 at 13:58
@KamiCuk, of course not. The user would see 'please, provide password' and ``client.sh`` keeps silent meanwhile. — Frank-Rene Schäfer, Feb 24 '21 at 14:05
Oooch, so it's not stdin connected to `server-app`, but there is a program between, right? And that program, receives lines from `server-app` and makes decisions where from to read next? — KamilCuk, Feb 24 '21 at 14:07
Not necessarily, if the ``client.sh`` sees ``password``it stays calm, while the user feeds its password. — Frank-Rene Schäfer, Feb 24 '21 at 14:55

score 0 · Accepted Answer · answered Mar 03 '21 at 08:32

As metioned by @sexpect the 'natural' way is to solve the problem is expect. This tool takes a Tcl-based script as input.

 spawn server-app

would start the server-app under control of expect. expect is also a keyword in these scritps.

 expect -re "something (..)"

waits for output matching the expression something (..).

 send ...

sends some characters to the application.

expect_tty ...

takes some input from the user that launched the expect script.

Bash: Mutual interaction of processes via pipes

1 Answers1