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

ShellCheck, a static analysis tool for shell scripts - GitHub - koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts

Build Status

ShellCheck — A shell script static analysis tool

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

Screenshot of a terminal showing problematic shell script lines highlighted

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:

Screenshot of Vim showing inlined shellcheck feedback.

  • Emacs, through Flycheck or Flymake:

Screenshot of emacs showing inlined shellcheck feedback.

  • 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)

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).

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!

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's user avatar

codeforester

37.4k16 gold badges107 silver badges132 bronze badges

asked Oct 5, 2008 at 12:51

Tom Feiner's user avatar

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's user avatar

Chris

43.6k16 gold badges138 silver badges154 bronze badges

answered Oct 5, 2008 at 12:55

andy's user avatar

andyandy

6,7881 gold badge19 silver badges17 bronze badges

12

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.

enter image description here

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

dvd818's user avatar

dvd818dvd818

1,7071 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 Tercero's user avatar

Diego TerceroDiego Tercero

1,1331 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's user avatar

Rob Hruska

117k31 gold badges167 silver badges192 bronze badges

answered Feb 2, 2011 at 13:16

Jeevan's user avatar

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's user avatar

Bensuperpc

1,2051 gold badge13 silver badges21 bronze badges

answered Aug 3, 2017 at 11:58

Gerald Hughes's user avatar

Gerald HughesGerald Hughes

5,58119 gold badges74 silver badges123 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

mug896's user avatar

mug896mug896

1,6871 gold badge17 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

Alberto Salvia Novella's user avatar

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's user avatar

Alexis Wilke

18.4k10 gold badges80 silver badges146 bronze badges

answered Aug 30, 2021 at 3:28

Mike's user avatar

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 Ciotti's user avatar

E CiottiE Ciotti

4,6601 gold badge24 silver badges17 bronze badges

Есть методы из традиционных сред программирования, которые могут помочь.

Некоторые основные инструменты, такие как использование редактора с подсветкой синтаксиса, также помогут.

Есть встроенные опции, которые Bash сам по себе предоставляет, чтобы упростить отладку и ежедневную работу системного администратора Linux.

В этой статье вы узнаете несколько полезных методов отладки скриптов Bash:

  • Как использовать традиционные методы
  • Как использовать параметр xtrace
  • Как использовать другие параметры Bash
  • Как использовать trap

Используя Традиционные Методы

Отладка кода может быть сложной, даже если ошибки просты и очевидны.

Для помощи программистам традиционно использовались такие инструменты, как отладчики и подсветка синтаксиса в редакторах.

Ничего не меняется при написании скриптов Bash.

Простое выделение синтаксиса позволит вам отлавливать ошибки при написании кода, избавляя вас от трудоемкой задачи отслеживания ошибок на более позднем этапе.

Некоторые языки программирования поставляются с сопутствующими средами отладки, такими как gcc и gdb, которые позволяют вам шагать по коду, устанавливать точки останова, исследовать состояние всего в моменты выполнения и многое другое – но, как правило, тут не требуется такой сложный подход, как этот с скрипт оболочки и код просто интерпретируется, а не компилируется в двоичные файлы.

Существуют методы, используемые в традиционных средах программирования, которые могут быть полезны со сложными скриптами Bash, например, с использованием утверждений.

В основном это способы явного утверждения условий или состояния вещей в определенный момент времени.

Утверждения могут выявить даже самые незначительные ошибки.

Они могут быть реализованы в виде короткой функции, которая показывает время, номер строки и тому подобное, или что-то вроде этого:

$ echo "function_name(): value of $var is ${var}"

Как использовать опцию Bash xtrace

При написании скриптов оболочки логика программирования имеет тенденцию быть короче и часто содержится в одном файле.

Таким образом, есть несколько встроенных опций отладки, которые мы можем использовать, чтобы увидеть, что происходит не так.

Первый вариант, который стоит упомянуть, вероятно, самый полезный – параметр xtrace.

Его можно применить к скрипту, вызвав Bash с ключом -x.

$ bash -x <scriptname>

Он говорит Bash показать нам, как выглядит каждое выражение непосредственно перед тем, как оно выполнится.

Вскоре мы увидим пример этого параметра в действии, но сначала давайте начнем с контраста -x с его противоположностью -v, который показывает каждую строку до ее оценки, а не после.

Опции можно комбинировать, и, используя -x и -v, вы можете увидеть, как выглядят операторы до и после замены переменных.

Как использовать другие параметры Bash

Параметры отладки Bash по умолчанию отключены, но как только они включаются с помощью команды set, они остаются включенными до тех пор, пока не будут явно отключены.

Если вы не уверены, какие опции включены, вы можете проверить переменную $ -, чтобы увидеть текущее состояние всех переменных.

$ echo $-
himBHs
$ set -xv && echo $-
himvxBHs

Есть еще один полезный ключ, который мы можем использовать, чтобы помочь нам найти переменные, на которые что-то ссылается, без установки какого-либо значения.

Это ключ -u, и точно так же, как -x и -v, его также можно использовать в командной строке.

Мы можем использовать эти опции в коротких скриптах Bash, чтобы предоставить нам информацию отладки для выявления проблем, которые иначе не вызовут обратную связь от интерпретатора Bash.

Как использовать trap, чтобы помочь в отладке

Есть более сложные методы, которые стоит рассмотреть, если ваши скрипты большиие сложные, включая использование функции assert, как упоминалось ранее.

Один из таких методов, о которых следует помнить, – это использование trap bash позволяют нам перехватывать сигналы и что-то делать в этой точке.

Простой, но полезный пример, который вы можете использовать в своих скриптах Bash – это trap EXIT.

Заключение

Если вы заметили, что ваш скрипт Bash ведет себя не так, как ожидалось, и причина по какой-либо причине вам не ясна, подумайте, какая информация будет полезна, чтобы помочь вам определить причину, а затем используйте наиболее удобные инструменты, доступные для определения проблем.

Опция xtrace -x проста в использовании и, вероятно, является наиболее полезной из представленных здесь опций, поэтому попробуйте попробовать ее в следующий раз, когда вы столкнетесь со скриптом, который не выполняет то, что, по вашему мнению должно произойти.

ShellCheck – это бесплатный инструмент статического анализа с открытым исходным кодом, который можно использовать для проверки и улучшения скриптов.

Он способен выделять как общие, так и граничные ошибки и предлагать соответствующие исправления.

ShellCheck может использоваться как онлайновая или системная утилита, а также может быть интегрирован в качестве линтера в различные текстовые редакторы.

В этом руководстве мы узнаем, как установить и использовать ShellCheck в некоторых наиболее распространенных дистрибутивах Linux, а также как интегрировать его в Vim и Visual Studio Code.

  • 🕵️ Scanmycode-Ce: Сканирование кода/SAST/Статический анализ/Linting с использованием многих инструментов/сканеров
  • 🕵️ Njsscan : Семантический инструмент SAST, который может находить небезопасные паттерны кода в приложениях Node.js
  • 🐛 SAST или DAST: Что лучше использовать для тестирования безопасности приложений

Содержание

  1. Установка
  2. Использование
  3. Использование онлайн-версии ShellCheck
  4. Интеграция ShellCheck в текстовые редакторы
  5. Интеграция ShellCheck в Vim
  6. Интеграция ShellCheck в Visual Studio Code
  7. Заключение

Установка

Прежде всего, давайте установим ShellCheck на нашу любимую систему на базе Linux.

Это очень простая задача, поскольку утилита упакована в программные репозитории наиболее используемых дистрибутивов.

Все, что нам нужно сделать, это использовать соответствующий менеджер пакетов.

На Fedora, например, мы будем использовать dnf:

sudo dnf install ShellCheck

В  системах на базе Debian вместо этого мы используем apt:

sudo apt install shellcheck

В Archlinux мы используем pacman:

sudo pacman -S shellcheck

Использование

Использовать ShellCheck очень просто.

Чаще всего мы просто вызываем команду и передаем в качестве аргумента путь к скрипту, который хотим проверить.

Приведем пример.

В следующем фрагменте вы можете видеть, что мы пропустили кавычки в переменной shell.

Это распространенная ошибка, которая, в зависимости от обстоятельств, может быть опасной:

#!/bin/bash

text=”this is the text”

echo $text

Мы сохраним приведенный выше код в файле script.sh.

Чтобы проверить его с помощью ShellCheck, мы просто передадим его в качестве аргумента утилите:


Результатом выполнения приведенной выше команды будет следующее:

In script.sh line 5:
echo $text
     ^---^ SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: 
echo "$text"

For more information:
  https://www.shellcheck.net/wiki/SC2086 -- Double quote to prevent globbing ...

Как видите, ошибка найдена и выделена правильно.

Ошибка идентифицируется определенным кодом, в данном случае это SC2086, и для нее дается краткое описание.

Более подробную информацию можно получить, просто нажав на предоставленную ссылку, которая указывает на соответствующую страницу ShellCheck Wiki:

ShellCheck, помимо всего прочего, также способен обнаруживать “башизмы”: нестандартные особенности, характерные для оболочки Bash.

Мы получаем предупреждение, когда не указываем явно Bash в качестве интерпретатора оболочки.

Например, посмотрите на этот пример:

#!/bin/sh

# Prints the current date and time
function now() {
date ‘+%Y/%m/%d %H:%M’
}

Если мы запустим ShellCheck с этим кодом, то получим следующий результат:

In date.sh line 4:
function now() {
^-- SC2112 (warning): 'function' keyword is non-standard. Delete it.

For more information:
  https://www.shellcheck.net/wiki/SC2112 -- 'function' keyword is non-standar...

Хотя в коде нет ошибок, ShellCheck предупреждает нас, потому что мы использовали ключевое слово “function” для создания функции: этот синтаксис специфичен для bash, но мы не указали bash в качестве интерпретатора скриптов (мы использовали /bin/sh, который в некоторых дистрибутивах, например Ubuntu, является символической ссылкой, указывающей на оболочку “dash”).

Хотя в коде нет ошибок, ShellCheck предупреждает нас, потому что мы использовали ключевое слово “function” для создания функции: этот синтаксис специфичен для bash, но мы не указали bash в качестве интерпретатора сценариев (мы использовали /bin/sh, который в некоторых дистрибутивах, например Ubuntu, является символической ссылкой, указывающей на оболочку “dash”).

Использование онлайн-версии ShellCheck

Если по каким-то причинам мы не можем или не хотим устанавливать ShellCheck на нашу систему, мы можем проверить наши скрипты онлайн, используя веб-версию ShellCheck.

Все, что нам нужно сделать, это вставить наш код в онлайн-редактор.

Под ним появятся предупреждения:

Это поведение можно повторить в большинстве текстовых редакторов, интегрировав ShellCheck в качестве линтера.

Давайте посмотрим, как это сделать.

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

ShellCheck может быть интегрирован в некоторые из наиболее используемых текстовых редакторов в качестве линтера.

Давайте посмотрим несколько примеров.

Интеграция ShellCheck в Vim

Чтобы использовать ShellCheck в качестве линтера непосредственно в Vim, сначала нужно установить плагин линтинга.

Одним из самых популярных и современных вариантов на момент написания статьи является ALE.

Плагин использует асинхронные возможности Neovim и Vim >= 8.

Есть много способов установить его, используя один из многочисленных менеджеров плагинов Vim или встроенную систему загрузки плагинов Vim.

После установки плагина Vim linter и ShellCheck мы можем визуализировать предупреждения и предложения прямо из интерфейса редактора!

Интеграция ShellCheck в Visual Studio Code

Visual Studio Code – это текстовый редактор, созданный компанией Microsoft и разработанный с использованием фреймворка Electron.

📜 Как установить VSCode на Kali Linux

Он основан на проекте с открытым исходным кодом Code-OSS и благодаря большой экосистеме плагинов может быть легко превращен в IDE для наиболее используемых языков программирования (Javascript прежде всего).

Для интеграции ShellCheck в Visual Studio Code достаточно найти плагин “shellcheck” прямо в интерфейсе редактора и нажать на кнопку “install”:

ShellCheck также может быть интегрирован в другие текстовые редакторы, такие как Sublime Text и Emacs: инструкции можно найти в специальном разделе README ShellCheck.

🐧 Совместное безопасное использование и управление терминалами в режиме реального времени из веб-браузера

Заключение

В этом руководстве мы рассмотрели, как установить и использовать ShellCheck для отладки и улучшения наших shell-скриптов.

ShellCheck – это инструмент статического анализа, который легко устанавливается во все наиболее используемые дистрибутивы Linux и может использоваться из командной строки или из различных текстовых редакторов с помощью специальных плагинов.

В этом руководстве мы рассмотрели, как использовать ShellCheck в качестве отдельного инструмента из командной строки, а также как интегрировать его в Vim и Visual Studio Code.

см. также:

  • 🔎 Мониторинг использования системных ресурсов Linux с помощью SysMonTask
  • 📜 Перемещение вверх или вниз Vim
  • 🐧 Как изменить цвет комментария в Vim – исправить нечитаемый синий цвет
  • 📜 Как копировать и вставлять строки вставки в vim

Понравилась статья? Поделить с друзьями:
  • Проверка системы на ошибки windows 10 sfc scannow
  • Проверка андроид на ошибки через компьютер
  • Проверка сзв стаж код ошибки 50
  • Проверка авто на ошибки через диагностический разъем
  • Проверка сетевой карты на ошибки