If I want to check for the existence of a single file, I can test for it using test -e filename
or [ -e filename ]
.
Supposing I have a glob and I want to know whether any files exist whose names match the glob. The glob can match 0 files (in which case I need to do nothing), or it can match 1 or more files (in which case I need to do something). How can I test whether a glob has any matches? (I don't care how many matches there are, and it would be best if I could do this with one if
statement and no loops (simply because I find that most readable).
(test -e glob*
fails if the glob matches more than one file.)
Note that this can be very time cosuming if there are a lot of matches or file access is slow.
The nullglob shell option is indeed a bashism.
To avoid the need for a tedious save and restore of the nullglob state, I'd only set it inside the subshell that expands the glob:
For better portability and more flexible globbing, use find:
Explicit -print -quit actions are used for find instead of the default implicit -print action so that find will quit as soon as it finds the first file matching the search criteria. Where lots of files match, this should run much faster than
echo glob*
orls glob*
and it also avoids the possibility of overstuffing the expanded command line (some shells have a 4K length limit).If find feels like overkill and the number of files likely to match is small, use stat:
I like
This is both readable and efficient (unless there are a huge number of files).
The main drawback is that it's much more subtle than it looks, and I sometimes feel compelled to add a long comment.
If there's a match,
"glob*"
is expanded by the shell and all the matches are passed toexists()
, which checks the first one and ignores the rest.If there's no match,
"glob*"
is passed toexists()
and found not to exist there either.Edit: there may be a false positive, see comment
I have yet another solution:
This works nicely for me. Are there some corner cases I miss?