Bug in zsh and bash with builtin ls when colorization is used and the filename starts with a drive letter

Bug in zsh and bash with builtin ls when colorization is used and the filename starts with a drive letter

[Ronald Fischer]

[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]

I have in my .zshrc:

    alias "ls=ls --color=auto"
    export
    LS_COLORS="di=1;4;33:*rc=7:*.rb=32:*.irbrc=32:*.sh=36:*.zsh=36:*.bak=2:*~=2:*.log=34;*.txt=34:ex=1"


Now compare these two commands and their output:

$ ls -l
C:/cygwin64/home/fisrona/gitwrk/vp5/manualtest/logs/manualtest_222.log
-rw-r--r-- 1 fisrona Domain Users 5771150 Aug  1 16:33
xt=34mC:/cygwin64/home/fisrona/gitwrk/vp5/manualtest/logs/manualtest_222.log
$ command ls -l
C:/cygwin64/home/fisrona/gitwrk/vp5/manualtest/logs/manualtest_222.log
-rw-r--r-- 1 fisrona Domain Users 5771150 Aug  1 16:33
C:/cygwin64/home/fisrona/gitwrk/vp5/manualtest/logs/manualtest_222.log

The output in both cases is printed in the same way, but as you can see,
the zsh builtin ls displays a strange "xt=34m" in front of the file
path, while /usr/bin/ls does not. 

Further investigation shows that this happens only if the file path
starts with a drive letter (here: C:) and the -l option is requested.

When setting --color=always and piping the output into a hex viewer, I
can see that the what is getting prefixed to the file path is:

0000020   r   o   n   a       D   o   m   a   i   n       U   s   e   r
           6f72    616e    4420    6d6f    6961    206e    7355    7265
0000040   s       5   7   7   1   1   5   0       A   u   g           1
           2073    3735    3137    3531    2030    7541    2067    3120
0000060       1   6   :   3   3     033   [   0   m 033   [   3   4   ;
           3120    3a36    3333    1b20    305b    1b6d    335b    3b34
0000100   *   .   t   x   t   =   3   4   m   C   :   /   c   y   g   w
           2e2a    7874    3d74    3433    436d    2f3a    7963    7767
0000120   i   n   6   4   /   h   o   m   e   /   f   i   s   r   o   n
           6e69    3436    682f    6d6f    2f65    6966    7273    6e6f

We can see here, that part of the text inside the LS_COLORS variable
(i.e. ;.txt=34m) has been placed in the output.

It is interesting that this happens only if we have a drive letter. If I
write

   ls -l
   /cygdrive/c/cygwin64/home/fisrona/gitwrk/vp5/manualtest/logs/manualtest_222.log

instead, the error does not occur.

This is with zsh 5.3, which is what I'm usually using. For curiosity, I
tested the same with bash, and the bash ls builtin command seems to
behave the same as zsh.




[-- Attachment #2: cygcheck.out --]
[-- Type: application/octet-stream, Size: 86689 bytes --]

[-- Attachment #3: Type: text/plain, Size: 219 bytes --]


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bug in zsh and bash with builtin ls when colorization is used and the filename starts with a drive letter

[Vlado]

On 1.8.2017 16:59, Ronald Fischer wrote:
> This is with zsh 5.3, which is what I'm usually using. For curiosity, I
> tested the same with bash, and the bash ls builtin command seems to
> behave the same as zsh.

Hi,

are You sure?

I run man bash, then /^SHELL BUILTIN COMMANDS and see ... kill, let, 
local, logout, mapfile, ...

No ls.

Check Your LS_COLORS value for missig ':' separator between *.log and 
*.txt definitions.

Vlado


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Bug in zsh and bash with builtin ls when colorization is used and the filename starts with a drive letter

[Brian Inglis]

On 2017-08-01 11:45, Vlado wrote:
> On 1.8.2017 16:59, Ronald Fischer wrote:
>> This is with zsh 5.3, which is what I'm usually using. For curiosity, I
>> tested the same with bash, and the bash ls builtin command seems to
>> behave the same as zsh.
> are You sure?
> I run man bash, then /^SHELL BUILTIN COMMANDS and see ... kill, let, local,
> logout, mapfile, ...
> No ls.
> Check Your LS_COLORS value for missig ':' separator between *.log and *.txt
> definitions.

export
LS_COLORS="di=1;4;33:*rc=7:*.rb=32:*.irbrc=32:*.sh=36:*.zsh=36:*.bak=2:*~=2:*.log=34;*.txt=34:ex=1"
      ^ . missing                                                   ^ s/b :

To avoid these typos, you might want to look at using the proper coreutils tool
dircolors, copy its default config file /etc/defaults/etc/DIR_COLORS to
~/.dircolors, customize it, and use it, e.g.:

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" \
				|| eval "$(dircolors -b)"
    alias ls='ls --color=auto'          # classify files in colour
    alias dir='dir --color=auto'
    alias vdir='vdir --color=auto'
fi

Check out the other defaults in /etc/defaults/etc/ for other shell profile
stanzas and tools you can use in your profiles.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple