Shell Reattach stdin to the terminal after using heredoc

[tembun]

Hello!

I'm developing a TUI program that is controlled via the commands entered into stdin.
I want to automate the process of testing: I want to write a script that would start this program with some initial input data (to set the proper state of the program) and then hand the input to me so that I can enter some values myself.

That was the brief description of the problem that I want to solve. Now, I want to simplify it:
test.sh

#!/bin/sh

cat <<__EOF__
1
2
3
__EOF__

I want to be able to continue entering the data into cat(1) after passing the heredoc values there (without killing the first process and starting a new one to enter the data; i.e. I want to reattach to the same process).

I don't know if it would be possible, since the end of the heredoc closes the stdin and thus the program exits:
$ ./test.sh
1
2
3
$

Maybe there's a way to somehow use heredoc without closing the stdin?

 

[eseipi]

Maybe there's a way to somehow use heredoc without closing the stdin?

I don't think there is a way to do this.

I want to write a script that would start this program with some initial input data (to set the proper state of the program) and then hand the input to me so that I can enter some values myself.

Sounds like you could use fifo:

mkfifo fifo
cat < fifo &
{ echo 1 2 3; cat; } > fifo
rm fifo

 

[tembun]

Sounds like you could use fifo:

Oh, yeah, right, I almost forgot about good old fifos
Thank you very much for the hint!

 

[Kai Burghardt]

[…] a script that would start this program with some initial input data […] and then hand the input to me so that I can enter some values myself.

You know, if you aren’t enclosing the here‑doc delimiter in 'quotation marks', command substitution (and variable expansion and some more) works.​

awesome_tui_program << __EOT__
1
2
3
$(cat)
__EOT__

NB: The here‑doc is first fully parsed before starting awesome_tui_program so it is unsuitable for interactive interaction.​

 

[ralphbsz]

I have something like that in the test suite for my home equipment control program. Usually, the test script writes all the stuff for stdin to a temporary file, and then runs the program as "./program < /tmp/test_input.xyz". But I have a few cases where the input has to be timed, and I connect the test program into a pipe from a second program which generates the stdin. This is particularly needed if there is timing involved: start the test program, give a few commands, then wait 10 seconds, then give it more commands. In my case, that is all done with python programs (I recently rewrote the test harness in python too, sh was to inflexible and wordy).