Adds CR and LF

[Resonanz]

In serial-cat.rs if I want to send abc to the com port, the bytes actually sent are 97, 98, 99, 13, 10 which is abc\r\n.

How can the sent bytes be limited to just abc?

What is the "cat" in serial-cat btw?

[de-vri-es]

Hey!

serial-cat is named after the Unix utility cat, which is short for concatenate. That tool concatenates all files that you give as argument to standard output.

The CRLF is most likely added by your terminal when you press Enter.

On Unix you could get rid of it by doing something like echo -n 'abc' | serial-cat (although this will close the stream as soon as the input is read). However, I'm guessing you are on Windows. I don't know too much about Windows.

We could add an option to the example to strip line endings from the input. Do you feel like making a PR for that?

[Resonanz]

Thanks for the reply.

Yes, CRLF is added when using Windows. Only LF is added on Linux. In my case, the external device only works with LF thus it will not work when running your code on Windows :-)

I'm not sure if there is an elegant fix. the CRLF is coming from std::io::stdin I think so any trimming might have to be done by manipulating buffer. But it is tokio that calls `std::io::stdin'. I'm not sure if there is a way to ask tokio to ignore CRLF and/or LF?

I did find the following .trim()

https://doc.rust-lang.org/std/string/struct.String.html#method.trim

[de-vri-es]

We can't let tokio do the removing, but we can do it ourselves after reading from stdin. Note that to correctly translate between CRLF and LF, we probably also need to turn LF from the serial device into CRLF for stdout (unless Windows terminals are fine with just LF).

trim() would remove too much though. You would have to remove only the CR before a LF, but leave the LF.

In theory you could even read blabla<CR> and then read <LF> in a separate read(). That complicates things even further :)

Maaaaybe we can configure stdin() on Windows to produce <LF> directly instead of mangling the byte stream ourselves. That would be even better.

But also note that this should not be much of a problem for most applications written with the library. serial-cat is just an example program. If you implement the communication protocol directly instead of forwarding between stdin/stdout and the serial device, you shouldn't have any of these problems.

[de-vri-es]

Going to close this issue as it's an application level thing, not really a serial port level thing.

Feel free to comment if you have additional questions.