Web lists-archives.com

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




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: cygcheck.out
Description: Binary data

--
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