grep aliases in .bashrc prevent use of extra flags in Ubuntu
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
As you can see, it's also searching sql files for some reason despite the --include parameter. What the heck?
I think it may have something to do with the .bashrc alias for grep:
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
Can anyone help me fix this problem? I really need to search only my php files.
Actually, now that I look at it, the alias only adds --color=auto to the command, which shouldn't affect the way the files are read at all.
I'm testing it out myself now, and so far I see pretty much the same effect. The --include option isn't really narrowing down the search. I wonder if it has anything to do with the recursive option or shell globbing?
The issue is not the command or the aliases. This is partly born out by the fact that none of the solutions in post #2 make a difference.
The issue you have is that the asterix is expanding to all the files in the current directory.
You should find that once on any level lower than current directory, the only files being returned will be php files (as per your example)
Not sure if grep has a hard and fast solution for this, but of course you could use find to restrict to php files and then use your grep in the -exec.
It certainly does seem to be a globbing problem or something, but I'm not getting any consistent results from any of my tests. Nothing I do seems to have any logical relationship to what the man page or my previous experience tells me it should. In particular:
--include=GLOB Search only files whose base name matches GLOB (using
wildcard matching as described under --exclude).
This description doesn't give any indication that globbing would override it. I've also just gone through the entire info file and found nothing about it. The closest it says about it is that this:
nice work, grail. That command does indeed seem to produce the results I'm after (it returns 55 results instead of 57, the difference being the two sql files).
However, this doesn't explain why the --include flag fails to exclude the sql files. From the man page:
Skip files whose base name matches GLOB (using wildcard matching). A file-name glob can use *, ?, and [...] as wildcards, and \ to quote a wildcard or backslash character
Search only files whose base name matches GLOB (using wildcard matching as described under --exclude).
Unless I'm missing something, 2011_02_11_dump.sql does not match a GLOB of *.php.
What's more irritating (and more confusing) is that Ubuntu behaves differently than every other linux distro (and Mac OSX 10.5) that I've ever used. Bizarre.
Well I am not familiar with these 2 options before today, but searching around I found reference that indicated that they are only in effect when used with a recursive
search and then only affect directories not files, hence again the fact that * expands to all files in the current directory they are getting searched.
I have not found collaboration of this information in the man pages.
grail, let me first say I'm grateful for your knowledge. that command is going to work for me i think. I can get over the fact that the man pages specify FILE as the last arg and "." is a directory.
However, the --include flag does in fact filter all files to be searched and NOT directories when used in a recursive search. At least this has been my experience on numerous other platforms including fedora, centos, and debian. I believe you are also correct that --include and --exclude also only apply in a recursive search. The use of --include in a non-recursive search appears to have the opposite effect. Note that the --include flag below results in no search results:
Having just typed that, I'm starting to understand what you are saying. That last asterisk tells grep to search not just the current directory (.) but also every file in the current directory and the --include param has a reversed effect on the current directory and works properly on all subdirs. I'm not certain, but I believe other distros don't work this way.
David, thanks also for your insights here -- and also for bearing witness to the confusing behavior -- at least inasmuch as the documentation doesn't adequately describe how this function works.
We also have to recognize that there are two levels of globbing going on here. The * in --include="*.txt" is globbing done by grep, while the * at the end of the command is globbing done by bash.
In bash, * expands to a list of all files in the current directory (or whatever directory is specified by a partial match). After globbing expansion is done, bash runs the command on the expanded filelist.
grep 'foo' * in a directory containing two files and one subdirectory really means grep 'foo' file1 file2 dir1.
grep then performs its globbing on the files/directories passed to it by bash.
I think the following output in my last post is telling.
Notice how the lvl1 file appears first, then it jumps down to lvl3 for the next match. That means that grep is processing the current directory first, then working its way recursively through the subdirectory tree.
So I'm guessing that grep is processing everything passed to it by the shell globbing in order, and if that something is a directory, it also processes that recursively.
Although I notice now that my test also failed to match foofile-lvl1.txt. It certainly does seem like the --include is acting like an --exclude on the top level.
I added a second subtree to my test, and came up with this.
It looks like grep only filters files if it processes the directory itself during recursion. If you pass it a filename directly, through globbing or otherwise, it will accept that as input, whether or not it matches the --include or --exclude globs.
Except for that bizarre top-level exclusion, of course.
Last edited by David the H.; 04-20-2011 at 12:36 AM.
Reason: minor rewording