In a bash script someone defines `ls() { ls -l "$@"; }` so listings are always long-format, and every call to ls then recurses until the shell dies. Why does that happen, and how do you call the real ls from inside the wrapper?

## How bash resolves a command name Given a simple command like `ls -l /tmp`, bash decides what `ls` means in a strict order: 1. **Reserved words** are recognised while parsing (`if`, `while`, `[[`, `function`…). 2. **Aliases** are expanded, also at parse time, and only when alias expansion is enabled (interactive shells, or `shopt -s expand_aliases`). 3. **Shell functions** are looked up next. 4. **Builtins** (`cd`, `echo`, `read`, `printf`, `command`…) come after that. 5. **PATH search** for an executable file is last, with results cached in the shell's hash table. Everything about wrapper functions follows from step 3 sitting above steps 4 and 5. A function called `ls`, `grep`, `cd` or `curl` takes over that name for the whole shell — in the script, in every function it calls, and in anything it sources. ## Why the wrapper recurses ```bash ls() { ls -l "$@"; } # broken ``` The body is not resolved when the function is defined; it is resolved each time the function runs. So calling `ls /tmp` enters the function, which runs `ls -l /tmp`, which resolves `ls` to the same function, which runs `ls -l /tmp` again. Bash does not detect this. Each level is a new function frame, so the shell keeps allocating until it is killed or the machine starts swapping — there is no tidy "maximum recursion depth" error unless you have set a nesting limit yourself. A useful mental check: any wrapper whose body mentions its own name is either intentional recursion or this bug. ## `command` and `builtin` The `command` builtin exists precisely for this. `command NAME ARGS…` runs `NAME` while ignoring shell functions, falling through to the builtin or the PATH executable: ```bash ls() { command ls -l "$@"; } # correct curl() { command curl --retry 3 "$@"; } ``` If the thing you are wrapping is a builtin, `command` still finds the builtin, which is usually what you want: ```bash cd() { builtin cd "$@" && ls; } # explicit is better here ``` `builtin NAME` forces the builtin specifically, skipping both functions and the PATH. And if you genuinely need the external binary rather than the builtin of the same name — `/bin/echo` instead of the `echo` builtin, say — call it by absolute path or through `env`. Note what `command` does **not** do: it is not a general "run this literally" escape. A leading backslash, `\ls`, suppresses *alias* expansion only; functions are still found. Candidates who reach for `\ls` to defeat a function have confused the two mechanisms. ## Inspecting and removing - `type -a ls` lists every meaning the name currently has, in resolution order — alias, function, builtin, and each PATH hit. - `type -t ls` prints just the kind: `alias`, `keyword`, `function`, `builtin` or `file`. - `declare -F` lists the names of all defined functions; `declare -f ls` prints the body. - `unset -f ls` removes the function, restoring the external command. In a debugging session, `type -a` is the first thing to run when a command in a script behaves nothing like it does at your prompt. ## When shadowing is deliberate Overriding is a real technique, not only a bug: - **Test stubs.** Shell test suites define `curl() { echo "$STUBBED_BODY"; }` to run a script without network access. - **Policy wrappers.** A deployment library defines `kubectl() { command kubectl --context "$CTX" "$@"; }` so every call is pinned to one cluster. - **Safety rails.** `rm() { command rm -I "$@"; }` inside a script that must not delete silently. The discipline is: keep the override local to the script that wants it, always call through `command` inside the body, and never let a general-purpose sourced library redefine a common name. A library that quietly redefines `test`, `echo` or `cd` will break code in files it has never heard of, and the failure surfaces far away from the definition. ## The related failure mode Because a later definition silently replaces an earlier one — no warning, no error — two sourced libraries that both define `log` will leave whichever was sourced last in charge. Prefixing library functions with a short namespace (`mylib::log`, or `mylib_log` for portability) is the usual defence, and `declare -F` makes the collision visible when you go looking for it.