Standard input must be a terminal about picocom HOT 6 CLOSED

Aren't there tools for that already? Like chat(8) or even simply echo(1) and cat(1)? What exactly do you want to achieve? An example would be useful.

I believe what you 're thinking is not as simple as that. Think:

 echo "command" | picocom /dev/ttyS0 > response.txt

Something like this will obviously not work. When will picocom exit? When the standard input is closed? If so, it probably won't have time to receive the the reply (to write to "response.tx"t). You have to do something like:

echo "command" | picocom /dev/ttyS0 --wait 10 > response.txt

and now we 're already in chat(8) territory.

Something that could be useful (maybe, I'm not sure) would be an option to exit after configuring the port, without resetting it, so that then you can use other tools to speak to the already configured port.

Another possibility would be for picocom fork and exec a program you provide with it's input and output connected to the configured port, wait for it to exit, and then reset the port and exit itself (something like what it already does with --send-file and --receive-file, but without any interaction).

But we 're already talking about another program altogether...

Maybe you mean something else and I don't understand. Sorry if this is the case.

from picocom.

Something along the lines of

echo "command" | picocom /dev/ttyS0 --wait 10 > response.txt

is the functionality I'm aiming for. I'll admit I don't have experience with chat(8), expect(1), or the like, but after reading their man pages, their design and intended purpose isn't quite what I had in mind here. Requiring a script (and one with a fairly limited vocabulary in the case of chat(8)) up front is obviously more restrictive and less composable than being able to operate on stdin and stdout. I was hoping to launch picocom as a child process in some test script written in Python or the like, and base what I write to the serial device on its responses to previous commands.

I could certainly set the ioctls as needed and do reads and writes with my test script itself, but picocom does such a nice job of handling this already. I think making it composable would be a simple add-on and a nice thing to have. The patch to do so is quite small (patch), and adding an argument to specify a timeout is similarly trivial.

from picocom.

Ah, now I see. As I was saying. It's much simpler than that:

• Add an option to picocom to quit imediatelly after configuring the serial port (without reseting it)
• Run picocom with the options you want, to configure the port. Picocom exits imediatelly.
• From your python program open "/dev/ttyXX" like a normal file (no ioctls required, as it is already configured), and read / wite from it, all you want.

Am I getting something wrong? Would such an option (quit immediatelly without reseting the port) be enough?

Something like this, I could possibly consider for a future release. My only qualm is that most of these things you can already do with stty(1).

But as I said, if this is what you want (I I'm getting it right) I will consider it.

from picocom.

I also added some comments to your patch.

from picocom.

Add an option to picocom to quit imediatelly after configuring the serial port (without reseting it)

This might be nice, but the more I try to justify my changes, the more I get the feeling I should just be using stty.

from picocom.

@npat-efault The solution you proposed in #29 (comment) is awesome. It is working like a charm.

I ran into a different use case, and I hope you can advise me on. I would like to use picocom to log on an unattended computer, Raspberry Pi for example. The problem is that when cron invokes picocom it has no tty.

I tried to run it in FG and BG to no avail. It simply refuses to run, saying that !! STDIN is not a TTY

Any advise?

from picocom.