How to Solve Syntax Error Near Unexpected Token Newline in Linux Bash

To fix syntax error near unexpected token newline, inspect the reported line and the command immediately before it for an unfinished construct. Unquoted < or > used as literal text are common causes; quote the text, or complete the redirection if that was intended.

Identify the Bash syntax error near unexpected token newline

When Bash reports syntax error near unexpected token newline, it has reached a line ending while parsing a command whose syntax is incomplete or whose next token cannot fit the construct it has read. The newline is where Bash noticed the problem; the missing piece may be on the preceding line. The message alone does not identify one cause, so inspect the command in context instead of changing line breaks at random.

Common clues include an unquoted < or > that Bash reads as a redirection operator, an unfinished redirection with no target, an unclosed quote or grouping construct, and a command split without a valid continuation. Similar mistakes can produce other diagnostics, including an unexpected end-of-file message. Use the wording as a clue, then confirm the actual syntax around the reported location.

Inspect the command around the reported line

Open the script and read the reported line together with the command immediately before it. In a multi-line command, the parser may only discover a missing argument or closing token when it reaches the next newline. Check for a redirection operator at the end of a command, a quote that never closes, a missing ) or }, and a backslash followed by whitespace rather than the newline it should continue.

If the command is in a script, inspect the source directly with an editor or a command such as sed -n '12,20p' script.sh, adjusting the line range to include nearby context. Reading the source helps locate the syntax, while cat by itself does not diagnose it. For commands pasted into a terminal, review the full pasted command; the error can be caused by an earlier line even when Bash names the final line.

Fix unquoted angle brackets used as text

In Bash, unquoted < redirects standard input and > redirects standard output. For example, name=<guest> is parsed as shell syntax, not as an assignment containing the literal text <guest>. A redirection also needs a target, so an unfinished form such as printf '%s\n' < leaves Bash without a filename. If the angle brackets are meant to appear as characters, quote them or escape them; if you intended redirection, provide the appropriate file or descriptor.

Run this example:

script=$(mktemp)
trap 'rm -f "$script"' EXIT
cat >"$script" <<'BASH'
greet() {
  printf 'Hello, %s! Use <name> as a placeholder.\n' "$1"
}
greet "Sam"
BASH
bash -n "$script" && bash "$script"

The heredoc keeps the script text literal while it is written to a temporary file. Inside the script, the printf format is quoted, so <name> is ordinary text and does not act as a redirection. The example also defines and closes a function before calling it. The syntax check runs before the script, and the trap removes the temporary file when the shell exits.

An unfinished redirection is a useful boundary case: < is present, but no input filename follows it. This self-contained diagnostic example writes that incomplete command to a temporary script, runs bash -n, suppresses the diagnostic text, and prints the syntax check’s exit status. The packet has no observed runtime output for it, so the example is unexecuted here; the status is captured so the deliberately invalid script does not make the example itself fail.

script=$(mktemp)
trap 'rm -f "$script"' EXIT
printf '%s\n' 'printf "%s\n" <' >"$script"
bash -n "$script" 2>/dev/null
status=$?
printf 'incomplete redirection syntax-check exit status: %s\n' "$status"

Check quotes, grouping, and line continuations

Make sure each single or double quote has a matching closing quote. For example, printf '%s\n' "Hello leaves the double-quoted argument unfinished; write printf '%s\n' "Hello" to close it. An unfinished quote often produces a diagnostic about an unexpected end-of-file or a matching quote, rather than this exact newline message, but it is still worth checking when the command spans lines.

Grouping constructs need their corresponding closer: a subshell opened with ( needs ), and a function body opened with { needs }. For example, greet() { printf '%s\n' 'Hello'; } has a complete function body. A missing closer may be reported at a later line or at the end of the file, depending on the construct and context; do not assume every grouping mistake produces the target wording.

For a command intentionally split across lines, put a backslash immediately before the newline, with no trailing spaces after the backslash. Bash then joins the continued line to the command. A newline inside a properly closed quoted string is different: it is part of the string and is not automatically a syntax error. Prefer clear quoting and continuation over deleting line breaks without checking the intended argument boundaries.

Trace scripts with Bash debugging

For a script that parses but behaves unexpectedly, bash -x script.sh prints each command as Bash executes it. You can also place set -x before the part you want to trace and set +x after it. The trace helps show expanded arguments and the order of executed commands; check the last trace line before a runtime failure to narrow down where behavior diverged.

Tracing does not repair syntax and cannot show commands that Bash cannot parse. Use bash -n script.sh first when checking syntax: it parses the script without executing its commands. If the syntax check reports an error, return to the relevant lines and fix the unfinished construct before using execution tracing.

Verify the corrected command

After editing, review the exact changed line and the construct around it. For a script, run bash -n script.sh; a clean syntax check means Bash parsed the file, but does not establish that it will produce the intended result. Then run the script with its normal inputs and compare its behavior with what you expect. If behavior is still wrong, use bash -x script.sh to follow the executed commands.

For a command entered directly in a terminal, run the corrected command with safe, representative input. Confirm that literal angle brackets are quoted, intended redirections have a destination, quotes and grouping are closed, and any continued line ends with a backslash in the right position. These checks separate a parsing fix from a later runtime or logic problem.