The stty utility sets or reports on terminal I/O characteristics for the device that is its standard input. These characteristics are used when establishing a connection over that particular medium. cat doesn't know the baud rate as such, it rather prints on the screen information received from the particular connection.
As an example stty -F /dev/ttyACM0 gives the current baud rate for the ttyACM0 device.
People usually want to see what they're typing (unless it's a password) :-)
The terminal accepts input at any time, and buffers it until an application reads it. More than that, when the tty is in cooked mode, the kernel buffers whole lines at a time and provides some rudimentary line editing functionality that allow you to kill the entire buffered line (default binding Ctrl-u and backspace. During the time that the line is being entered and edited and until you press Enter, applications reading from the terminal read nothing at all.
The tty functionality in the kernel does not and can not know if and when an application like tail is planning to produce output on the terminal, so it would not be able to somehow... cancel (?) line editing during such times and only during such times.
Anyway, being able to prepare the next line for the shell while something else is still busy running on the terminal and the shell is not yet ready to read that command is a feature, not a bug, so I wouldn't advocate removing it. Maybe not so useful for tail (which will never terminate on its own), but pre-typing the next command during a long-running cp or make (for example), and even editing that command with Ctrl-h and Ctrl-u, all before the shell gets ahold of it, is a common thing to do. Timothy Martin wrote in a comment:
It is worth mentioning that less +F somefile provides similar functionality to tail -f somefile except that (accidentally) typed keystrokes will not echo to the screen.
Yeah, but less not only prevents those characters from being echoed, but it also eats them, so they are not available to the next application that wants to read them!
Finally, there is one more reason:
In historical times (before my time!) terminals with local echo were common. That is, the terminal (usually in hardware) would echo the characters you typed locally while also sending them down the serial line. This is useful for giving the user quick feedback even if there was lots of latency over the conection to the UNIX system (think 300 baud modem dialing up a terminal server with auto-telnet to a slow UNIX system over a token ring network — or whatever).
If you have a terminal with local echo, then you want stty -echo at all times on the UNIX server to which you are connected. The result is approximately the same as a terminak without local echo (the common kind today) and stty echo enabled. So from that point of view, stty echo's job is to echo charatcers immediately as soon as they are received, regardless of what software is running, in emulation of what would happen on a terminal with local echo.
(By the way, if you have a terminal with local echo, you can't hide your password.)
Best Answer
It looks like you might be a bit confused about how this all works.
First,
/dev/ttyACM0does not represent the USB link, or even the USB endpoint for whatever serial adapter you have connected, it represents the UART inside the adapter that handles the serial communications. Data you read from it will not include any USB headers or framing, just like data you read from/dev/ttyS0will not include any PCI Express headers or framing. Setting the baud rate on these affects the hardware that it represents, not the bus it's connected to, so this won't do anything to the USB connection.Second, the baud rate is a hardware setting, not a software one. When you call
sttyto set it on a serial port, that is telling the kernel to tell the hardware to change what baud rate it is trying to receive data at. This means in particular that any data that was received prior to this change will either be bogus (because it wasn't interpreted correctly by the hardware, sometimes the case if the baud rates are close to each other or exact harmonics), or completely lost (because the hardware just didn't accept it, the more likely case on modern hardware).If you plan on reading data from a serial line, you need to have the baud rate set correctly prior to any data being transmitted by the other end. This also means that changing the baud rate won't change how the kernel interprets the data. If the data is already buffered in the kernel, then it's not going to change just because you change the baud rate (although it is good practice after changing the baud rate to drain the kernel buffers so that you know any future data is good).
So, to clarify, the correct method to get data out of a USB to serial adapter without using special software is to:
cat(orodif you need the byte values instead of text) to read data. This will return the exact data that is received by the USB to serial adapter (assuing the adapter doesn't do special processing).