What does the pattern `**` expand to in bash, what has to be enabled for it to be recursive, and how does `for f in **/*.js` differ from `find . -name '*.js'`?

## The default is not recursion In a pattern, ordinary adjacent asterisks collapse: `**` matches the same set as `*`, because `*` already matches any run of characters within one path component and repeating it adds nothing. So the very common assumption that `**/*.js` is "all JavaScript files anywhere" is wrong in a default bash: ```bash shopt -u globstar echo **/*.js # identical to */*.js -- exactly one directory deep ``` This is a quiet failure. In a shallow project the pattern appears to work; on a deeper tree it silently misses most of the files, and a linting or formatting step covers a fraction of the codebase without anyone noticing. ## Turning on globstar ```bash shopt -s globstar for f in **/*.js; do echo "$f"; done ``` With `globstar` set, `**` used as a path component matches all files and zero or more directories and subdirectories. When it is followed by a `/`, it matches only directories and subdirectories. The "zero or more" part is important and often missed: `**/*.js` includes `app.js` in the current directory, not only files nested at least one level down. And `**/` on its own expands to every directory in the tree, which is handy for `chmod` sweeps. globstar arrived in **bash 4.0**. It does not exist in bash 3.2, the version Apple still ships as `/bin/bash` on macOS, so a script relying on it needs either a newer bash on the PATH or a different approach. ## Four differences from find **Hidden entries.** globstar is still pathname expansion and still refuses to match a leading dot, so `**/*.js` never descends into `.git`, `.cache` or `.github`. Depending on your goal this is a feature — you rarely want to lint vendored files inside a dot-directory — or a bug you must fix with `shopt -s dotglob`. `find` has no such rule and walks everything unless you prune explicitly. **Symbolic links.** Since **bash 4.3**, globstar no longer traverses symbolic links to directories. Earlier versions did, and a symlink pointing at a parent directory could send the expansion into an effectively unbounded walk. `find` does not follow symlinks by default either, but `find -L` does, so the two tools can be made to differ in both directions — be explicit about which behaviour you want. **Everything up front.** Bash builds the complete list of matches, sorts it, and substitutes it into the command line before the command runs. On a very large tree that means noticeable memory and latency, and if the expansion is passed to an external command it can exceed the system's argument-list limit and fail with "argument list too long". `find` streams, and `find ... -exec cmd {} +` batches arguments to stay under the limit. A `for` loop over a glob does not hit that limit — the loop is internal to bash — but `rm -- **/*.tmp` can. **Selection power.** find can filter on type, size, mtime, permissions and depth, prune subtrees, and emit NUL-separated names for safe consumption. A glob can only match names. When the selection criteria go beyond the name, that is the signal to switch tools. ## Choosing between them Globs win on safety and readability for name-based selection: each expanded word is a real pathname handed to the command as one argument, so filenames containing spaces or newlines are handled correctly with no extra ceremony, which is exactly where naive `find | while read` pipelines go wrong. ```bash shopt -s globstar nullglob for f in **/*.js; do # safe with any filename, zero iterations if none prettier --write "$f" done ``` Note `nullglob` alongside globstar: without it, an empty match still leaves the literal `**/*.js` in the loop. Pairing the two is the idiomatic combination for a script that walks a tree. find wins when you need non-name criteria, when the tree is large enough that materialising every path is wasteful, or when the script must run under `/bin/sh` where globstar does not exist at all. ## Repository-aware alternatives In a source tree, neither tool knows about ignore files. If the intent is "every tracked JavaScript file", `git ls-files '*.js'` is usually more correct than either, because it automatically excludes build output and vendored directories that the glob would happily include.