bug-coreutils
[Top][All Lists]
Advanced

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

Re: dircolors database documentation


From: Eric Blake
Subject: Re: dircolors database documentation
Date: Tue, 18 Oct 2005 06:36:58 -0600
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eric Blake on 10/17/2005 10:04 PM:
> 
> Turns out I was wrong.  Escape sequences exist, so I documented them (and
> \_ is a clever way to get space).

Meanwhile, there are a few bugs I found.  I can provide a patch, but need
some agreement on semantics first.

$ cat > file
EXEC ' echo Hello; : '
$ (eval "`dircolors -b file`")
Hello

Oops - we aren't properly quoting ' in dircolors' output.  This should be
as simple as outputing '\'' in place of ' in append_quoted().

$ vi file2
$ cat -A file2
EXEC address@hidden
$ dircolors -b file2
LS_COLORS='ex=a:';
export LS_COLORS

Oops - we aren't handling NUL.  Before I provide a patch, we need to
decide if we WANT to support NUL (in which case, we translate NUL into 0
after unquoted \, into @ after unquoted ^, and into \0 otherwise.  The
alternative is to print an error message if an embedded NUL is encountered.

Furthermore, this means it is possible to generate suffix rules that will
never match a filename (since the basename of a file cannot contain / or
embedded NUL).  Should dircolors emit an error if it encounters a suffix
rule that contains one of these two characters?  Should ls emit an error
if LS_COLORS contains a hand-constructed suffix rule with the same invalid
properties?

Then there is the matter of unterminated escapes:
$ cat > file
LEFT \
FILE f
$ dircolors file
LS_COLORS='lc=\:fi=f:';
export LS_COLORS
$ LS_COLORS='lc=\:fi=f:' ls --color file
:fi=f0m:fi=f0mfile:fi=f0m
:fi=fm
$ LS_COLORS='lc=\\:fi=f:' ls --color file
\0m\fmfile\0m
\m

Oops - the lc string parsed as ":di=d", because dircolors didn't recognize
that the \ in LEFT was unterminated, rather than parsing both lc and fi as
shown in the second run with \ quoted.  I think the best thing here it to
treat the unterminated escape as an error.

I also found a memleak in dc_parse_stream - input_line is malloc'd by
getline(), but missing a free() on a successful line parse.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDVOxp84KuGfSFAYARApIvAKC1QEkiOCKs1UkbKZ/7p33Uerr51ACeIPnI
OgVsuL1VJxCfvkueDIFJ6fw=
=HA51
-----END PGP SIGNATURE-----




reply via email to

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