Stephane Chazelas <[EMAIL PROTECTED]> writes:
> It should be:
>
> eval "`dircolors [OPTION... [FILE]`"
Thanks for reporting that. I've fixed this in coreutils CVS.
> I've been told some Linux distributions have this kind of line
> in the system /etc/bash.bashrc
Yes, I noticed it for Debian at least. I filed Debian bugs 285836 and
285840 about this issue.
In practice, I suspect it's not a problem unless your home directory
is world-writeable -- and if your home directory is world-writeable
you're in deep trouble anyway.
Here's the patch I installed. It fixed another minor problem while I
was at it.
2004-12-15 Paul Eggert <[EMAIL PROTECTED]>
* coreutils.texi (ls invocation): Change minor problem to be
"subdirectory not found", since top-level trouble is now serious.
(dircolors invocation): Quote argument to eval. Problem reported
by Stephane Chazelas.
Index: coreutils.texi
===================================================================
RCS file: /fetish/cu/doc/coreutils.texi,v
retrieving revision 1.233
retrieving revision 1.234
diff -p -u -r1.233 -r1.234
--- coreutils.texi 12 Dec 2004 07:24:31 -0000 1.233
+++ coreutils.texi 15 Dec 2004 22:08:07 -0000 1.234
@@ -5299,7 +5299,7 @@ Exit status:
@display
0 success
-1 minor problems (e.g., a file could not be found)
+1 minor problems (e.g., a subdirectory was not found)
2 serious trouble (e.g., memory exhausted)
@end display
@@ -6205,7 +6205,7 @@ terminal for color output from @command{
Typical usage:
@example
-eval `dircolors [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]
+eval "`dircolors [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]"
@end example
If @var{file} is specified, @command{dircolors} reads it to determine which
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
