You ship a zsh plugin whose functions misbehave for users who have set options such as SH_WORD_SPLIT or KSH_ARRAYS in their own configuration. What does adding `emulate -L zsh` at the top of each function do, and how is it different from `emulate sh`?

## The problem being solved zsh has well over a hundred options, and users set them freely. A function you ship runs in *their* shell with *their* options. Any of these will change what your code does without touching a line of it: - `SH_WORD_SPLIT` — your unquoted expansions suddenly split on whitespace. - `KSH_ARRAYS` — your subscripts are off by one and bare array names collapse to element zero. - `EXTENDED_GLOB` — `^`, `#`, and `~` become pattern characters inside your patterns. - `NULL_GLOB` / `NOMATCH` changes — your globs silently vanish or hard-fail. - `NO_UNSET` — reading an unset variable becomes an error. This is the shell equivalent of a library that behaves differently depending on the caller's global settings. The fix is to declare the dialect you were written in. ## What `emulate` actually does ```zsh emulate [-lLR] [zsh|sh|ksh|csh] ``` It sets the shell options to those appropriate for the named shell. `emulate zsh` restores zsh's own defaults; `emulate sh` and `emulate ksh` switch to those shells' compatible behaviour, which among other things turns `SH_WORD_SPLIT` on. `-l` lists the resulting settings instead of applying them, which is a useful way to see exactly what an emulation changes. `-R` means *reset*: set all options to their defaults for that emulation, not only the ones that affect compatibility. Without `-R`, options that are purely a matter of taste — interactive conveniences, for instance — are left as the user had them. With `-R` you get a clean slate, which is more predictable and also more likely to surprise you by turning off something you were relying on. ## What `-L` adds, and why it is the whole point `-L` implies `LOCAL_OPTIONS` and `LOCAL_TRAPS`. Inside a function, those mean every option change and trap installed during the function is undone when the function returns. Without `-L`, `emulate zsh` in a function permanently rewrites the user's option set — you would fix your own function by breaking their shell. ```zsh my_plugin_widget() { emulate -L zsh setopt extended_glob # scoped: reverted on return local -a matches matches=(*.log) # behaves the way you wrote it, whatever the user set print -r -- ${#matches} } ``` That prologue is the convention in well-written zsh plugins and in zsh's own shipped functions. Many authors write `emulate -L zsh -o no_unset` or similar to add the specific options they *do* want on top of the reset baseline. ## `emulate sh` is a different tool for a different job `emulate -L zsh` says "my code is zsh". `emulate -L sh` says "the block that follows is Bourne-style code, please apply Bourne rules". Use it when you are sourcing or inlining something written for `/bin/sh` and you would rather not port it: word splitting comes back, and other sh-compatible behaviours are enabled for the duration. zsh also applies emulation automatically based on the name it was invoked under. If the basename of `argv[0]` is `sh` or `ksh`, zsh emulates that shell from startup, including following sh's startup-file conventions rather than reading the zsh ones. That is how a system that makes `/bin/sh` a link to zsh keeps Bourne scripts working. There is one more form worth knowing, *sticky emulation*: running an `autoload` inside `emulate <shell> -c '...'` attaches that emulation to the loaded function, so it runs under those rules every time it is called, without needing a prologue of its own. ```zsh emulate sh -c 'autoload -Uz legacy_helper' # legacy_helper always runs sh-style ``` ## Limits worth stating out loud Emulation covers *options*. It does not sandbox everything: variables such as `IFS`, aliases defined by the user, functions that shadow builtins, and `PATH` are not reset. Robust plugin code still declares `local` variables, uses `command`/`builtin` prefixes where an alias or override would be catastrophic, and avoids depending on ambient state. `emulate -L zsh` is the cheap 90% of the defence, not the whole of it. And it is not a compatibility layer for *bash*: there is no `emulate bash`. `emulate sh` gets you Bourne semantics, but bashisms such as `${var^^}`, `local -n`, or `BASH_SOURCE` are simply absent, so genuinely bash-specific code must be ported rather than emulated.