Re: Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Day wrote: Yes, Bob. This problem came out because I set an alias for `ls' in my .bashrc file alias ls='ls -F --color' So when I run the script what goes in to the [] test is `ls -F --color -A ./dir' in fact. Thus issued the problem. Thanks for your msg. Hmm... But aliases are not used in scripts. Scripts shouldn't be reading your .bashrc file and therefore shouldn't be affected by aliases there. If in your environment scripts are reading you .bashrc file then you should fix it because there will almost certainly be other similar problems such as this. Are you setting ENV or BASH_ENV to your .bashrc environment file? That would cause scripts to source it. Although BASH_ENV and ENV have special uses they shouldn't be set in the normal course of events for bash. (For ksh use setting ENV is typical.) If that is the problem I think you should unset those variables. Or perhaps you are using the alias in your .bashrc file itself? Because aliases would only be expanded within the particular shell that source the .bashrc file. So if in the .bashrc script itself you were subsequently using the ls command after the alias then that would also be a problem. I usually put aliases at the very bottom of the file for this reason. In any case, you can avoid alias expansion by quoting the command. 'ls' ls \ls command ls All of those would avoid the alias expansion. Plus using --color=auto would also avoid the problem. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Eric Blake wrote: It may be worth considering a patch to coreutils, such that plain --color implies --color=auto rather than --color=always. For example, this would match how 'git config' reacts when interpreting color options (where 'auto' and 'true' are synonyms, and 'always' must be explicit). FWIW, I commonly use --color to turn color back on. My usage: I list a directory and it scrolls off screen. So I redo it with |more appended -- and then I get unhappy because I don't get the same output I just looked at now that I've added a paging option, so when color is helping sort out what is what, I re-edit again to: ls --color|more... (my more is aliased to less, FYI). Having to specify --color=always...well that's just more torture -- I have --color=auto in my LS_OPTIONS...(or the alias, forget which sometimes...). That's the only time I really want color no matter what the output, which is why I specify color=auto. I or perhaps someone else might find it disconcerting to type: ls --color|more and get no color -- what's the point of specifying --color on the command line if it doesn't turn on color? -l ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 2/12/2008 11:30 AM: | | Here's the result I'll push in a day or two: What about the corresponding patch to dircolors? I haven't done that yet. Would you like to do it? FYI, this time, I'm adding a dist check to ensure the sets of 2-letter codes in dircolors.c and ls.c are equal. It'll look something like this: dc=$(sed -n '/static.*ls_codes\[/,/};'/p src/dircolors.c \ |sed -n '/^ */p'|tr , '\n'|sed 's/^ *//' \ |sed -n 's/^\(..\)/\1/p'|sort -u) ls=$(sed -n '/static.*indicator_name\[/,/};'/p src/ls.c \ |sed -n '/^ */p'|tr , '\n'|sed 's/^ *//' \ |sed -n 's/^\(..\)/\1/p'|sort -u) test $dc = $ls || exit 1 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/12/2008 11:30 AM: | | Here's the result I'll push in a day or two: | | ls --color no longer outputs unnecessary escape sequences | In --color mode, plain files do not get any color, not even white. | When no highlighting is required, ls outputs no escape sequence at all. | (indicator_no) [C_RESET]: New enum value. | (indicator_name) [rs]: Corresponding new string. | (color_indicator): Make the 'normal' and 'file' markers be NULL. | Use rs (C_RESET) to reset to ordinary colors. What about the corresponding patch to dircolors? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsfex84KuGfSFAYARAleWAJ4vLiypc9IzO0hKhGQskqqHMdC7eACfUHV4 4o2rdm84ikMOi3gyenQ7o7w= =iy2I -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Jim Meyering [EMAIL PROTECTED] wrote: Here's the result I'll push in a day or two: ls --color no longer outputs unnecessary escape sequences BTW, that patch reduces by up to about 60% the size of the output of ls -C --color=always when there are many short-named files, e.g., as you'd see in an mh-style mailbox dir. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Eric Blake [EMAIL PROTECTED] wrote: According to Day on 2/11/2008 8:35 PM: | | [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty | | the echoed message is always Not Empty, regardless of the fact that ./dir is actually EMPTY. Below is the tested result. Thanks for the report. However, this is not necessarily a bug. By itself, --color is documented to mean --color=always, in which case ls outputs command sequences to initialize and restore colors back to normal: $ ls -A --color | od -tx1z 000 1b 5b 30 6d 1b 5b 6d .[0m.[m 007 And since that is output (even though it does not show up on the terminal), the string is non-empty, hence the result of the [] test. You really want the color output to be supressed in this context (in $() command substitution, the output is not a terminal, so color escape sequences don't normally make sense to the downstream client), so you should consider using --color=auto instead: $ ls -A --color=auto | od -tx1z 000 It may be worth considering a patch to coreutils, such that plain --color implies --color=auto rather than --color=always. For example, this would match how 'git config' reacts when interpreting color options (where 'auto' and 'true' are synonyms, and 'always' must be explicit). Sounds ok. Any other opinions? It may also be worth a patch to ls to omit color sequences altogether if there is no other output, although this may be more difficult to code and/or justify. Yes, that is worthwhile. Ed Avis wrote a patch to do just that a few years ago. It was held up due to copyright assignment processing delays, and then I forgot about it. I've just dug up the patch, merged it, and added one more test along with the usual administrivia. Here's the result I'll push in a day or two: ls --color no longer outputs unnecessary escape sequences In --color mode, plain files do not get any color, not even white. When no highlighting is required, ls outputs no escape sequence at all. * src/ls.c (print_with_color): (used_color): New global. (indicator_no) [C_RESET]: New enum value. (indicator_name) [rs]: Corresponding new string. (color_indicator): Make the 'normal' and 'file' markers be NULL. Use rs (C_RESET) to reset to ordinary colors. (process_signals): Restore default colors only if necessary. (main): Don't call prep_non_filename_text here. (print_name_with_quoting): Call it here, instead. (prep_non_filename_text): Use C_RESET, not C_NORM. (print_color_indicator): Return bool, not void. Print nothing, when possible. (put_indicator): Call prep_non_filename_text the first time. * tests/misc/ls-misc: Test for above. * tests/ls/color-dtype-dir: Adapt: no escapes around regular file name. * TODO: Remove item. * NEWS: Mention this. Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- NEWS |4 +++ TODO |3 -- src/ls.c | 60 +- tests/ls/color-dtype-dir |4 +- tests/misc/ls-misc | 17 ++-- 5 files changed, 63 insertions(+), 25 deletions(-) diff --git a/NEWS b/NEWS index e05e1c3..b9f25e6 100644 --- a/NEWS +++ b/NEWS @@ -10,6 +10,10 @@ GNU coreutils NEWS-*- outline -*- rmdir --ignore-fail-on-non-empty detects and ignores the failure in more cases when a directory is empty. +** Improvements + + ls --color no longer outputs unnecessary escape sequences + ** Consistency mkdir and split now write --verbose output to stdout, not stderr. diff --git a/TODO b/TODO index 3cec054..f8cc66a 100644 --- a/TODO +++ b/TODO @@ -133,9 +133,6 @@ Changes expected to go in, someday. Pending copyright papers: - ls --color: Ed Avis' patch to suppress escape sequences for -non-highlighted files - getpwnam from Bruce Korb pb (progress bar) from Miika Pekkarinen diff --git a/src/ls.c b/src/ls.c index 46713f2..bf94e8f 100644 --- a/src/ls.c +++ b/src/ls.c @@ -207,7 +207,7 @@ static bool file_ignored (char const *name); static uintmax_t gobble_file (char const *name, enum filetype type, ino_t inode, bool command_line_arg, char const *dirname); -static void print_color_indicator (const char *name, mode_t mode, int linkok, +static bool print_color_indicator (const char *name, mode_t mode, int linkok, bool stat_ok, enum filetype type); static void put_indicator (const struct bin_str *ind); static void add_ignore_pattern (const char *pattern); @@ -489,6 +489,12 @@ ARGMATCH_VERIFY (indicator_style_args, indicator_style_types); static bool print_with_color; +/* Whether we used any colors in the output so far. If so, we will + need to restore the default color
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
Day wrote: I found this bug when I tried a tiny script which checks a directory is empty or not. [ $(ls -A ./dir) ] echo Not Empty || echo Empty So far so good. After `mkdir ./dir' and without adding anything into ./dir, run the script, the echoed message is Empty. But when adding the `--color' option to `ls', The --color option forces color codes on. You wanted to use 'ls --color=auto' instead. [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty Using --color=auto allows ls to selectively turn color on or off depending upon whether the output is a tty device or not. That is the right option for you to use instead of --color which is the same as saying --color=always. Obviously you don't want to use any --color* options there at all. But I assume this is reduced from a larger test case where if seen in the real case would make more sense. the echoed message is always Not Empty, regardless of the fact that ./dir is actually EMPTY. Below is the tested result. Although I think it is a little strange that 'ls --color=always' does output terminal initialization codes when there is nothing to list I don't think this can be catagorized as a bug when color has been forced on manually. This doesn't happen with --color=auto for instance. [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty How did you happen to run into using 'ls --color' in a test such as this? That seems an unfortunate option choice there. I recommend not using --color there. But obviously you already thought of that and so I have to ask what you were doing that caused it to be there? Why not simply avoid saying anything there? Why not simply use 'ls' without color? Could you say a few more words about how you came about this problem? Thanks Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: the `--color' option of `ls' shadows the shortcut evaluation scheme of `' and `||'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Day on 2/11/2008 8:35 PM: | | [ $(ls -A --color ./dir) ] echo Not Empty || echo Empty | | the echoed message is always Not Empty, regardless of the fact that ./dir is actually EMPTY. Below is the tested result. Thanks for the report. However, this is not necessarily a bug. By itself, --color is documented to mean --color=always, in which case ls outputs command sequences to initialize and restore colors back to normal: $ ls -A --color | od -tx1z 000 1b 5b 30 6d 1b 5b 6d .[0m.[m 007 And since that is output (even though it does not show up on the terminal), the string is non-empty, hence the result of the [] test. You really want the color output to be supressed in this context (in $() command substitution, the output is not a terminal, so color escape sequences don't normally make sense to the downstream client), so you should consider using --color=auto instead: $ ls -A --color=auto | od -tx1z 000 It may be worth considering a patch to coreutils, such that plain --color implies --color=auto rather than --color=always. For example, this would match how 'git config' reacts when interpreting color options (where 'auto' and 'true' are synonyms, and 'always' must be explicit). It may also be worth a patch to ls to omit color sequences altogether if there is no other output, although this may be more difficult to code and/or justify. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsSpu84KuGfSFAYARAtC2AJ9tkXl1dAXlU9JcXiAOq7B6Te7I5ACdEL5G tbFOIuLMuC30mMwqXvLfsVE= =3aQY -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
