Binary package hint: coreutils
ls --color=always outputs a (seemingly) extraneous ESC [ m after everything else, which makes less -RX show an extra blank line.
Note that ESC [ m is the ANSI escape sequence ESC [ <parameters> m with empty <parameters>.
Does a "null mode set" do anything? I can't find any documentation saying that it's other han a no-op,
but maybe some terminal somewhere requires (required?) this "no-op" to behave correctly (?)
In any case, the extra "no-op" escape sequence appears after the final newline, and therefore
constitutes an extra unterminated line. In an interactive shell this is invisible, but if the output it piped
through a pager such as less -RX then the extra line can cause an extraneous blank line to appear.
SUGGESTED SOLUTIONS:
If the "no op" escape sequence is really a no-op, then don't output it;
If it is necessary, then output it before the newline of the final item, so it will not constitute an unterminated extra line.
I'll attach a tar archive of the test directory used in the following examples:
bash>env - /bin/ls -l --color=always | less -FXR
total 120
-rw-r--r-- 1 jima jima 0 Dec 9 09:57 afile
-rwxr-xr-x 1 jima jima 114032 Oct 6 04:06 bexecutable
-rw-r--r-- 1 jima jima 0 Dec 9 09:58 bfile
-rw-r--r-- 1 jima jima 0 Dec 9 09:58 cfile
bash> #note EXTRA BLANK LINE above
bash>(env - /bin/ls -l --color=always; echo ==AFTER==) | cat -teuv
total 120$
-rw-r--r-- 1 jima jima 0 Dec 9 09:57 afile$
-rwxr-xr-x 1 jima jima 114032 Oct 6 04:06 ^[[0m^[[01;32mbexecutable^[[0m$
-rw-r--r-- 1 jima jima 0 Dec 9 09:58 bfile$
-rw-r--r-- 1 jima jima 0 Dec 9 09:58 cfile$
^[[m==AFTER==$
bash> # Note the colorization of the executable, which is correct, and the final ESC [ m which causes trouble.
ProblemType: Bug
Architecture: amd64
Date: Wed Dec 9 10:21:20 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: fglrx
Package: coreutils 7.4-2ubuntu1
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.52-generic
SourcePackage: coreutils
Uname: Linux 2.6.31-16-generic x86_64
XsessionErrors:
(gnome-settings-daemon:2128): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
(gnome-settings-daemon:2128): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
(nautilus:2197): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
(polkit-gnome-authentication-agent-1:2229): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(rhythmbox:2224): Rhythmbox-WARNING **: Could not open device /dev/radio0
Thank you for opening this bug and helping make Ubuntu better. The "ESC[m" sequence at the end of a 'ls --color' (or --color=auto, or --color=always) is added to reset the colouring to the default values.
I am not sure, however, on how necessary this is -- a _few_ tests I performed, on a hacked version of 'ls' that does *not* add in the reset sequence showed no problems -- but, again, (1) few tests; (2) rather incomplete; (3) and I am quite sure this is there because some terminal needs it...
Nevertheless, I cannot repeat your problem -- if I pipe 'ls' output to another programme, I see *no* colouring codes being output. As such, I wonder if you are forcing '--color=always' to the pipe. This would, most probably, be a bad move.