A colleague's bash trace from `set -x` is a wall of lines that all start with `+ ` and you cannot tell which file or line any of them came from. How do you make bash's trace show the source file, line number and function — and why must that PS4 assignment be single-quoted?

## PS4 is a template, not a string When xtrace is on, bash prints the expanded value of `PS4` before each traced command. "Expanded" is the operative word: `PS4` is subjected to parameter expansion, command substitution and arithmetic expansion **every time a trace line is emitted**, exactly like the interactive prompt variables. That makes it a template into which you can inject the shell's own location variables. The default value is `+ `, which carries no information beyond "this is a trace line". ## A prefix worth having ```bash PS4='+ ${BASH_SOURCE[0]##*/}:${LINENO}:${FUNCNAME[0]:-main}: ' set -x ``` Each piece: - **`BASH_SOURCE[0]`** — an array whose element 0 is the name of the source file currently being executed. It is the reliable way to identify the file, because a script that `source`s a shell library will otherwise produce trace lines that look like they came from the main script. `${...##*/}` strips the directory so the prefix stays short. - **`LINENO`** — the line number in the current source file of the command about to run. Because `PS4` is re-expanded per line, it tracks. - **`FUNCNAME[0]`** — the function currently executing. Outside any function `FUNCNAME` is empty, so `${FUNCNAME[0]:-main}` substitutes a readable placeholder rather than printing nothing. The result turns an anonymous firehose into something greppable: ``` + deploy.sh:41:main: build_image v1.4.2 + deploy.sh:18:build_image: docker build -t app:v1.4.2 . ``` People also add a timestamp with a command substitution such as `$(date +%T)`, or the process id via `$$` when several processes trace into one stream. Anything with a command substitution costs a fork per traced line, so on a hot loop it can dominate the runtime. ## Why the quoting decides whether it works This is the classic failure: ```bash PS4="+ ${BASH_SOURCE[0]}:${LINENO}: " # WRONG ``` Double quotes do not suppress parameter expansion. The expansions run **once**, at the moment of assignment, so `PS4` becomes the fixed string `+ deploy.sh:3: ` and every single trace line for the rest of the run claims to come from line 3. The script looks traced; the location data is a lie, which is worse than no location data. ```bash PS4='+ ${BASH_SOURCE[0]}:${LINENO}: ' # RIGHT ``` Single quotes preserve the `$` sequences verbatim; bash expands them when it prints each trace line. The rule generalises: any variable whose value is meant to be re-expanded later — `PS1`, `PS4`, a format template — is assigned in single quotes. ## The nesting cue Bash replicates the **first character** of `PS4` to indicate levels of indirection: a command running one level deeper, such as inside a command substitution or a subshell, is prefixed with a doubled character. If your custom `PS4` begins with a `+`, you keep that signal (`++ deploy.sh:…`). If you begin it with a space or a timestamp, the depth information is still there but far less readable, so conventionally the `+` stays first. ## Where to set it `PS4` is an ordinary shell variable, so: - Set it in the script, right before the tracing you care about. - Or supply it on the invocation — `PS4='+ ${BASH_SOURCE[0]}:${LINENO}: ' bash -x ./script.sh` — to get a rich prefix on a script you cannot edit. It must reach the child's environment, since ordinary shell variables are not inherited. One caution about environment inheritance: a `PS4` containing a command substitution is executed by any bash that turns on xtrace, so treat an exported `PS4` the way you treat any other inherited executable content — keep it simple and local to your own debugging session. ## What it does not fix A richer prefix makes a trace navigable; it does not reduce its volume, and it does not stop the trace from printing expanded secrets, since the command itself is still printed in clear. Those are separate decisions about when tracing is on and where its output goes.