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
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 "%s\n" "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: %s\n' 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?
Is it possible to check a bash script syntax without executing it?
Using Perl, I can run perl -c 'script name'. Is there any equivalent command for bash scripts?
codeforester
39.6k16 gold badges113 silver badges141 bronze badges
asked Oct 5, 2008 at 12:51
1
bash -n scriptname
Perhaps an obvious caveat: this validates syntax but won’t check if your bash script tries to execute a command that isn’t in your path, like ech hello instead of echo hello.
Chris
44.7k16 gold badges138 silver badges157 bronze badges
answered Oct 5, 2008 at 12:55
andyandy
6,8881 gold badge20 silver badges17 bronze badges
10
Time changes everything. Here is a web site which provide online syntax checking for shell script.
I found it is very powerful detecting common errors.
About ShellCheck
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.
Haskell source code is available on GitHub!
answered Oct 24, 2013 at 17:55
dvd818dvd818
1,7371 gold badge10 silver badges10 bronze badges
6
I also enable the ‘u’ option on every bash script I write in order to do some extra checking:
set -u
This will report the usage of uninitialized variables, like in the following script ‘check_init.sh’
#!/bin/sh
set -u
message=hello
echo $mesage
Running the script :
$ check_init.sh
Will report the following :
./check_init.sh[4]: mesage: Parameter not set.
Very useful to catch typos
answered May 23, 2012 at 14:10
Diego TerceroDiego Tercero
1,1431 gold badge11 silver badges17 bronze badges
2
sh -n script-name
Run this. If there are any syntax errors in the script, then it returns the same error message.
If there are no errors, then it comes out without giving any message. You can check immediately by using echo $?, which will return 0 confirming successful without any mistake.
It worked for me well. I ran on Linux OS, Bash Shell.
Rob Hruska
119k32 gold badges167 silver badges192 bronze badges
answered Feb 2, 2011 at 13:16
JeevanJeevan
2693 silver badges2 bronze badges
4
I actually check all bash scripts in current dir for syntax errors WITHOUT running them using find tool:
Example:
find . -name '*.sh' -print0 | xargs -0 -P"$(nproc)" -I{} bash -n "{}"
If you want to use it for a single file, just edit the wildcard with the name of the file.
Bensuperpc
1,2751 gold badge14 silver badges21 bronze badges
answered Aug 3, 2017 at 11:58
Gerald HughesGerald Hughes
5,77920 gold badges73 silver badges132 bronze badges
null command [colon] also useful when debugging to see variable’s value
set -x
for i in {1..10}; do
let i=i+1
: i=$i
done
set -
answered Jan 17, 2014 at 10:41
mug896mug896
1,7771 gold badge19 silver badges17 bronze badges
2
For only validating syntax:
shellcheck [programPath]
For running the program only if syntax passes, so debugging both syntax and execution:
shellproof [programPath]
answered Feb 13, 2021 at 1:52
Bash shell scripts will run a syntax check if you enable syntax checking with
set -o noexec
if you want to turn off syntax checking
set +o noexec
Alexis Wilke
19.2k10 gold badges86 silver badges156 bronze badges
answered Aug 30, 2021 at 3:28
If you need in a variable the validity of all the files in a directory (git pre-commit hook, build lint script), you can catch the stderr output of the «sh -n» or «bash -n» commands (see other answers) in a variable, and have a «if/else» based on that
bashErrLines=$(find bin/ -type f -name '*.sh' -exec sh -n {} \; 2>&1 > /dev/null)
if [ "$bashErrLines" != "" ]; then
# at least one sh file in the bin dir has a syntax error
echo $bashErrLines;
exit;
fi
Change «sh» with «bash» depending on your needs
answered Jul 16, 2019 at 9:17
E CiottiE Ciotti
4,7501 gold badge25 silver badges17 bronze badges
Opening
Being involved in technology, specifically web, it does not take long we have to write a bash (or shell) script. If you work with server side technology this event happens very soon after logging into a server. As a Dev(Sec)Ops practitioner linting code during the a CI/CD process is a basic requirement for me personally. Until recently linting Bash/sh code for me was a painful process. However, like so much else it was just a matter of time before a solution was found to automate the process. Enter ‘shellcheck’.
Installation
For this quick demo I am running Ubuntu 18.04. The installation process is very straight forward, APT work for this.
sudo apt-get install -y shellcheck
Once executed we should see the standard install output. Just to make sure everything completed as expected I execute a quick version check.
shellcheck --version
And has hoped shellcheck is indeed installed.
Options
Getting to the options of shellcheck is as easy as the installation. A quick ‘—help’ argument provides us with the list of execution options.
shellcheck --help
Usage
So far so good. Now lets look at how it executes. I has a BASH file in my home directory that provides the SVN history of a file so I used that as a demo.
shellcheck ./svn_file_history.sh
Hey, that’s pretty neat. Give it is standard output it would be easy to pipe these messages to a reporting system or quality gate process. Nice.
Closing
shellcheck is one of those tools that makes life much easier, as long as you know about it before trying to write your own monster of a syntax checker. Easy to install, easy to use, easy to integrate with it becomes yet another quality and security insurance step along the development pipeline.
Share your favorite linter in the comments so we can all learn.
Additional Resources
- https://en.wikipedia.org/wiki/Lint_(software)
- https://nickjanetakis.com/blog/here-is-why-you-should-quote-your-variables-in-bash
- https://github.com/koalaman/shellcheck
- Header Image from https://www.youtube.com/watch?v=lbMsFXMnqNY