this post was submitted on 30 Jun 2026
51 points (100.0% liked)

Linux

14231 readers
952 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 3 years ago
MODERATORS
Ategon@programming.dev
anzo@programming.dev
dwraf_of_ignorance@programming.dev
51
A Surprisingly Common Mistake Involving Wildcards & The Find Command (blog.robertelder.org)
submitted 1 week ago* (last edited 1 week ago) by unglueclass23@programming.dev to c/linux@programming.dev
9 comments fedilink hide all child comments
 

I came across this older article from 2020 and I found it informative. It's about how the shell does globbing and the potential issues it can cause if not understood correctly.

TLDR:

find . -not -name *.py -delete and find . -not -name '*.py' -delete will behave differently in certain scenarios.

In the first example, the shell will replace the wildcard pattern with a list of matching file names IF there are any matches in the current directory. If there isn't, then it won't do anything and will pass *.py to find.

In the second example, the shell won't do any globbing at all and will just pass *.py

you are viewing a single comment's thread
view the rest of the comments
[–] p_consti@lemmy.world 3 points 1 week ago (2 children)

Using zsh will gelp with that mistake, because by default it will turn the 'no matches' scenario into an error. But seriously, always quote your arguments if there is any chance for ambiguity (also for variables)

[–] unglueclass23@programming.dev 2 points 1 week ago

I use bash and it did throw that error, however the find . | egrep *.py example at the end did not.

[–] fruitcantfly@programming.dev 1 points 1 week ago

It took a while to get used to zsh bailing on non-matching wildcards, but it honestly makes a lot more sense