[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]