CLI lineend character, best choice, docu?

[olliw42]

two users just had issues with the cli and its default lineend maybe we should add some comments to the docs and/or recommend a terminal

not sure how but maybe there is a way to track which default lineend would be best suited. It seems a new set of users are flowing in with new & different experiences and practices.

[miszaklajent]

If you are using PIO, paste monitor_eol = CR in your .ini file, and use esp 32 as a ttl with

include

include

HardwareSerial mySerial(1);

void setup() { // Initialize USB serial communication for debugging Serial.begin(115200);

// Set pins for UART1 (TX and RX) const int uart1_tx = 17; const int uart1_rx = 16;

// Configure UART1 with the required settings - true here inverts the signalling mySerial.begin(115200, SERIAL_8N1, uart1_rx, uart1_tx, true); }

void loop() { // Check for data from USB serial while (Serial.available()) { // Read data from USB serial int data = Serial.read(); // Write data to UART1 mySerial.write(data); }

// Check for data from UART1 while (mySerial.available()) { // Read data from UART1 int data = mySerial.read(); // Write data to USB serial Serial.write(data); } } code, it seems to work really well

[jlpoltrack]

maybe we should add some comments to the docs and/or recommend a terminal

Seems reasonable, can add something to the CLI page.

maybe there is a way to track which default lineend would be best suited

The default for Windows is CR LF - so if we think most users are Windows users then this may be best. LF is used by Mac and Unix, whereas no OS uses CR by default.

Source: https://stackoverflow.com/a/1552775

[olliw42]

this are the line ends of files, right. not terminal specific. I mean, nearly no one doing a quick c code line would write \r\n :) I wonder how CR came about, maybe it was meant to be LF? Also why we didn't we had a constant stream of complaints so far. It's CR like forever.

Should we conclude we want to change to LF per default?

[brad112358]

Since you are asking... I have always thought that sending just CR in the CLI was not ideal, especially for new users, but it is so easy with most terminal emulators to have the LF added that I didn't bother to suggest a change or do a PR.

I believe the most compatible line ending when the data stream is expected to go directly to a terminal emulator is to include both CR and LF. I think this will result in the least confusion and new user questions. My second choice would be just LF.

The reason for my opinion is defaults and the history of terminals.

Before we had terminal emulators, we had dumb terminals. Before that, we had teletypes. Before that we had electric typewriters and before that we had manual typewriters. Manual typewriters could literally have their carriage positioned manually to any point on the page, but most of them also had a lever which moved the paper up one line with a quick bump and also could return the carriage back to the beginning by moving the lever farther. A second bump would double space. Or, you could also return the carriage back to the beginning of the same line by moving it without the lever. Note that the LF and CR actions are independent, but unless you want to underline or strike out or overstrike for darker (bold) text or special combination marks, you usually want both.

Later, when teletypes came out, the ability to overstrike was maintained by defining separate CR and LF control characters, but you always send both for simple text.

Then, when dumb CRT based serial terminals were introduced, the separate CR and LF was useful for things like updating status lines, etc. Some graphics terminals like those made by Tektronix which used storage CRTs could utilize general overstrike capabilities as well. The ability to position the cursor and place a character at any location on the screen was quickly added to terminals, though they didn't all use the same control characters for cursor addressing.

In theory, terminal emulators emulate a specific type of CRT terminal and if they do so accurately, then, by default, they will not move the cursor to the beginning of the line when just a LF is received and they will not advance the line when just a CR is received. Of course, this ignores the complication of any translation the OS might do. On Unix/Linux systems, it is common for the TTY subsystem to be in a mode which adds the CR when a LF is received, but terminal emulators which connect to serial ports should place the TTY subsystem in raw mode, so, nothing is added.

If we send CR+LF in the CLI, then, if terminal emulator is in a mode which emulates a real terminal (hopefully the default), it will add nothing and we get what we want. If it adds a CR when it sees LF, we still get what we want because the extra CR does not move the cursor. If it adds LF when it sees CR, we get double spaced text which I think is more usable than when the text walks off the right hand side of the screen or when everything is overwritten on one line.

[olliw42]

many thx, much appreciated. so, if I read you correctly, you woud suggest crlf as default, right

[brad112358]

so, if I read you correctly, you woud suggest crlf as default, right

Yes, sorry if I used way too many words to say that. :)

[olliw42]

not at all,much appreciated justed wanted to double check to be sure

[olliw42]

default changed to crlf THX !!