Microcom says it's from "the android open source project", so presumably I should send questions that way: Why do you open the tty in nonblocking mode and then immediately switch to blocking mode for the reads (guarded by poll so they shouldn't block anyway)? Are there ttys that hang on open?
I remember testing whether a CDROM drive had a CD in it without waiting to spin it up involves trying to open the block device in nonblock mode and seeing what error message you get. Presumably you can pull a similar trick on external USB drives that spin down if you don't want to wait for them. But I dunno how it applies to char devices? I'm combining xraw() with set_terminal(), and moving the speed setting logic into set_terminal. And while we're at it: $ echo hello | toybox microcom -s 115200 /dev/ttyS0 microcom: tcgetattr fd: I/O error (I think about these things because "toybox expect" is on my post-1.0 todo list.) And if xraw() fails on stdin we haven't set up the signal handler yet and don't restore the tty state? Dunno if it matters... Heh. If you run "toybox top | cat" and then ctrl-c to kill it, the cursor display isn't reenabled and the _reason_ is it was disabled by an ANSI escape sequence and the signal handler that re-enables it outputs the corresponding ANSI escape sequence... which can't make it out through cat if the ctrl-c killed the whole pipeline. I'm calling that one pilot error, largely because I dunno how to fix it. (The tcsetattr call takes it back out of raw mode, but the tcsetattr man page doesn't contain the word "cursor"...) Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
