It's quite surprising how trivial a serial terminal program is if you remove all the extraneous stuff like modem support that no one uses anymore. I may actually switch to this from cu and screen if I can ever train my fingers to type a different command
I know the feeling - sometimes it can take a long time time to un-train those finger moves that we get so used to
A few suggestions:
If you get a failure opening the tty do some simple checks and give a more useful error message. Check for idiots logged in as root, and give a suitable error - root isn't allowed to open serial ports by default for obvious (although now largely historical) reasons.
Also check if the user is a member of the correct group to access the tty and provide a helpful message if not. You should really read the group for the tty file etc, etc. Those are two serial port access error I get asked about frequently.
I think at best I can add a warning when you run as root because I really don't want to dictate policy. If you want to run as root I won't prevent you. We also have to keep in mind that tio is actually being used on embedded devices with very simple filesystems where root is still the normal user state. Regarding tty groups, I don't want to walk down the road of maintaining checks for specific groups since those can vary across distributions and over time.
Make ctrl-t ctrl-t send a ctrl-t. That's a little easier to type reliably than taking a finger of ctrl.
I know what you are saying but in this case I really prefer to keep the same type of key code sequence for all key commands to keep it consequential, simple and clean. Besides, the need for sending the raw ctrl-t key code is such a rare event that the vast majority of user fingers out there will never be affected by this non-standard Vulcan death grip
Linux does have an interface for selecting arbitrary baud rates in addition to the standard ones. It is very occasionally useful to be able to use them.
Actually I did implement part of that feature but I didn't have a serial device that supported arbitrary baud rates so I couldn't test it. Either way, only a very few Linux serial device drivers support arbitrary baud rates so I ended up deciding against it and stick with what can be done through the standard c library API just to keep the code simple across all platforms (tio is also used on non-linux platforms). However, I might revisit that decision in the future if there becomes a big enough demand for it.
Oh, and why the call the system("clear"); rather than just doing it inline?
Admittedly, it was a lazy quick way of doing it because I didn't find the correct ANSI/VT100 code for it at the time. Fixed in
https://github.com/tio/tio/commit/07255c94b94f2b9e40766757450f5b73745a9086And the 'weird shit' with the status variable in the function? Other than that, nice clean code.
Thanks.
Actually the 'status' thing is not weird
Think about it. A function returns a value that represents its status code. Hence I prefer 'status' over any of the less meaningful shorthand abbreviations 'r', 'ret', 'retval' etc.. Anyway, by the end of the day it's just a matter of coding style - generally I prefer not keeping everything super abbreviated just to save a few characters and in the process muddle the expressed semantics