In a bash script with s=deployment, what do ${s:4:3}, ${s:-3} and ${s: -3} each produce, and why are the last two different?

## Substring expansion ```bash s=deployment # d e p l o y m e n t # 0 1 2 3 4 5 6 7 8 9 echo "${s:4:3}" # oym echo "${s:4}" # oyment echo "${s:0:6}" # deploy ``` The form is `${parameter:offset:length}`. Offsets are **zero-based** — the most common off-by-one in shell code, because `cut -c` is one-based and people move between them. Omitting `:length` extracts everything from the offset to the end of the value. A length longer than what remains is not an error; you simply get what is there. ## The colon-minus collision This is the real content of the question. Bash decides which operator you meant by looking at the character immediately after the colon: ```bash s=deployment echo "${s:-3}" # deployment — the ${var:-word} default operator, word is "3" echo "${s: -3}" # ent — substring, offset -3 echo "${s:(-3)}" # ent — same thing, parenthesised ``` `${s:-3}` is unambiguously the default-value operator with the word `3`: since `s` is set and non-empty, it expands to `deployment` and the `3` is never used. If `s` had been unset you would get `3` — which looks like a plausible substring result and is why this bug survives review. The fix is to break the `:-` token apart with a space or wrap the offset in parentheses; both are standard idioms, and a computed offset such as `${s:$((n-3))}` sidesteps the problem naturally. ## Negative offsets and negative lengths A negative offset counts from the end of the value: `-1` is the last character, `-3` starts three from the end. Since bash 4.2 the *length* may also be negative, in which case it is an offset from the end rather than a count: ```bash s=deployment echo "${s: -3}" # ent echo "${s:1:-1}" # eploymen — from offset 1 to one before the end ``` Before bash 4.2 a negative length is an error (`substring expression < 0`), so if a script must run on an old bash — macOS still ships bash 3.2 as `/bin/bash` — compute the length arithmetically instead. Naming the bash version an answer depends on is a habit worth having here. ## Length, and how these compose `${#s}` gives the length of the value in characters — 10 for `deployment`. It pairs naturally with substrings for hand-rolled trimming and for validation: ```bash [[ ${#token} -ge 32 ]] || die "token looks truncated" middle=${s:1:${#s}-2} ``` Note that `${#s}` counts characters, not bytes, when the locale is a multibyte one such as UTF-8, and substring offsets are likewise character-based. That means `${s:0:1}` on a value starting with a multibyte character gives you the whole character, not half of it — good behaviour, but it does mean lengths differ from byte counts, which matters if you are sizing a field for a protocol. ## When to use it Substring expansion is the right tool when you know the position: fixed-width identifiers, a short hash prefix (`${sha:0:7}`), splitting a value at a known column. When the boundary is defined by a *delimiter* rather than a position, the trimming operators `#`, `##`, `%` and `%%` express the intent far better and do not break when the field width changes. Reaching for `${s:0:5}` to strip a prefix such as `refs/` works until someone renames the prefix; `${s#refs/}` states what you actually meant. All of these are non-destructive: the variable keeps its original value, and you assign the result if you want to keep it. And substring expansion is a bashism — POSIX `sh` has no `${var:offset:length}` — so a script with a `#!/bin/sh` shebang cannot rely on it.