Re: nl-command bug

From:

Bob Proulx

Subject:

Re: nl-command bug

Date:

Sat, 3 Dec 2005 17:52:52 -0700

User-agent:

Mutt/1.5.9i

Silvano Catinella wrote:
> I have discovered a little bug in nl command written by Scott Bartram and
> David MacKenzie. When I push an ASCII-color-text into the pipe used by nl, I
> can see a very strange behavior.
Thanks for the report. But this does not look like a bug in nl to me.
> Usually, if I use "-b t" argument I would see no line-number before
> empty line.
The line is actually not empty. That seems to be the confusion.
> But with ASCII-color the program considers escape-codes (\033[....m) as text
> and prints number before empty lines. For example the following command
>
> $ ls coreutils-5.93 --color=always |nl -b t
>
> ...produces the following output:
>
> 1 ABOUT-NLS
> 2 AUTHORS
> 3 COPYING
> [ ... ]
> 28 po
> 29 src
> 30 tests
> 31
>
> "tests" file has blue color because it is a directory, and, as you
> can see the nl-process prints a empty line (31) next.
Eric Blake wrote:
> The behavior is admittedly strange, but it is not a bug. The last
> line with escape codes is not empty even though the escape codes don't
> show up visibly on the terminal.
Agreed. You can see these characters by piping the result through
'od -c' or 'cat -v' or some such to make all characters visible.
ls --color=always |nl -b t | cat -v
...
30 ^[[01;34mtests^[[00m/
31 ^[[m
> In general, piping terminal escape sequences to other programs leads
> to surprising results; hence it is usually better to use ls
> --color=auto instead of --color=always, so that you only get
> terminal escape sequences when writing directly to a terminal.
Agreed.
Bob