Bash: Syntax Error Near Unexpected Token (tested)

bash: syntax error near unexpected token (exit code 2) means the parser got confused about the script's structure — usually a block that never closed, or a line ending the parser didn't expect. We reproduced both of the two most common real causes: a missing fi/done/esac, and Windows-style CRLF line endings.

1. Reproduced: a missing fi, done, or esac at the very end of a script

$ cat missingfi.sh
#!/bin/bash
if [ "$1" = "x" ]; then
  echo "yes"
$ bash missingfi.sh
missingfi.sh: line 4: syntax error: unexpected end of file

We got the identical "unexpected end of file" message for a missing done closing a for loop and a missing esac closing a case — when the missing keyword is the very last thing in the file, bash just keeps reading, waiting for the block to close, until it runs out of file. Exit code was 2 in every case.

2. Reproduced: the same mistake, but now it really does say "unexpected token"

The slug of this guide is the literal message, so here's exactly when you get it instead of "unexpected end of file": when there's more file left to parse after the point where bash gives up. We left esac out of a case block and added one more line after it:

$ cat missingesac2.sh
#!/bin/bash
case "$1" in
  x) echo "x" ;;
echo "after case"
$ bash missingesac2.sh
missingesac2.sh: line 4: syntax error near unexpected token `"after case"'
missingesac2.sh: line 4: `echo "after case"'

case/esac has stricter grammar than if/for: after a pattern's ;;, bash expects either another pattern or esac, not an arbitrary command — so it names the bad token immediately instead of reading to EOF.

The same thing happens with an unclosed if or for inside a function, because the function's own closing } is what bash trips over:

$ cat missingfi3.sh
myfunc() {
  if [ "$1" = "x" ]; then
    echo "yes"
}
$ bash missingfi3.sh
missingfi3.sh: line 5: syntax error near unexpected token `}'
missingfi3.sh: line 5: `}'

And a stray extra fi (one too many) names itself directly:

$ printf 'if [ "$1" = x ]; then\n echo yes\nfi\nfi\n' | bash
bash: line 4: syntax error near unexpected token `fi'

3. Reproduced: Windows CRLF line endings, variant 1 — a stray $'\r' command

A script edited on Windows (or downloaded/copied without conversion) has \r\n line endings instead of bash's expected \n. file and cat -A show it instantly — ^M is the carriage return:

$ file crlfblank.sh
crlfblank.sh: ASCII text, with CRLF line terminators
$ cat -A crlfblank.sh
echo one^M$
^M$
echo two^M$

Running it is revealing: a blank-looking line (just the stray \r) gets executed as its own "command":

$ bash crlfblank.sh
one
crlfblank.sh: line 2: $'\r': command not found
two

The script didn't stop — that line just failed on its own and bash moved on. This is the single most common tell of a CRLF file: an error mentioning literal $'\r'.

4. Reproduced: CRLF, variant 2 — a real "unexpected token"

The more disruptive case: a \r glued directly onto a keyword like then, in, or { makes that keyword unrecognizable to the parser — then\r is a different token than then. We built a file with CRLF endings around a case block:

$ cat -A t3.sh
case "$1" in^M$
  x) echo x ;;^M$
esac^M$
echo done^M$
$ bash t3.sh
t3.sh: line 1: syntax error near unexpected token `$'in\r''
t3.sh: line 1: `case "$1" in'

Same result on a function definition, where {\r isn't recognized as opening the function body:

$ bash t4.sh
t4.sh: line 1: syntax error near unexpected token `$'{\r''

The $'...\r' quoting in the error message is the giveaway — bash is showing you that the token it choked on has an invisible carriage return stuck to the end of it. If you see $'...\r' anywhere in a syntax error, the file has CRLF endings; stop looking for a missing fi and fix the line endings instead.

5. Fixing CRLF, confirmed

Either of these strips the \r and leaves the script byte-identical otherwise. We confirmed both on the broken files above and reran them successfully afterward:

$ sed -i 's/\r$//' script.sh
$ tr -d '\r' < script.sh > fixed.sh

dos2unix script.sh does the same if it's installed (we didn't have it on this box, so we didn't measure it — but it's a standard, widely documented tool for exactly this). After stripping, re-check with file script.sh; it should say "ASCII text" with no mention of CRLF.

6. Reproduced: an unclosed quote, several lines before the error

A different, sneakier cause of the same family of errors: a quote that never closes. We opened a double quote on line 3 and never closed it:

$ cat -n quotesneaky.sh
     1  #!/bin/bash
     2  # config
     3  name="deploy-bot
     4  log() {
     5    echo "[$name] $1"
     6  }
     7  log "starting deploy"
     8  log "step 1 done"
     9  log "step 2 done"
    10  log "finished"
$ bash quotesneaky.sh
quotesneaky.sh: line 10: unexpected EOF while looking for matching `"'

The unclosed quote is on line 3. Bash reports line 10 — the real last line of the file, 7 lines away — because once bash sees the opening ", everything after it (including what look like other commands, other quotes, even the function's closing }) is swallowed as plain text inside that one unterminated string, all the way to true end of file. The message is also worded differently from the missing-fi case above: unexpected EOF while looking for matching `"' instead of syntax error: unexpected end of file — both mean bash ran out of file before a construct closed, just phrased differently depending on whether it was waiting for a keyword or a quote character.

To find the real line instead of guessing from the EOF line, count quotes (an odd total confirms one is unmatched) and then bisect:

$ grep -o '"' quotesneaky.sh | wc -l
11
$ head -n 3 quotesneaky.sh > bisect3.sh && bash -n bisect3.sh
bisect3.sh: line 3: unexpected EOF while looking for matching `"'
$ head -n 2 quotesneaky.sh > bisect2.sh && bash -n bisect2.sh
$ echo $?
0

Line 2 parses clean, line 3 doesn't — confirming the unclosed quote's exact location directly instead of guessing. This same truncate-and-check trick works for a missing fi/done/esac too: shrink the file with head -n N right after the suspect block and see if bash -n still complains.

7. A heredoc missing its closing delimiter is only a warning, not a hard error

This one behaves differently from every case above. We wrote a heredoc with no closing EOF:

$ cat heredocbad.sh
#!/bin/bash
echo "start"
cat <