Проверка скрипта на ошибки bash

ShellCheck — A shell script static analysis tool

ShellCheck is a GPLv3 tool that gives warnings and suggestions for bash/sh shell scripts:

The goals of ShellCheck are

• To point out and clarify typical beginner’s syntax issues that cause a shell
  to give cryptic error messages.

• To point out and clarify typical intermediate level semantic problems that
  cause a shell to behave strangely and counter-intuitively.

• To point out subtle caveats, corner cases and pitfalls that may cause an
  advanced user’s otherwise working script to fail under future circumstances.

See the gallery of bad code for examples of what ShellCheck can help you identify!

Table of Contents

• How to use
  • On the web
  • From your terminal
  • In your editor
  • In your build or test suites
• Installing
• Compiling from source
  • Installing Cabal
  • Compiling ShellCheck
  • Running tests
• Gallery of bad code
  • Quoting
  • Conditionals
  • Frequently misused commands
  • Common beginner’s mistakes
  • Style
  • Data and typing errors
  • Robustness
  • Portability
  • Miscellaneous
• Testimonials
• Ignoring issues
• Reporting bugs
• Contributing
• Copyright
• Other Resources

How to use

There are a number of ways to use ShellCheck!

On the web

Paste a shell script on https://www.shellcheck.net for instant feedback.

ShellCheck.net is always synchronized to the latest git commit, and is the easiest way to give ShellCheck a go. Tell your friends!

From your terminal

Run shellcheck yourscript in your terminal for instant output, as seen above.

In your editor

You can see ShellCheck suggestions directly in a variety of editors.

• Vim, through ALE, Neomake, or Syntastic:

.

• Emacs, through Flycheck or Flymake:

.

• Sublime, through SublimeLinter.

• Atom, through Linter.

• VSCode, through vscode-shellcheck.

• Most other editors, through GCC error compatibility.

In your build or test suites

While ShellCheck is mostly intended for interactive use, it can easily be added to builds or test suites.
It makes canonical use of exit codes, so you can just add a shellcheck command as part of the process.

For example, in a Makefile:

check-scripts:
    # Fail if any of these files have warnings
    shellcheck myscripts/*.sh

or in a Travis CI .travis.yml file:

script:
  # Fail if any of these files have warnings
  - shellcheck myscripts/*.sh

Services and platforms that have ShellCheck pre-installed and ready to use:

• Travis CI
• Codacy
• Code Climate
• Code Factor
• CircleCI via the ShellCheck Orb
• Github (only Linux)
• Trunk Check (universal linter; allows you to explicitly version your shellcheck install) via the shellcheck plugin

Most other services, including GitLab, let you install
ShellCheck yourself, either through the system’s package manager (see Installing),
or by downloading and unpacking a binary release.

It’s a good idea to manually install a specific ShellCheck version regardless. This avoids
any surprise build breaks when a new version with new warnings is published.

For customized filtering or reporting, ShellCheck can output simple JSON, CheckStyle compatible XML,
GCC compatible warnings as well as human readable text (with or without ANSI colors). See the
Integration wiki page for more documentation.

Installing

The easiest way to install ShellCheck locally is through your package manager.

On systems with Cabal (installs to ~/.cabal/bin):

cabal update
cabal install ShellCheck

On systems with Stack (installs to ~/.local/bin):

stack update
stack install ShellCheck

On Debian based distros:

sudo apt install shellcheck

On Arch Linux based distros:

or get the dependency free shellcheck-bin from the AUR.

On Gentoo based distros:

On EPEL based distros:

sudo yum -y install epel-release
sudo yum install ShellCheck

On Fedora based distros:

On FreeBSD:

pkg install hs-ShellCheck

On macOS (OS X) with Homebrew:

Or with MacPorts:

sudo port install shellcheck

On OpenBSD:

On openSUSE

Or use OneClickInstall — https://software.opensuse.org/package/ShellCheck

On Solus:

On Windows (via chocolatey):

C:> choco install shellcheck

Or Windows (via scoop):

C:> scoop install shellcheck

From conda-forge:

conda install -c conda-forge shellcheck

From Snap Store:

snap install --channel=edge shellcheck

From Docker Hub:

docker run --rm -v "$PWD:/mnt" koalaman/shellcheck:stable myscript
# Or :v0.4.7 for that version, or :latest for daily builds

or use koalaman/shellcheck-alpine if you want a larger Alpine Linux based image to extend. It works exactly like a regular Alpine image, but has shellcheck preinstalled.

Using the nix package manager:

nix-env -iA nixpkgs.shellcheck

Alternatively, you can download pre-compiled binaries for the latest release here:

• Linux, x86_64 (statically linked)
• Linux, armv6hf, i.e. Raspberry Pi (statically linked)
• Linux, aarch64 aka ARM64 (statically linked)
• macOS, x86_64
• Windows, x86

or see the GitHub Releases for other releases
(including the latest meta-release for daily git builds).

There are currently no official binaries for Apple Silicon, but third party builds are available via
ShellCheck for Visual Studio Code.

Distro packages already come with a man page. If you are building from source, it can be installed with:

pandoc -s -f markdown-smart -t man shellcheck.1.md -o shellcheck.1
sudo mv shellcheck.1 /usr/share/man/man1

pre-commit

To run ShellCheck via pre-commit, add the hook to your .pre-commit-config.yaml:

repos:
-   repo: https://github.com/koalaman/shellcheck-precommit
    rev: v0.7.2
    hooks:
    -   id: shellcheck
#       args: ["--severity=warning"]  # Optionally only show errors and warnings

Travis CI

Travis CI has now integrated ShellCheck by default, so you don’t need to manually install it.

If you still want to do so in order to upgrade at your leisure or ensure you’re
using the latest release, follow the steps below to install a binary version.

Installing a pre-compiled binary

The pre-compiled binaries come in tar.xz files. To decompress them, make sure
xz is installed.
On Debian/Ubuntu/Mint, you can apt install xz-utils.
On Redhat/Fedora/CentOS, yum -y install xz.

A simple installer may do something like:

scversion="stable" # or "v0.4.7", or "latest"
wget -qO- "https://github.com/koalaman/shellcheck/releases/download/${scversion?}/shellcheck-${scversion?}.linux.x86_64.tar.xz" | tar -xJv
cp "shellcheck-${scversion}/shellcheck" /usr/bin/
shellcheck --version

Compiling from source

This section describes how to build ShellCheck from a source directory. ShellCheck is written in Haskell and requires 2GB of RAM to compile.

Installing Cabal

ShellCheck is built and packaged using Cabal. Install the package cabal-install from your system’s package manager (with e.g. apt-get, brew, emerge, yum, or zypper).

On macOS (OS X), you can do a fast install of Cabal using brew, which takes a couple of minutes instead of more than 30 minutes if you try to compile it from source.

$ brew install cabal-install

On MacPorts, the package is instead called hs-cabal-install, while native Windows users should install the latest version of the Haskell platform from https://www.haskell.org/platform/

Verify that cabal is installed and update its dependency list with

Compiling ShellCheck

git clone this repository, and cd to the ShellCheck source directory to build/install:

Or if you intend to run the tests:

$ cabal install --enable-tests

This will compile ShellCheck and install it to your ~/.cabal/bin directory.

Add this directory to your PATH (for bash, add this to your ~/.bashrc):

export PATH="$HOME/.cabal/bin:$PATH"

Log out and in again, and verify that your PATH is set up correctly:

$ which shellcheck
~/.cabal/bin/shellcheck

On native Windows, the PATH should already be set up, but the system
may use a legacy codepage. In cmd.exe, powershell.exe and Powershell ISE,
make sure to use a TrueType font, not a Raster font, and set the active
codepage to UTF-8 (65001) with chcp:

In Powershell ISE, you may need to additionally update the output encoding:

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

Running tests

To run the unit test suite:

Gallery of bad code

So what kind of things does ShellCheck look for? Here is an incomplete list of detected issues.

Quoting

ShellCheck can recognize several types of incorrect quoting:

echo $1                           # Unquoted variables
find . -name *.ogg                # Unquoted find/grep patterns
rm "~/my file.txt"                # Quoted tilde expansion
v='--verbose="true"'; cmd $v      # Literal quotes in variables
for f in "*.ogg"                  # Incorrectly quoted 'for' loops
touch $@                          # Unquoted $@
echo 'Don't forget to restart!'   # Singlequote closed by apostrophe
echo 'Don't try this at home'    # Attempting to escape ' in ''
echo 'Path is $PATH'              # Variables in single quotes
trap "echo Took ${SECONDS}s" 0    # Prematurely expanded trap
unset var[i]                      # Array index treated as glob

Conditionals

ShellCheck can recognize many types of incorrect test statements.

[[ n != 0 ]]                      # Constant test expressions
[[ -e *.mpg ]]                    # Existence checks of globs
[[ $foo==0 ]]                     # Always true due to missing spaces
[[ -n "$foo " ]]                  # Always true due to literals
[[ $foo =~ "fo+" ]]               # Quoted regex in =~
[ foo =~ re ]                     # Unsupported [ ] operators
[ $1 -eq "shellcheck" ]           # Numerical comparison of strings
[ $n && $m ]                      # && in [ .. ]
[ grep -q foo file ]              # Command without $(..)
[[ "$$file" == *.jpg ]]           # Comparisons that can't succeed
(( 1 -lt 2 ))                     # Using test operators in ((..))
[ x ] & [ y ] | [ z ]             # Accidental backgrounding and piping

Frequently misused commands

ShellCheck can recognize instances where commands are used incorrectly:

grep '*foo*' file                 # Globs in regex contexts
find . -exec foo {} && bar {} ;  # Prematurely terminated find -exec
sudo echo 'Var=42' > /etc/profile # Redirecting sudo
time --format=%s sleep 10         # Passing time(1) flags to time builtin
while read h; do ssh "$h" uptime  # Commands eating while loop input
alias archive='mv $1 /backup'     # Defining aliases with arguments
tr -cd '[a-zA-Z0-9]'              # [] around ranges in tr
exec foo; echo "Done!"            # Misused 'exec'
find -name *.bak -o -name *~ -delete  # Implicit precedence in find
# find . -exec foo > bar ;       # Redirections in find
f() { whoami; }; sudo f           # External use of internal functions

Common beginner’s mistakes

ShellCheck recognizes many common beginner’s syntax errors:

var = 42                          # Spaces around = in assignments
$foo=42                           # $ in assignments
for $var in *; do ...             # $ in for loop variables
var$n="Hello"                     # Wrong indirect assignment
echo ${var$n}                     # Wrong indirect reference
var=(1, 2, 3)                     # Comma separated arrays
array=( [index] = value )         # Incorrect index initialization
echo $var[14]                     # Missing {} in array references
echo "Argument 10 is $10"         # Positional parameter misreference
if $(myfunction); then ..; fi     # Wrapping commands in $()
else if othercondition; then ..   # Using 'else if'
f; f() { echo "hello world; }     # Using function before definition
[ false ]                         # 'false' being true
if ( -f file )                    # Using (..) instead of test

Style

ShellCheck can make suggestions to improve style:

[[ -z $(find /tmp | grep mpg) ]]  # Use grep -q instead
a >> log; b >> log; c >> log      # Use a redirection block instead
echo "The time is `date`"         # Use $() instead
cd dir; process *; cd ..;         # Use subshells instead
echo $[1+2]                       # Use standard $((..)) instead of old $[]
echo $(($RANDOM % 6))             # Don't use $ on variables in $((..))
echo "$(date)"                    # Useless use of echo
cat file | grep foo               # Useless use of cat

Data and typing errors

ShellCheck can recognize issues related to data and typing:

args="$@"                         # Assigning arrays to strings
files=(foo bar); echo "$files"    # Referencing arrays as strings
declare -A arr=(foo bar)          # Associative arrays without index
printf "%sn" "Arguments: $@."    # Concatenating strings and arrays
[[ $# > 2 ]]                      # Comparing numbers as strings
var=World; echo "Hello " var      # Unused lowercase variables
echo "Hello $name"                # Unassigned lowercase variables
cmd | read bar; echo $bar         # Assignments in subshells
cat foo | cp bar                  # Piping to commands that don't read
printf '%s: %sn' foo             # Mismatches in printf argument count
eval "${array[@]}"                # Lost word boundaries in array eval
for i in "${x[@]}"; do ${x[$i]}   # Using array value as key

Robustness

ShellCheck can make suggestions for improving the robustness of a script:

rm -rf "$STEAMROOT/"*            # Catastrophic rm
touch ./-l; ls *                 # Globs that could become options
find . -exec sh -c 'a && b {}' ; # Find -exec shell injection
printf "Hello $name"             # Variables in printf format
for f in $(ls *.txt); do         # Iterating over ls output
export MYVAR=$(cmd)              # Masked exit codes
case $version in 2.*) :;; 2.6.*) # Shadowed case branches

Portability

ShellCheck will warn when using features not supported by the shebang. For example, if you set the shebang to #!/bin/sh, ShellCheck will warn about portability issues similar to checkbashisms:

echo {1..$n}                     # Works in ksh, but not bash/dash/sh
echo {1..10}                     # Works in ksh and bash, but not dash/sh
echo -n 42                       # Works in ksh, bash and dash, undefined in sh
expr match str regex             # Unportable alias for `expr str : regex`
trap 'exit 42' sigint            # Unportable signal spec
cmd &> file                      # Unportable redirection operator
read foo < /dev/tcp/host/22      # Unportable intercepted files
foo-bar() { ..; }                # Undefined/unsupported function name
[ $UID = 0 ]                     # Variable undefined in dash/sh
local var=value                  # local is undefined in sh
time sleep 1 | sleep 5           # Undefined uses of 'time'

Miscellaneous

ShellCheck recognizes a menagerie of other issues:

PS1='e[0;32m$e[0m '            # PS1 colors not in [..]
PATH="$PATH:~/bin"                # Literal tilde in $PATH
rm “file”                         # Unicode quotes
echo "Hello world"                # Carriage return / DOS line endings
echo hello                       # Trailing spaces after 
var=42 echo $var                  # Expansion of inlined environment
!# bin/bash -x -e                 # Common shebang errors
echo $((n/180*100))               # Unnecessary loss of precision
ls *[:digit:].txt                 # Bad character class globs
sed 's/foo/bar/' file > file      # Redirecting to input
var2=$var2                        # Variable assigned to itself
[ x$var = xval ]                  # Antiquated x-comparisons
ls() { ls -l "$@"; }              # Infinitely recursive wrapper
alias ls='ls -l'; ls foo          # Alias used before it takes effect
for x; do for x; do               # Nested loop uses same variable
while getopts "a" f; do case $f in "b") # Unhandled getopts flags

Testimonials

At first you’re like «shellcheck is awesome» but then you’re like «wtf are we still using bash»

Alexander Tarasikov,
via Twitter

Ignoring issues

Issues can be ignored via environmental variable, command line, individually or globally within a file:

https://github.com/koalaman/shellcheck/wiki/Ignore

Reporting bugs

Please use the GitHub issue tracker for any bugs or feature suggestions:

https://github.com/koalaman/shellcheck/issues

Contributing

Please submit patches to code or documentation as GitHub pull requests! Check
out the DevGuide on the
ShellCheck Wiki.

Contributions must be licensed under the GNU GPLv3.
The contributor retains the copyright.

Copyright

ShellCheck is licensed under the GNU General Public License, v3. A copy of this license is included in the file LICENSE.

Copyright 2012-2019, Vidar ‘koala_man’ Holen and contributors.

Happy ShellChecking!

Other Resources

• The wiki has long form descriptions for each warning, e.g. SC2221.
• ShellCheck does not attempt to enforce any kind of formatting or indenting style, so also check out shfmt!

Время на прочтение
5 мин

Количество просмотров 12K

Написание shell-скриптов — занятие увлекательное. Скрипты командной строки помогают автоматизировать повседневные дела. Можно создать нечто прекрасное (или какую-нибудь гадость), однако, если уж что-то писать, хорошо бы точно знать, что код получается именно таким, каким он нужен программисту. Скрипт, написанный некачественно, может представлять опасность. Большинство новичков пишут скрипты, копируя фрагменты кода со StackOverflow, находя то, что им нужно, в Google, или пользуясь сайтами с вопросами и ответами по Linux. Такой подход к программированию выливается в некачественный код и в появление ошибок. Вот, например, команда rm, выполнение которой приведёт к катастрофе, так как переменная VAR не определена:

rm -rf "/$VAR/*"

Многие из проблем скриптов можно решить с помощью линтера, такого, как статический анализатор кода ShellCheck, который написан на Haskell. Он помогает искать ошибки в текстах скриптов и выводить отчёты о проведённых проверках. Это позволяет повысить производительность работы и качество кода. Сегодня мы расскажем о том, как установить и использовать ShellCheck в Linux и Unix-подобных операционных системах.

Установка

Самый простой способ локальной установки ShellCheck заключается в использовании применяемого в вашем дистрибутиве менеджера пакетов вроде apt/apt-get/yum и других.

▍Установка ShellCheck в Debian/Ubuntu Linux

Тут понадобится следующая команда apt / apt-get:

$ sudo apt install shellcheck

Вот пример реакции системы на эту команду:

[sudo] password for vivek: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  shellcheck
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,841 kB of archives.
After this operation, 15.5 MB of additional disk space will be used.
Get:1 http://in.archive.ubuntu.com/ubuntu artful/universe amd64 shellcheck amd64 0.4.6-1 [1,841 kB]
Fetched 1,841 kB in 42s (43.4 kB/s)
Selecting previously unselected package shellcheck.
(Reading database ... 196100 files and directories currently installed.)
Preparing to unpack .../shellcheck_0.4.6-1_amd64.deb ...
Unpacking shellcheck (0.4.6-1) ...
Setting up shellcheck (0.4.6-1) ...
Processing triggers for man-db (2.7.6.1-2) ...

▍Установка ShellCheck в CentOS/RHEL/Fedora/Oracle Linux

Сначала нужно включить репозиторий EPEL в CentOS/RHEL:

$ sudo yum -y install epel-release

Дальше надо ввести следующую команду yum:

$ sudo yum install ShellCheck

Вот что будет выведено в ответ на эту команду:

Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.excellmedia.net
 * epel: mirror.nes.co.id
 * extras: mirrors.vonline.vn
 * updates: centos-hcm.viettelidc.com.vn
Resolving Dependencies
--> Running transaction check
---> Package ShellCheck.x86_64 0:0.3.5-1.el7 will be installed
--> Processing Dependency: ghc(ShellCheck-0.3.5-297097a7f5fa37100847be7f096be51e) for package: ShellCheck-0.3.5-1.el7.x86_64
.....
..
...
Dependencies Resolved
 
===============================================================================
 Package                Arch         Version                  Repository  Size
===============================================================================
Installing:
 ShellCheck             x86_64       0.3.5-1.el7              epel       495 k
Installing for dependencies:
 ghc-ShellCheck         x86_64       0.3.5-1.el7              epel       540 k
 ghc-array              x86_64       0.4.0.1-26.4.el7         epel       113 k
 ghc-base               x86_64       4.6.0.1-26.4.el7         epel       1.6 M
 ghc-bytestring         x86_64       0.10.0.2-26.4.el7        epel       182 k
 ghc-containers         x86_64       0.5.0.0-26.4.el7         epel       287 k
 ghc-deepseq            x86_64       1.3.0.1-26.4.el7         epel        45 k
 ghc-directory          x86_64       1.2.0.1-26.4.el7         epel        59 k
 ghc-filepath           x86_64       1.3.0.1-26.4.el7         epel        60 k
 ghc-json               x86_64       0.7-4.el7                epel        96 k
 ghc-mtl                x86_64       2.1.2-27.el7             epel        33 k
 ghc-old-locale         x86_64       1.0.0.5-26.4.el7         epel        50 k
 ghc-parsec             x86_64       3.1.3-31.el7             epel       105 k
 ghc-pretty             x86_64       1.1.1.0-26.4.el7         epel        57 k
 ghc-regex-base         x86_64       0.93.2-29.el7            epel        28 k
 ghc-regex-compat       x86_64       0.95.1-35.el7            epel        15 k
 ghc-regex-posix        x86_64       0.95.2-30.el7            epel        47 k
 ghc-syb                x86_64       0.4.0-35.el7             epel        39 k
 ghc-text               x86_64       0.11.3.1-2.el7           epel       379 k
 ghc-time               x86_64       1.4.0.1-26.4.el7         epel       187 k
 ghc-transformers       x86_64       0.3.0.0-34.el7           epel       100 k
 ghc-unix               x86_64       2.6.0.1-26.4.el7         epel       160 k
 
Transaction Summary
===============================================================================
Install  1 Package (+21 Dependent packages)
 
Total download size: 4.6 M
Installed size: 28 M
Is this ok [y/d/N]: y
Downloading packages:
(1/22): ghc-bytestring-0.10.0.2-26.4.el7.x86_64.rpm       | 182 kB   00:09     
(2/22): ghc-array-0.4.0.1-26.4.el7.x86_64.rpm             | 113 kB   00:09     
....
..
...
  ghc-parsec.x86_64 0:3.1.3-31.el7                                             
  ghc-pretty.x86_64 0:1.1.1.0-26.4.el7                                         
  ghc-regex-base.x86_64 0:0.93.2-29.el7                                        
  ghc-regex-compat.x86_64 0:0.95.1-35.el7                                      
  ghc-regex-posix.x86_64 0:0.95.2-30.el7                                       
  ghc-syb.x86_64 0:0.4.0-35.el7                                                
  ghc-text.x86_64 0:0.11.3.1-2.el7                                             
  ghc-time.x86_64 0:1.4.0.1-26.4.el7                                           
  ghc-transformers.x86_64 0:0.3.0.0-34.el7                                     
  ghc-unix.x86_64 0:2.6.0.1-26.4.el7                                           
 
Complete!

Если вы пользуетесь Fedora, выполните следующую команду dnf:

$ sudo dnf install ShellCheck

▍Установка ShellCheck в Arch Linux

Введите следующую команду pacman:

$ sudo pacman -S shellcheck

▍Установка ShellCheck в Gentoo Linux

Введите такую команду emerge:

$ sudo emerge --ask shellcheck

▍Установка ShellCheck в OpenSUSE Linux

Введите следующую команду zypper:

$ sudo zypper in ShellCheck

▍Установка ShellCheck в macOS Unix

Воспользуйтесь следующей командой port если вы работаете с MacPorts:

$ port install shellcheck

Если вы пользуетесь Homebrew в macOS/OS X, введите такую команду brew:

$ brew install shellcheck

Как пользоваться ShellCheck

Испытаем ShellCheck на скрипте, содержимое которого просмотрим с помощью команды cat:

$ cat -n backupme

Вот его код:

#!/bin/bash
t="/tmp/exclude.$$"
source ~/.backup.conf
>$t
for w in $WHATNOT
do
    echo $w >> $t
done
rsync $OPT -avr --exclude-from=$t  $WHAT $SERVER:$WHERE
rm -rf $t

Теперь проверим скрипт с помощью ShellCheck:

$ shellcheck backupme

В ответ программа выдаст следующее:

ShellCheck в действии

Утилита ShellCheck предложила внести исправления, касающиеся использования переменных, не заключённых в кавычки, а также сообщила о других проблемах. Исправим ошибки и снова просмотрим текст скрипта следующей командой:

$ cat -n backupme

Вот что, в итоге, получилось:

#!/bin/bash
t="/tmp/exclude.$$"
source ~/.backup.conf
touch $t
for w in $WHATNOT
do
    echo "$w" >> $t
done
rsync "$OPT" -avr --exclude-from=$t  "$WHAT" "$SERVER:$WHERE"
rm -rf "$t"

Интеграция ShellCheck в текстовый редактор

ShellCheck можно интегрировать в vim или emacs, в результате, он будет проверять тексты скриптов прямо в редакторе. Тут показано применение плагина для vim neomake, асинхронного средства для линтинга и сборки программ. Он был установлен с использованием менеджера плагинов vim-plug в ~/.vimrc:

call plug#begin('~/.vim/plugged')
Plug 'pearofducks/ansible-vim'
" install and use neomake linting
Plug 'neomake/neomake'
call plug#end()

Для установки ansible-vim и neomake/neomake, введите в vim следующую команду:

:PlugInstall

Для использования плагина введите следующую команду, редактируя bash/sh-скрипт:

:Neomake

Вот как выглядят результаты работы плагина в редакторе:

Neomake выводит предупреждения и сообщения об ошибках с помощью ShellCheck

Итоги

Полагаем, ShellCheck — это замечательный инструмент, который позволяет улучшать и исправлять скрипты командной строки Linux. Он способен обнаруживать множество распространённых недоработок и ошибок в их коде. Если вы хотите узнать о SpellCheck больше — вот сайт проекта, а вот — его репозиторий на GitHub.

Уважаемые читатели! Проверяете ли вы свои скрипты чем-то вроде ShellCheck?

A bash script is a text file that contains a sequence of commands that are executed by the bash shell, a Unix-based command-line interface. Bash scripts are used to automate tasks, create utility scripts, and perform a wide range of other functions in the command-line environment. They can include variables, loops, conditional statements, and other programming constructs, allowing you to perform a wide range of tasks from the command line.

How to create a Bash Script?

Step 1: Create a text file with .sh file extension. (Here, helloworld.sh).

touch <name of file>.sh

Step 2: Open it in an editor like nano, and add the commands you want to execute, one per line.

Step 3: Save the file.

Ctrl+X -> Y -> Enter key

Step 4: Now check for executable permission for the bash script.

ls -l

x means that the file has executable permissions.

If it has executable permission, skip Step 5 else continue.

Step 5: Give the file executable permission, using the following command.

chmod +x <name of file with extension>

Step 6: Execute the file using bash or ./

bash <name of file>.sh

./<name of file>.sh

Check for syntax errors

To check the syntax of a Bash script without running it, you can use the bash -n option. This option tells the Bash interpreter to read the script and check the syntax without actually executing the commands in the script.

To use the bash -n (noexec) option, open a terminal and navigate to the directory where the Bash script is located.

cd <directory name>

Then, enter the following command:

bash -n <name of file>.sh

If the script has no syntax errors, this command will not produce any output. 

If there are syntax errors, the Bash interpreter will print an error message indicating the line number and the nature of the error.

Caveats

• The “noexec” option only checks the syntax of the script, it does not catch all possible errors. This means that even if the “noexec” option does not report any issues, your script may still contain other mistakes that you need to fix. For example, you may have a runtime error, such as trying to divide by zero, that the “noexec” option will not catch.
• This does not execute any commands in the script, so it cannot catch runtime errors. This means that if your script has a command that produces an error when it is run, the “noexec” option will not detect this.
• This does not interpret shell variables, so it may not catch errors related to the use of variables. This means that if you have a typo in a variable name, or if you are using a variable that has not been defined, the “noexec” option will not report this.
• This option does not check the exit status of commands, so it may not catch errors related to the return value of commands. This means that if you have a command that returns an error code, the “noexec” option will not detect this.
• This does not check the permissions of files or directories, so it may not catch errors related to file system permissions. This means that if your script tries to access a file or directory that it does not have permission to access, the “noexec” option will not report this.

To check for syntax errors along with the content

To check for syntax errors along with the script’s content, the bash -v option can be used to print each line of the script as it is read by the interpreter, and print the syntax errors in the script if any. This can be helpful for debugging syntax errors or other issues in the script. To use the bash -v option, navigate to the directory where the bash script is located

cd <directory name>

And enter the following command:

bash -v <name of the file>.sh

If no syntax error, then it will just print the lines of the script.

If there is a syntax error the Bash interpreter will print an error message indicating the line number and the nature of the error along with the contents of the file.

 Using the Shell Check Tool

A static analysis tool for shell scripts is called ShellCheck. It can be applied to bash, sh, and other shell scripts to detect syntax mistakes, semantic flaws, and stylistic problems.

To use Shell Check Tool, it must be installed first:

apt-get install shellcheck

To check for errors run the command shellcheck with the name of the file:

shellcheck <name of file>.sh

Conclusion

With the bash -n option, you may check for syntax problems. However, keep in mind that this option just examines the script’s syntax and may not identify all potential mistakes. Even so, it’s crucial to thoroughly test your scripts before putting them to use in a real-world setting. You can use the bash -v option to inspect the script’s text and syntax for mistakes. This will output all script lines as they are read by the interpreter, along with any syntax mistakes.

Last Updated :
05 Feb, 2023

Like Article

Save Article

Shell script analysis tool

Examples (TL;DR)

• Check a shell script: shellcheck path/to/script.sh
• Check a shell script interpreting it as the specified shell dialect (overrides the shebang at the top of the script): shellcheck --shell sh|bash|dash|ksh path/to/script.sh
• Ignore one or more error types: shellcheck --exclude SC1009,SC1073 path/to/script.sh
• Also check any sourced shell scripts: shellcheck --checked-sourced path/to/script.sh
• Display output in the specified format (defaults to tty): shellcheck --format tty|checkstyle|diff|gcc|json|json1|quiet path/to/script.sh
• Enable one or more optional checks: shellcheck --enable=add-default-case|avoid-nullary-conditions
• List all available optional checks that are disabled by default: shellcheck --list-optional

tldr.sh

Synopsis

shellcheck [Options...] FILES...

Description

ShellCheck is a static analysis and linting tool for sh/bash scripts. It’s mainly focused on handling typical beginner and intermediate level syntax errors and pitfalls where the shell just gives a cryptic error message or strange behavior, but it also reports on a few more advanced issues where corner cases can cause delayed failures.

ShellCheck gives shell specific advice. Consider this line:

(( area = 3.14*r*r ))

• For scripts starting with #!/bin/sh (or when using -s sh), ShellCheck will warn that (( .. )) is not POSIX compliant (similar to checkbashisms).
• For scripts starting with #!/bin/bash (or using -s bash), ShellCheck will warn that decimals are not supported.
• For scripts starting with #!/bin/ksh (or using -s ksh), ShellCheck will not warn at all, as ksh supports decimals in arithmetic contexts.

Options

-a, —check-sourced

Emit warnings in sourced files. Normally, shellcheck will only warn about issues in the specified files. With this option, any issues in sourced files will also be reported.

-C[WHEN], —color[=WHEN]

For TTY output, enable colors always, never or auto. The default is auto. —color without an argument is equivalent to —color=always.

-i CODE1[,CODE2…], —include=CODE1[,CODE2…]

Explicitly include only the specified codes in the report. Subsequent -i options are cumulative, but all the codes can be specified at once, comma-separated as a single argument. Include options override any provided exclude options.

-e CODE1[,CODE2…], —exclude=CODE1[,CODE2…]

Explicitly exclude the specified codes from the report. Subsequent -e options are cumulative, but all the codes can be specified at once, comma-separated as a single argument.

-f FORMAT, —format=FORMAT

Specify the output format of shellcheck, which prints its results in the standard output. Subsequent -f options are ignored, see Formats below for more information.

—list-optional

Output a list of known optional checks. These can be enabled with -o flags or enable directives.

—norc

Don’t try to look for .shellcheckrc configuration files.

-o NAME1[,NAME2…], —enable=NAME1[,NAME2…]

Enable optional checks. The special name all enables all of them. Subsequent -o options accumulate. This is equivalent to specifying enable directives.

-P SOURCEPATH, —source-path=SOURCEPATH

Specify paths to search for sourced files, separated by : on Unix and ; on Windows. This is equivalent to specifying search-path directives.

-s shell, —shell=shell

Specify Bourne shell dialect. Valid values are sh, bash, dash and ksh. The default is to deduce the shell from the file’s shell directive, shebang, or .bash/.bats/.dash/.ksh extension, in that order. sh refers to POSIX sh (not the system’s), and will warn of portability issues.

-S SEVERITY, —severity=severity

Specify minimum severity of errors to consider. Valid values in order of severity are error, warning, info and style. The default is style.

-V, —version

Print version information and exit.

-W NUM, —wiki-link-count=NUM

For TTY output, show NUM wiki links to more information about mentioned warnings. Set to 0 to disable them entirely.

-x, —external-sources

Follow source statements even when the file is not specified as input. By default, shellcheck will only follow files specified on the command line (plus /dev/null). This option allows following any file the script may source.

This option may also be enabled using external-sources=true in .shellcheckrc. This flag takes precedence.

FILES…

One or more script files to check, or «-» for standard input.

Formats

tty

Plain text, human readable output. This is the default.

gcc

GCC compatible output. Useful for editors that support compiling and showing syntax errors.

For example, in Vim, :set makeprg=shellcheck -f gcc % will allow using :make to check the script, and :cnext to jump to the next error.

<file>:<line>:<column>: <type>: <message>

checkstyle

Checkstyle compatible XML output. Supported directly or through plugins by many IDEs and build monitoring systems.

<?xml version='1.0' encoding='UTF-8'?>
<checkstyle version='4.3'>
  <file name='file'>
    <error
      line='line'
      column='column'
      severity='severity'
      message='message'
      source='ShellCheck.SC####' />
    ...
  </file>
  ...
</checkstyle>

diff

Auto-fixes in unified diff format. Can be piped to git apply or patch -p1 to automatically apply fixes.

--- a/test.sh
+++ b/test.sh
@@ -2,6 +2,6 @@
 ## Example of a broken script.
 for f in $(ls *.m3u)
 do
-  grep -qi hq.*mp3 $f 
+  grep -qi hq.*mp3 "$f" 
     && echo -e 'Playlist $f contains a HQ file in mp3 format'
 done

json1

Json is a popular serialization format that is more suitable for web applications. ShellCheck’s json is compact and contains only the bare minimum. Tabs are counted as 1 character.

{
  comments: [
    {
      "file": "filename",
      "line": lineNumber,
      "column": columnNumber,
      "level": "severitylevel",
      "code": errorCode,
      "message": "warning message"
    },
    ...
  ]
}

json

This is a legacy version of the json1 format. It’s a raw array of comments, and all offsets have a tab stop of 8.

quiet

Suppress all normal output. Exit with zero if no issues are found, otherwise exit with one. Stops processing after the first issue.

Directives

ShellCheck directives can be specified as comments in the shell script. If they appear before the first command, they are considered file-wide. Otherwise, they apply to the immediately following command or block:

# shellcheck key=value key=value
command-or-structure

For example, to suppress SC2035 about using ./*.jpg:

# shellcheck disable=SC2035
echo "Files: " *.jpg

To tell ShellCheck where to look for an otherwise dynamically determined file:

# shellcheck source=./lib.sh
source "$(find_install_dir)/lib.sh"

Here a shell brace group is used to suppress a warning on multiple lines:

# shellcheck disable=SC2016
{
  echo 'Modifying $PATH'
  echo 'PATH=foo:$PATH' >> ~/.bashrc
}

Valid keys are:

disable

Disables a comma separated list of error codes for the following command. The command can be a simple command like echo foo, or a compound command like a function definition, subshell block or loop. A range can be be specified with a dash, e.g. disable=SC3000-SC4000 to exclude 3xxx. All warnings can be disabled with disable=all.

enable

Enable an optional check by name, as listed with —list-optional. Only file-wide enable directives are considered.

external-sources

Set to true in .shellcheckrc to always allow ShellCheck to open arbitrary files from ‘source’ statements (the way most tools do).

This option defaults to false only due to ShellCheck’s origin as a remote service for checking untrusted scripts. It can safely be enabled for normal development.

source

Overrides the filename included by a source/. statement. This can be used to tell shellcheck where to look for a file whose name is determined at runtime, or to skip a source by telling it to use /dev/null.

source-path

Add a directory to the search path for source/. statements (by default, only ShellCheck’s working directory is included). Absolute paths will also be rooted in these paths. The special path SCRIPTDIR can be used to specify the currently checked script’s directory, as in source-path=SCRIPTDIR or source-path=SCRIPTDIR/../libs. Multiple paths accumulate, and -P takes precedence over them.

shell

Overrides the shell detected from the shebang. This is useful for files meant to be included (and thus lacking a shebang), or possibly as a more targeted alternative to ‘disable=SC2039’.

RC Files

Unless --norc is used, ShellCheck will look for a file .shellcheckrc or shellcheckrc in the script’s directory and each parent directory. If found, it will read key=value pairs from it and treat them as file-wide directives.

Here is an example .shellcheckrc:

# Look for 'source'd files relative to the checked script,
# and also look for absolute paths in /mnt/chroot
source-path=SCRIPTDIR
source-path=/mnt/chroot

# Since 0.9.0, values can be quoted with '' or "" to allow spaces
source-path="My Documents/scripts"

# Allow opening any 'source'd file, even if not specified as input
external-sources=true

# Turn on warnings for unquoted variables with safe values
enable=quote-safe-variables

# Turn on warnings for unassigned uppercase variables
enable=check-unassigned-uppercase

# Allow [ ! -z foo ] instead of suggesting -n
disable=SC2236

If no .shellcheckrc is found in any of the parent directories, ShellCheck will look in ~/.shellcheckrc followed by the XDG config directory (usually ~/.config/shellcheckrc) on Unix, or %APPDATA%/shellcheckrc on Windows. Only the first file found will be used.

Note for Snap users: the Snap sandbox disallows access to hidden files. Use shellcheckrc without the dot instead.

Note for Docker users: ShellCheck will only be able to look for files that are mounted in the container, so ~/.shellcheckrc will not be read.

Environment Variables

The environment variable SHELLCHECK_OPTS can be set with default flags:

export SHELLCHECK_OPTS='--shell=bash --exclude=SC2016'

Its value will be split on spaces and prepended to the command line on each invocation.

Return Values

ShellCheck uses the following exit codes:

• 0: All files successfully scanned with no issues.
• 1: All files successfully scanned with some issues.
• 2: Some files could not be processed (e.g. file not found).
• 3: ShellCheck was invoked with bad syntax (e.g. unknown flag).
• 4: ShellCheck was invoked with bad options (e.g. unknown formatter).

Locale

This version of ShellCheck is only available in English. All files are leniently decoded as UTF-8, with a fallback of ISO-8859-1 for invalid sequences. LC_CTYPE is respected for output, and defaults to UTF-8 for locales where encoding is unspecified (such as the C locale).

Windows users seeing commitBuffer: invalid argument (invalid character) should set their terminal to use UTF-8 with chcp 65001.

Known Incompatibilities

(If nothing in this section makes sense, you are unlikely to be affected by it)

To avoid confusing and misguided suggestions, ShellCheck requires function bodies to be either { brace groups; } or ( subshells ), and function names containing []*=! are only recognized after a function keyword.

The following unconventional function definitions are identical in Bash, but ShellCheck only recognizes the latter.

[x!=y] () [[ $1 ]]
function [x!=y] () { [[ $1 ]]; }

Shells without the function keyword do not allow these characters in function names to begin with. Function names containing {} are not supported at all.

Further, if ShellCheck sees [x!=y] it will assume this is an invalid comparison. To invoke the above function, quote the command as in '[x!=y]', or to retain the same globbing behavior, use command [x!=y].

ShellCheck imposes additional restrictions on the [ command to help diagnose common invalid uses. While [ $x= 1 ] is defined in POSIX, ShellCheck will assume it was intended as the much more likely comparison [ "$x" = 1 ] and fail accordingly. For unconventional or dynamic uses of the [ command, use test or [ instead.

Reporting Bugs

Bugs and issues can be reported on GitHub:

https://github.com/koalaman/shellcheck/issues

Authors

ShellCheck is developed and maintained by Vidar Holen, with assistance from a long list of wonderful contributors.

Copyright

Copyright 2012-2022, Vidar Holen and contributors. Licensed under the GNU General Public License version 3 or later, see https://gnu.org/licenses/gpl.html

See Also

sh(1) bash(1)

Info

Shell script analysis tool