Check Syntax in a Shell Script: Quick Methods

To check a shell script’s syntax without running its commands, use the shell’s parser: run bash -n script.sh for Bash or sh -n script.sh for a script written for a POSIX-style shell. These commands report many parsing errors and return a nonzero status when they find one, but they do not prove the script will behave correctly at runtime.

Choose the shell the script uses

“Shell script” can mean a script written for Bash, Dash, Zsh, or another command interpreter. Syntax is not identical across shells, so checking a script with the wrong one can give misleading results. Look at its first line, called the shebang, and at the syntax it uses.

• #!/usr/bin/env bash or #!/bin/bash: check with bash -n script.sh.
• #!/bin/sh: use sh -n script.sh, preferably on a system whose sh matches the target environment.
• #!/usr/bin/env zsh: check with zsh -n script.sh.

The shebang tells the operating system what interpreter to use when the file is executed directly. If you run bash script.sh, however, Bash interprets it regardless of the shebang. That distinction matters: a script containing Bash-only features may pass Bash’s check but fail when run under a more limited sh.

Run a syntax-only check

For a Bash script, open a terminal in the directory containing the file and run:

bash -n script.sh

Replace script.sh with the actual filename or give its path, such as bash -n ./scripts/backup.sh. The -n option tells Bash to read commands and check syntax without executing them. If there is no diagnostic, the parser accepted the file; silence is the usual success result.

For a portable shell script, use:

sh -n script.sh

A syntax check is useful before committing a change, sharing a script, or running a script that could alter files or systems. It is also safe to use on a script whose commands you do not want to execute: parsing is not the same as running those commands. Still, treat any file opened in an editor or passed to a tool according to your normal security practices.

Check the exit status and locate errors

Shells generally print an error message with a line number and return a nonzero exit status if parsing fails. You can inspect that status immediately after the check:

bash -n script.sh
printf 'status: %s\n' "$?"

A status of zero means the command completed successfully; a nonzero value means the check reported a problem or could not complete. In a script or automated job, you can use the status to stop later steps:

if bash -n script.sh; then
    echo "Syntax looks valid"
else
    echo "Syntax check failed"
fi

Read the first useful diagnostic and inspect the reported line along with the lines just before it. A missing quote, closing parenthesis, or fi may only become apparent when the parser reaches a later line. Line numbers identify where the shell noticed a problem, not always where the mistake began.

What a syntax check can and cannot find

The parser can catch structural mistakes such as an unclosed quote, malformed grouping, or an incomplete conditional. It cannot generally determine whether a variable contains the value you expect, whether a file exists, or whether a command will succeed. Nor does -n run the script’s commands to test their effects.

For example, this can be syntactically valid even if the named program is absent:

missing_tool --input data.txt

Likewise, a command can use a valid but unintended filename, or a condition can be logically wrong. Those are behavior or logic problems, not necessarily syntax errors. To find them, review the code, test with safe sample inputs, and check command results. Avoid using a real production environment as a substitute for a controlled test.

Also note that shells may defer some interpretation until a particular branch runs or a command is invoked. A syntax-only check is an important first filter, not a complete test suite or a guarantee that every possible execution path will work.

Common problems and useful tools

If a check reports errors that do not make sense, first confirm the interpreter. A Bash script checked as sh may be rejected because features such as arrays or Bash-specific conditional syntax are not portable. Conversely, checking a portable script only with Bash does not establish that it works under the target system’s sh.

• “Command not found” for the checker: the shell may not be installed or may not be on your PATH. Check with a system administrator or install the appropriate interpreter through your platform’s normal package process.
• Wrong file or path: verify the filename and current directory. A missing-file message is not a syntax diagnosis.
• Unexpected end of file: look for an opening quote, then, brace, parenthesis, or other construct that lacks its matching close.
• Different results on another machine: interpreter versions and the actual shell used for sh can differ. Check in the environment where the script is intended to run.
• Unusual line endings: files edited on different operating systems can contain line-ending differences. If diagnostics point to strange characters, inspect the file’s format and convert it with a suitable text tool.

For deeper static analysis, ShellCheck is a widely used tool that flags many likely mistakes and portability concerns. It complements, rather than replaces, the shell’s own syntax check: some findings are warnings about suspicious behavior, and a clean report still cannot prove that a script meets its requirements.

Syntax checking in a workflow

Run the parser check after editing and before executing a changed script. In a project with several scripts, a loop can check each Bash file and stop when one fails:

for file in scripts/*.sh; do
    bash -n "$file" || exit 1
done

Use a loop suited to the actual interpreter and file set; the example assumes the files are Bash scripts. In continuous integration, the same check can act as an early validation step. It is fast and does not execute the checked commands, but should sit alongside relevant tests and review rather than replace them.

Frequently Asked Questions

Does bash -n execute the script?
No. It asks Bash to parse the script without executing its commands. It therefore checks syntax, not the commands’ real-world effects.

How do I check syntax in a shell script on Linux or macOS?
Use the interpreter that will run the file, such as bash -n script.sh for Bash or sh -n script.sh for a POSIX-style script. The command is available wherever that shell is installed.

What does “unexpected end of file” mean?
The shell reached the end while expecting a closing part of a construct. Check earlier lines for unmatched quotes, parentheses, braces, or control structures such as if without a matching fi.

Can I use sh -n to check a Bash script?
Not reliably. Bash-only syntax may be rejected by sh, and passing with Bash does not show that a script is portable. Check with the intended interpreter.

Does a successful syntax check mean the script is safe or correct?
No. It means the parser accepted the syntax. It does not validate the script’s logic, commands, permissions, inputs, or effects, so review and appropriate testing are still needed.

Related

• Llama 3 vs GPT-4: Which Model Is Better?
• Enable Light Theme on Mac: Steps and Fixes
• Open Source Forks: Can Great Projects Really Die?