find . -name \*.jpg
This is pretty elementary which any seasoned Linux person should know.
A common mistake involving wildcards and the find command
21–30 of 148 posts
Re: A common mistake involving wildcards and the find command
#22Globbing is also more complex than it seems on first blush.
Alternation is supported in bash. Stuff like "echo ∗.{png,jp{e,}g}" (utf8 asterisk to get around HN, cut/paste won't work).
That bsd derived glob is useful for some sometimes useful tricks. Like in Perl:
use File::Glob qw/bsd_glob/;
my @list = bsd_glob('This {list|stuff} is nested {{very,quite} deeply,deep}');
Re: A common mistake involving wildcards and the find command
#23I often set the nullglob option in scripts, because it makes the handling of globs which don't match anything a bit more predictable: http://bash.cumulonim.biz/NullGlob.html There's a note at the end about how with nullglob set, ls on a glob with no matches does something surprising. This is a great illustration of how an empty list and the absence of a list are different. Sadly it's rather hard to make that distinct…
I set failglob: `shopt -s failglob`. Makes the whole command fail if there's no matches. That combined with `set -e` which aborts the script in the event of any command failing makes me feel somewhat safe.
Indeed I add the following two lines to every bash script I write:
set -exu
shopt -s failglobRe: A common mistake involving wildcards and the find command
#24As another user mentioned, many POSIX and/or GNU utilities havent aged well. I respect trying to stay portable, but peoples needs change over time and these tools simply havent kept up. Like the other user, I use Fd now instead: https://github.com/sharkdp/fd As well as Silver Searcher: https://github.com/ggreer/the_silver_searcher while Grep performance is pretty good, its also gotten pretty stale with regard to its…
Wouldn't you have the same problem with fd if you invoke it on unquoted globs? The problem is the semantics of the shell, not find.
Yes, but fd has implicit pattern matching without requiring the * character:
Features:
Convenient syntax: fd PATTERN instead of find -iname '*PATTERN*'Re: A common mistake involving wildcards and the find command
#25Straight from The UNIX-HATERS Handbook. https://web.mit.edu/~simsong/www/ugh.pdf
Re: A common mistake involving wildcards and the find command
#26For a long time (probably since the first time I forgot to quote something and got burned, so around 40 years), I've thought that there should be some mechanism for the shell to pass in information about how each argument came about.
For each argument, it would tell the program if it was supplied directly, or came from wildcard expansion. For those from wildcard expansion, it would tell the program what the wildcard was.
Most programs would not care, but some programs could use this to catch common quoting errors.
Re: A common mistake involving wildcards and the find command
#27at my workplace I use git bash on windows, and because i'm always getting
man: command not found
I flick to a browser and type
man
About once a year I forget what happened all the previous times I typed
man find
TLDR: looking for Dennis Ritchie, I found Chuck Tingle.
Re: A common mistake involving wildcards and the find command
#28The title seems a bit off since shell expansions and arguments has nothing to do with the find command.
Both features are also often covered in entry level material for introduction to shell.
Re: A common mistake involving wildcards and the find command
#29The title seems a bit off since shell expansions and arguments has nothing to do with the find command. Both features are also often covered in entry level material for introduction to shell.
Most commands don’t accept the shell-like wildcard `*` as part of their command syntax; find does. That’s the connection.
Re: A common mistake involving wildcards and the find command
#30My instant reaction to the example was “that won’t work; you’re shell will say something like ‘no matches’”.
Using an unescaped star in a find command never works for me, which is a lot better than it sometimes working and sometimes breaking!
Reading the article and the comments, it seems like bash doesn’t do this? I suppose it’s one nice thing about oh-my-zsh, whose default confit I use almost unchanged.