When printing files with Windows line endings (CRLF), less shows carriage return ^M in blank lines when option --hilite-unread is used. Lines with any text display correctly, skipping the carriage returns.

I read through the manual, and it seems it should be the same as long as CR is followed by LF. Adding --raw-control-chars removes the markers, but its use is not recommended, and it has other consequences which I do not want.

$ printf 'first\r\n\r\nsecond\r\n' | LESS= less --quit-if-one-screen


$ printf 'first\r\n\r\nsecond\r\n' | LESS= less --quit-if-one-screen --hilite-unread

$ printf 'first\r\n\r\nsecond\r\n' | LESS= less --quit-if-one-screen --hilite-unread --raw-control-chars


Is that a known bug in less, or is there something I could do? For now I will just resign from using --hilite-unread.

Interestingly when text is long enough to scroll, when scrolling back up the ^M markers dissappear. So these are only displayed for the freshly printed lines. Possibly less does not yet know that LF will be there? But then why does it work for lines with text?

I use Git for Windows, versions: git 2.43.0.windows.1, bash 5.2.21(1), less 643.

1 Answer 1


Some time after posting the question, I have realized this must have been a bug, and created a bug report in the less repository, which was then promptly confirmed and fixed by the developer.

For future reference, the problem was introduced in less 571 (Dec 30, 2020) and the fix will probably be included in the next version, ie. less 650 (not yet released as of Feb 4, 2024).

The --hilite-unread (or --HILITE-UNREAD) inserts a space in blank lines so that there is always a character to highlight. If the line ends with CR/LF, it will now put the space before the CR, not between the CR and the LF. Thus the CR will be correctly recognized as part of the line ending, and not displayed as ^M.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .