globbing wildcards or why **/* means different things

In my previous post on globbing, I looked at how to glob multiple file types simultaneously (while narrowing only to a specific set). I also asserted the following:

1. The /**/* part says starting in src, look at every directory (and directory of directories), all the way down look at all files

This, it turns out is not quite how that works. Or rather, it depends on which shell is being used.

I noticed the difference when running eslint in a zsh environment:

% eslint **/*.js

zsh: argument list too long: eslint

I was fairly certain that this was the pattern I’d used previously, so I started searching the web for solutions. I came across several potential options, which I’ll walk through below:

1. Using the GLOB_STAR_SHORT option in zsh
2. Wrapping the command in quotes

The GLOB_STAR_SHORT option

The first place I looked was in the zsh option for the interpreting the Glob Star pattern. As Stéphane Chazelas outlines in her answer on the Unix & Linux StackExchange, different shells interpret the * wildcard differently.

Per the zsh documentation on options:

GLOB_STAR_SHORT

When this option is set and the default zsh-style globbing is in effect, the pattern '**/*' can be abbreviated to '**' and the pattern '***/*' can be abbreviated to ***. Hence '**.c'finds a file ending in .c in any subdirectory, and'**\*.c'does the same while also following symbolic links. A/immediately after the'**'or'\*\*\*' forces the pattern to be treated as the unabbreviated form.

With this option set, in theory, we can now simplify to:

% eslint **.js

The issue is that when I did this I still got errors:

zsh: argument list too long: eslint

Using ‘Quotes’

Fortunately, all’s not lost. While I wasn’t able to get the glob star short to work with zsh, I was able to find a relatively simple solution: use quotes.¹

% eslint '**/*.js'

At least as far as the goal of searching any subdirectory to match a file pattern, this approach seems to be less prone to error.

Conclusion

This was one of the first times in my experience where the difference between how shells interpret a command materially affected the outcome. Certainly the first time I spent this much time digging into the why! Though it was not how I expected to spend my afternoon, I always love learning this kind of stuff. Hopefully it helps me avoid some pain in the future!

Footnotes

• ¹ Credit to Andrew Naeve for pointing this out.