Sorry, because I don't have a serial port, the function of the serial port may be imperfect. If you can, please use the following simpler steps to quickly collect the log for analysis:

• Open the serial session.
• Check menu "Main Menu - Mode - Debug Mode".
• Reproduce the print output.
• Uncheck menu "Main Menu - Mode - Debug Mode".
• Click the menu item "Right click menu - Log - Open Log Folder".
• Open the folder debug and paste your log file in your comment here. You can zip it before upload.

The log content is in plain text and will not contain any private information. You can use any editor to view it. Thank you.

BTW,
This problem should be caused by incorrectly parsed newline characters, but I still don't know why it is not parsed correctly. There should be more clues in the log.

[
2021-07-28_15.32.23.log
](url)
This is the debug log.
SecureCRT have same problem, but setting as below, can fix this problem.

Thank you very much. I have analyzed the log initially, and there is no error in the parsing process, as you mentioned, so is SecureCrt.

Among the fix methods of the SecureCrt you mentioned, the one that really works is "New line mode".

New line mode

Check this option to have the ENTER key generate both CR and LF characters. In addition, any LF, FF, or VT character will cause the text cursor to be moved to the first column of the next line. When New line mode is not selected, the ENTER key generates only the CR character. By default, New line mode is not selected.

Usually CR is responsible for moving the cursor to the beginning of the line, and LF is responsible for moving the cursor to the next line. But your device only sends LF characters, which causes the cursor to never return to the beginning of the line. When you set "New line mode" in the SecureCrt, this setting will force the caret back to the beginning of the line when encountering LF, thus solving this problem.

In fact, this setting should be set by the device notifying the client when it is started, but I don't know why the device did not notify the client.

I will provide "New line mode" in the next prerelease version, please keep follow, thank you.

I forgot. If your device system supports echo, you can try to execute the command echo -e "\033[20h" after the session started, which can temporarily enable "New line mode" in the current session, and can solve this problem. You can try it, good luck.

Thanks for the fast response, i will try with echo.

Sure. The new prerelease version should be released next week. Since WindTerm already supports "New line mode" internally, it just needs to add a setting interface. I will update the progress here. 😄

My device system don't support echo , Look forward to your setting interface.

@dbitc
Okay, after the WindTerm_2.2.0 version is released, I will complete this feature first and release it in the WindTerm_2.3.0_Prerelease_1 version, which is expected to be released early next month.

I am happy to inform you that WindTerm_2.3.0_Prerelease_3 has been released and this issue has been fixed. The New Line Mode setting is in the dialog Session Settings - Serial - Terminal - Mode - New Line Mode (NLM), please download and check it, thank you.