Named pipes into program

[shawnjgoff]

I'm on an embedded platform, trying to use microcom to talk to a modem device from a script. I made a named pipe with mkfifo and I'm trying to do something like:

microcom /dev/ttyUSB0 <pipe1 >/tmp/responses &
echo "at" > pipe
cat /tmp/responses
#returns "at" the first time, doesn't change after echoing other things to the pipe.

I've tried variations on a theme such as:

tail -f pipe | microcom >> /tmp/responses &
tail -f /tmp/responses &
echo "at" > pipe
#causes microcom to exit, nothing comes out.

I've tried a few things and haven't been able to get anything to work. I know about tools like expect and its cousins, but I can't use that because this is a very limited platform. Any suggestions?

[lugoteehalt]

No idea at all really, but I like doing this:

$ cat > pipe1
enter
some text
<ctrl+d>

Then, on another terminal:

$ cat < pipe1 <return>

Then the text comes out of the other terminal. ctrl+d ends the process.

Y'know, it just clarifies what pipes do.

[waynemot]

I'm on an embedded platform, trying to use microcom to talk to a modem device from a script. I made a named pipe with mkfifo and I'm trying to do something like:

microcom /dev/ttyUSB0 <pipe1 >/tmp/responses &
echo "at" > pipe
cat /tmp/responses
#returns "at" the first time, doesn't change after echoing other things to the pipe.

I've tried variations on a theme such as:

tail -f pipe | microcom >> /tmp/responses &
tail -f /tmp/responses &
echo "at" > pipe
#causes microcom to exit, nothing comes out.

I've tried a few things and haven't been able to get anything to work. I know about tools like expect and its cousins, but I can't use that because this is a very limited platform. Any suggestions?

My suspicion is that because you start the microcom process reading in from a pipe, once the contents of the pipe are exhausted and the ctrl-d (end of data) signal is sent as the input to microcom that the microcom process terminates and the subsequent cat/echo statements directed to the pipe are ignored, because microcom isn't listening anymore. You may want to put a sleep between the first echo and the cat and then use a second shell window to see if the microcom process still exists. That would validate or repudiate this hypothesis.

[unlimitedscolobb]

microcom /dev/ttyUSB0 <pipe1 >/tmp/responses &
echo "at" > pipe
cat /tmp/responses
#returns "at" the first time, doesn't change after echoing other things to the pipe.

As waynemot points out, echo > pipe also produces the EOF symbol, which makes microcom exit.

I've tried variations on a theme such as:

tail -f pipe | microcom >> /tmp/responses &
tail -f /tmp/responses &
echo "at" > pipe
#causes microcom to exit, nothing comes out.

I've tried the same thing subsituting microcom with cat and it worked as expected. This most probably means that something is wrong with the microcom application or with the data you are trying to supply to it.

And yes, I used more than one shell sessions (via screen).

[shawnjgoff]

I've tried the same thing subsituting microcom with cat and it worked as expected. This most probably means that something is wrong with the microcom application or with the data you are trying to supply to it.

And yes, I used more than one shell sessions (via screen).

Thanks, folks. Looks like I have some more to try.