Summary: | sys-apps/grep false positive - bug related to color output | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Capricelli <orzel> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | mjo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Thomas Capricelli
2015-11-24 01:29:35 UTC
The 'm' is really there. Your terminal hides certain character sequences from you. In particular, it hides the color escape sequences. Try this, for example: $ echo -e "\e[31mRed" So what you're seeing is that `ls` is outputting not just the name of the file, but a color code followed by the name of the file. And as you can see above, that color escape code happens to end with an 'm'. If you want to reliably grep the output of ls, use `/bin/ls` or $(which ls) so that you don't get colored output from some alias. Indeed this is fixed by using \ls instead of ls which is an alias to 'ls --color'. As shown by the 'grep | cat' example i've given, grep is smart enough to NOT output colors when stdout is not a tty, but ls doesn't have this smartness.. right ? Too bad. I guess we should close the bug as CANTFIX then ? ls is behaving correctly. `ls --color` is the same as `ls --color=always`, and that (by design) does not check if stdout is a tty. Gentoo's default already does the correct thing: $ grep ls= /etc/bash/bashrc alias ls='ls --color=auto' yeps, indeed. ls --color was an alias from my ~/.cshrc. Sorry for the noise. |