Why does an alias defined near the top of a bash script usually fail to work when it is used further down in the same script, and what should you write instead?

## What an alias actually is An alias is a parser-level text replacement. `alias ll='ls -l'` tells bash that when the *first word* of a simple command is `ll`, it should substitute the text `ls -l` before doing anything else. That is the whole mechanism — no arguments, no scope, no return value. ```bash alias ll='ls -l' ll /tmp # parsed as: ls -l /tmp ``` Because it is a first-word substitution, `echo ll` is unaffected, and an alias only ever prepends text; whatever you type after the alias name is appended to the end of the expansion. ## Reason one: non-interactive shells do not expand aliases Bash disables alias expansion when it is not interactive. A script run as `./deploy.sh`, a `bash -c` command, a cron job and a CI step are all non-interactive, so their aliases are recorded and never used. The behaviour is deliberate and it surprises people who copy working lines out of their `~/.bashrc` into a script: ```bash #!/usr/bin/env bash alias k='kubectl --context prod' k get pods # bash: k: command not found ``` You can turn expansion on with `shopt -s expand_aliases`, and it is the standard trick when a script must reuse aliases from a sourced profile — but it does not solve the second problem. ## Reason two: expansion happens at parse time Bash reads input a whole compound command at a time, expanding aliases as it parses. An alias defined by a line that has not run yet cannot affect text the parser has already consumed: ```bash shopt -s expand_aliases setup() { alias hi='echo hello' hi # still 'command not found' } setup ``` The entire `setup` function body was parsed before any of it ran, so `hi` was not an alias at parse time. The same applies to both halves of `alias hi='echo hello'; hi` on one line. This is the rule that makes aliases genuinely unsuitable for scripts: even when you enable them, whether they work depends on where the parser happened to be. ## Reason three: aliases cannot take parameters Since the alias body is text and the user's arguments are appended after it, there is no way to place an argument anywhere but the end. `alias mkcd='mkdir -p $1 && cd $1'` looks plausible and does not work: the `$1` expands to the *shell's* first positional parameter (usually empty), and the typed argument lands after the `cd`. People then reach for increasingly baroque quoting instead of writing the four-line function that solves it. ## What a function gives you instead ```bash mkcd() { mkdir -p -- "$1" && cd -- "$1" } ``` A function is resolved at *execution* time, so ordering only requires that the definition has run before the call. It receives real positional parameters, so `$1` is the caller's argument and `"$@"` forwards the whole list. It can hold multiple statements, declare local variables, and produce an exit status the caller can test. It also composes: functions can call functions, and a function can be passed to `xargs`-free loops and conditionals like any other command. The practical rule that falls out of all this: - **Interactive prompt:** aliases are fine for short, argument-free abbreviations you type all day. - **Scripts and shell libraries:** always functions. If you are tempted by an alias, you want a function. ## Two details worth knowing `alias` with no arguments lists what is currently defined, and `unalias name` removes one. A function and an alias can share a name — the alias wins, because it is applied first, during parsing. That combination is confusing enough that `type -a name`, which shows both, is the fastest way to untangle it when a script and a user's environment disagree about what a name means.