Error: Saving current stdio settings failed

[CarlFK]

echo test | tio /dev/ttyACM0  >test.log
cat test.log
Error: Saving current stdio settings failed

The real goal is using tio in a script called from a systemd service, which says:

May 31 00:30:00 oppi dev_setup.sh[1383]: [44B blob data]

trying to see blob lead me to the error I am reporting. no idea if this will fix that.

[expipiplus1]

Could try something like { echo test; sleep 10 } | sudo unbuffer -p tio /dev/ttyACM0 > test.log (untested).

The sleep 10 is to keep tio's stdin open long enough to get a reply.

A non-interactive mode for tio would be very convenient. For some reason cat /dev/ttyUSB0 doesn't really work for me but tio works fine...

[pallas]

It would be awesome to write something like echo ATI | tio /dev/ttyACM0 | timeout 10s grep -m 1 OK and have tio close the serial when its output stream closed, in this case when it reads "OK" (success) or after 10 seconds (failure).

[lundmar]

The stuff that you guys are trying requires an non interactive mode. I will put it on the TODO list.

[albfan]

Whatever this needs is something like cu does:

https://github.com/quinot/taylor-uucp

here filtering output:

cu -l /dev/ttyUSB0 -s 115200 | grep -v "-"

or saving to file

cu -l /dev/ttyUSB0 -s 115200 > file.log

to end pipe type ~. like Ctrl+t q in tio

[lundmar]

Yes, piping to/from tio is a feature that I would like to see added in the future.

[GWHAYWOOD]

Thanks very much for working on tio.

Although my present use for tio does not require an interactive mode, I think it might be very useful.

I am using tio version 1.32 on Raspberry Pi devices. The 'meson' build system does not appear to be available on this platform so I cannot build and test the latest version. Having said that, perhaps I can contribute something from my experience using tio recently.

I believe that on startup it may be possible for tio to get into a kind of loop, where it repeatedly displays a line of text which has been sent by the serial device before tio was started and which is presumably sitting in a buffer somewhere, lying in wait for any unsuspecting comms utility.

In my application I am sure that the line of text is not being repeated by the remote device, but I cannot be certain that it is not being erroneously repeated by the USB-serial converters which I am using. However, I have not seen 'minicom' repeat these same lines when I use it instead of tio with the same USB-serial converters. (If for no apparent reason the USB-serial device goes away briefly, which in my experience they all seem to do, Minicom does not reconnect. This is why I have replaced minicom with tio. For more than 30 years with non-USB serial devices this has never been necessary.)

My point is this: would it make sense to provide an option for tio at startup to flush all input from the remote device to /dev/null, until for example it has to wait (perhaps for some configurable time) for input?

[lundmar]

Thank you, I'm glad you like tio.

Repeated error messages of same type should be fixed in more recent versions. Please try latest tio version with your usb-serial device.

[GWHAYWOOD]

Thanks for the very quick reply. I was wrong about meson not being available for the Pi - I don't know why I didn't find it when I first looked.

The build went very smoothly (after I installed git :) so I've managed to compile tio version 1.38 for the Pi.

The repetition of messages usually happens at the beginning of the day when the systems are started. It doesn't happen every time, so I guess it will be a few days before I can say whether that's fixed or not.

Thinking more about the startup issues, I wonder if it's possible at startup to have tio send the contents of a file to the remote device? I suppose it would be possible to use the local socket feature to get the same effect, but just creating a file would be a lot easier for the users. Just nice to have, not a deal-breaker.

[lundmar]

Yes, could do that using the upcoming file socket feature - the purpose of that feature is for the user to interact with the serial device in any way they want, even from multiple clients.

That being said, on the wish list is a feature to be able to pipe to tio as suggested in this reported issue. This means eventually you will be able to do something like this to pipe the contents of a file:

cat test.txt | tio /dev/ttyACM0

[lundmar]

Finally support for piping to tio has been added in dba77eb