There's a weird bug with grep where it finds (and displays) stuff that doesn't exist. It only happens by adding a 'm' at the beginning. The 'm' dissappears with removing grep colors (by piping in cat for example), but the false positive is still there 100% reproducible example, starting from an empty directory: orzel@berlioz orzel/tmp/grepbug% touch abc.txt orzel@berlioz orzel/tmp/grepbug% ls | grep mab mabc.txt # 'mab' is in red orzel@berlioz orzel/tmp/grepbug% ls | grep mab | cat abc.txt It works with standard input (as previous exemple) and also from inside a file. I can reproduce it with both sys-apps/grep-2.21-r1 and sys-apps/grep-2.22 Reproducible: Always
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.
