Bash Compatibility and Migration

## The error comes from the shell, not from the program Before `pip` exists as a process, zsh parses the command line and performs filename generation (globbing) on every word that contains a pattern character. `requests[security]` contains `[` and `]`, so zsh treats it as a bracket expression: the literal text `requests`, followed by exactly one character drawn from the set `s e c u r i t y`. It looks for files in the current directory named `requestss`, `requeste`, `requestc`, and so on. In a normal project directory nothing matches. The `zsh: ` prefix on the message is the giveaway. The shell never built an argument list, never forked, and never executed pip. Any theory that blames pip, the package name, or the network is disproved by that prefix alone. ## NOMATCH is the only real difference from bash Both shells glob. What differs is what happens when a pattern matches nothing, and there are only three possible behaviours: - **Pass the word through literally.** This is POSIX, and it is bash's default. `pip` receives the eight-character string `requests[security]` and does the right thing with it. - **Remove the word.** zsh calls this `NULL_GLOB`; bash calls it `shopt -s nullglob`. - **Fail the command.** zsh calls this `NOMATCH` and has it **on by default**; bash calls it `shopt -s failglob` and has it off. So zsh is not doing anything exotic — it simply defaults to the third option. Related knobs: `unsetopt NOMATCH` restores bash-style passthrough, and `CSH_NULL_GLOB` errors only when *no* pattern on the line matched anything. ## The fixes, best first ```zsh pip install 'requests[security]' # quote — always correct pip install requests\[security\] # escape — same effect noglob pip install requests[security] # zsh precommand modifier: skip globbing for this command alias pip='noglob pip' # if you hit it constantly unsetopt NOMATCH # global bash-like behaviour; last resort ``` Quoting is right because the argument was never meant to be a filename pattern in the first place; you are telling the shell the truth about your intent. `noglob` is a genuine zsh feature — a precommand modifier that disables filename generation for that one command — and it is convenient for tools whose arguments routinely look like globs. ## Where else this bites a bash refugee - **Remote paths.** `scp server:/var/log/*.gz .` — the pattern is meant for the *remote* shell, but your local zsh expands it first and aborts. Quote it: `scp 'server:/var/log/*.gz' .` - **URLs with query strings.** `?` is a pattern character, so `curl http://api.example.com/v1?limit=10` can fail. Quote the URL. - **Refspecs and branch patterns.** `git branch -d 'feature/*'`, `git log --grep='fix[0-9]'`. - **Extended globbing.** If a configuration enables `EXTENDED_GLOB`, `^` and `#` become pattern characters too, and `git show HEAD^` starts failing. That option is off in a bare zsh but many shipped configurations turn it on. In every case the rule is the same: if an argument is a pattern *for something other than your local filesystem*, quote it. ## Why the default is defensible The silent-passthrough behaviour bash inherits from POSIX has a nasty failure mode. Consider: ```zsh for f in *.log; do gzip "$f"; done ``` In a directory with no `.log` files, bash runs the loop body exactly once with `f` set to the literal string `*.log`, and `gzip` fails with a confusing "no such file" for a file whose name contains an asterisk. Scripts that then feed `$f` into `rm`, `mv`, or a `find -name` argument produce genuinely surprising results. zsh stops the command instead, which is noisy but never silently wrong. The same protection catches ordinary typos: `ls *.tct` tells you nothing matched rather than printing an error from `ls` about a file literally named `*.tct`. That is the trade the interviewer usually wants you to articulate: zsh chose loud failure over silent literal text, and once you know that, the fix is always "quote what was never a filename".