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.)
Based on flabdablet's answer, for me it looks like easiest (not necessarily fastest) is just to use find itself, while leaving glob expansion on shell, like:
Or in
if
like:This abomination seems to work:
It probably requires bash, not sh.
This works because the nullglob option causes the glob to evaluate to an empty string if there are no matches. Thus any non-empty output from the echo command indicates that the glob matched something.
If you have globfail set you can use this crazy ( which you really should not )
or
Escape the pattern or it'll get pre-expanded into matches.
Exit status is:
stdout
is a list of files matching the glob.I think this is the best option in terms of conciseness and minimizing potential side effects.
UPDATE: Example usage requested.
Explanation
When there isn't a match for
glob*
, then$1
will contain'glob*'
. The test-f "$1"
won't be true because theglob*
file doesn't exist.Why this is better than alternatives
This works with sh and derivates: ksh and bash. It doesn't create any sub-shell.
$(..)
and`...`
commands create a sub-shell; they fork a process, and therefore are slower than this solution.ls | grep -q "glob.*"
Not the most efficient solution (if there's a ton of files in the directory it might be slowish), but it's simple, easy to read and also has the advantage that regexes are more powerful than plain bash glob patterns.