Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I tried finding some files (*.e*) that are in the same directory as another file (md.tpr). I needed to list them (for further processing) using the following:

find . -name md.tpr -execdir ls *.e* \;

I tried a few variants of this command and some others (including single quoting the command passed to -execdir or passing it as sh -c 'ls *.e*' or eval 'ls *.e*' to name a few). It appears that globbing is not working when passed to -exec or -execdir. The error I get when running the above command is:

ls: *.e*: No such file or directory

Just as a sanity check, I did -execdir pwd and it prints what it should, so it appears that it's a problem with globbing, as those *.e* files do exist in the directories listed with this test.

Now, I was able to solve this problem in a much less elegant way but it just baffled me why globbing and wildcards wouldn't work here. Any ideas? Or am I completely off the track?

I use bash 3.2.25 (old but I don't have admin rights on that system).

Also, interestingly, if I do

find ~ -name .bashrc -maxdepth 2 -execdir ls -d .b* \;

it doesn't work unless it's done from $HOME.

share|improve this question
Using find to ls seems a bit redundant, and I hope you were careful if you tried to parse the output. –  jw013 Nov 9 '12 at 21:46
Yes, I am not worried about any unexpected characters in file names, so I wasn't bothered about the ls. The point was to find some files that live in the same file as another file (and then process them further). –  Wojtek Rzepala Nov 9 '12 at 23:09

1 Answer 1

The shell does globbing, not find. When you type a command that includes an unquoted glob like .b* or *.e*, the shell will expand that for you. This happens before find ever sees it.

You probably have files like .bashrc, .bash_history, etc. in your $HOME directory. So when run from $HOME, your command turns into find ... -execdir ls -d .bashrc .bash_history ... \;. When run from other places, the .b* glob doesn't match anything, so it gets passed through. This still doesn't work, as it is the shell that does globbing, not find -exec. If you wanted the glob to be expanded for the -exec, you would need to invoke a shell to do it:

find ... -execdir sh -c 'echo globs: *' \;
share|improve this answer
Yes, true. I guess I'm baffled about the behaviour because doing things like find ... -name '*.txt' works (yes, yes, single quotes) and handles those globs properly, but when I pass such globs to -exec[dir], it fails. I made a comment in my post about single quotes and no quotes as at some point I did try everything, so dropping the quotes was the first thing I did, trying to figure out why things failed. The last example was to show that even the obvious thing didn't work (yes, I was expecting to see .bashrc, .bash_history, etc.). –  Wojtek Rzepala Nov 9 '12 at 23:12
@WojtekRzepala -exec and -name work differently. -name does support globs. –  jw013 Nov 10 '12 at 0:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.