Shellcheck - статический анализатор, он совместим с atom-linter плагином, что делает его идеальным вариантом.

Сейчас, в 2019 году, я перестал пользоваться Atom и Shellcheck, в угоду Pycharm + BashSupport. Недавно JetBrains добавили поддержку ShellCheck, но мне не горит. В Carbon Soft есть свой анализатор, но он больше в угоду стиля кодирования: crab_syntax.

shellcheck-atom

Писать без статического анализатора на Bash я не рекомендую.

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

Позавчера прошёлся немного с shellcheck по коду своего проекта и был даже в каком-то роде рад - 3-4 основных типа ошибок, ничего серьёзного, видимо опыт сказывается. Основные ошибки, на которые ругался shellcheck:

Ошибка Как было Как надо
Использование переменной в read для отсечения ненужных слов read md5 tmp < file.md5 read md5 _ < file.md5
Передача параметров массивом без кавычек main $@ main "$@" или если аргументы нужны как одна строка main "$*"
Неявное обнуление переменной окружения при запуске команды LANG= join -a 1 -j 1 file1 file2 LANG='' join -a 1 -j 1 file1 file2
Незаковыченные паттерны grep которые могут glob’биться. ip link \| grep br[0-9]* ip link \| grep 'br[0-9]*'

Пример с glob у grep:

touch br01111 broken
set -x
$ ip link | grep br[0-9]*
+ ip link
+ grep --color br01111 broken

Заключение

Считать “я, мол, и так умный” не стоит. Все мы несовершенны.

Ну и “bash - не язык, зачем ему linter” тоже.

Лучше сэкономить себе минут 20 из цикла поиска баги, фикса, отладки, тестов и пересборки/выкладки, просто сразу написав нормально под присмотром линтера. Особенно это полезно начинающим в bash.

Update 2019

Проблема: люди начинают вылизывать код для линтера, тратят много времени, напихивают кучу комментариев “игнорируй такую-то ошибку”, код в итоге выглядит ещё хуже. Более того, иногда в угоду линтеру, делают код более хрупким.