ShellCheck, a static analysis tool for shell scripts

Overview

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

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.

Screenshot of Vim showing inlined shellcheck feedback.

Screenshot of emacs showing inlined shellcheck feedback.

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:

Services and platforms with third party plugins:

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:

apt-get install shellcheck

On Arch Linux based distros:

pacman -S shellcheck

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

On Gentoo based distros:

emerge --ask shellcheck

On EPEL based distros:

yum -y install epel-release
yum install ShellCheck

On Fedora based distros:

dnf install ShellCheck

On FreeBSD:

pkg install hs-ShellCheck

On macOS (OS X) with Homebrew:

brew install shellcheck

Or with MacPorts:

sudo port install shellcheck

On OpenBSD:

pkg_add shellcheck

On openSUSE

zypper in ShellCheck

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

On Solus:

eopkg install shellcheck

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:

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

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

$ cabal update

Compiling ShellCheck

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

$ cabal 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:

chcp 65001

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:

$ cabal test

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 [email protected]                          # Unquoted [email protected]
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

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

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="[email protected]"                         # 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: [email protected]."    # 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

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
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
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!
Issues
  • False positive SC2030/SC2031 in 0.7.2?

    False positive SC2030/SC2031 in 0.7.2?

    For bugs

    • Rule Id (if any, e.g. SC1000): SC2030/SC2031
    • My shellcheck version (shellcheck --version or "online"): 0.7.2
    • [x] The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2031)
    • [x] I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

    Here's a snippet or screenshot that shows the problem:

    
    #!/bin/bash
    
    test1() {
         echo "Test" | if [[ -n "$LOGFILE" ]]; then tee -a "$LOGFILE"; else cat; fi
    }
    
    test2() {
            echo "ERROR" | tee -a "$LOGFILE"
    }
    

    Here's what shellcheck currently says:

    $ shellcheck myscript
     
    Line 4:
         echo "Test" | if [[ -n "$LOGFILE" ]]; then tee -a "$LOGFILE"; else cat; fi
                                 ^-- SC2030: Modification of LOGFILE is local (to subshell caused by pipeline).
     
    Line 8:
            echo "ERROR" | tee -a "$LOGFILE"
                                   ^-- SC2031: LOGFILE was modified in a subshell. That change might be lost.
    
    
    

    Here's what I wanted or expected to see:

    Nothing as in 0.7.1 shellcheck.

    Everything was ok before last update. Can you check please?

    opened by Stikus 41
  • Use file extension to detect shell

    Use file extension to detect shell

    • Rule Id 2148
    • My shellcheck version 0.5.0:
    • [x] I read the issue's wiki page, e.g. https://github.com/koalaman/shellcheck/wiki/SC2148
    • [x] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

    Why doesn't shellcheck consider the file extension to decide which shell is in play? I couldn't find any issues related to this. I write a lot of bash libraries that have a .bash file extension. I don't have a good reason for a shebang in those files.

    opened by ingydotnet 34
  • SC2230 - command -v is not a direct replacement for which

    SC2230 - command -v is not a direct replacement for which

    For bugs

    • Rule Id (if any, e.g. SC1000): SC2230
    • My shellcheck version (shellcheck --version or "online"): 4.4.7 (latest from git)
    • [X] I tried on shellcheck.net and verified that this is still a problem on the latest commit

    Here's a snippet or screenshot that shows the problem:

    
    #!/bin/sh
    
    which "$0"
    /usr/bin/which "$0"
    command -v "$0"
    
    

    Here's what shellcheck currently says:

    In test.sh line 3: which "$0" ^-- SC2230: which is non-standard. Use builtin 'command -v' instead.

    In test.sh line 4: /usr/bin/which "$0" ^-- SC2230: which is non-standard. Use builtin 'command -v' instead.

    Here's what I wanted or expected to see:

    Because "command -v" does not do the same as which, I would have liked to see nothing. When running the above (from /tmp), I get: /tmp/test.sh /tmp/test.sh ./test.sh

    While "which" may not be standard, it is commonly used to get the full path. At the very least I would like to not get warned when I specifically use the path as in the third command - then it's fairly certain what the user wants, which won't be the common bash alias.

    opened by arth1 25
  • SC1090/SC1091: sourcing should find files relative to script

    SC1090/SC1091: sourcing should find files relative to script

    When using the directive source=foobar.sh, then it seems to look up the source relative to the path shellcheck is being run from. For example, I have the following scripts: foo.sh and foobar.sh in the same directory (for example bar/baz from the project root).

    Suppose there is the following line in foo.sh:

    source "${0%/*}/foobar.sh"
    

    I will get a SC1090 error because shellcheck is unable to resolve the path. I have to do this:

    # shellcheck source bar/baz/foobar.sh
    source "${0%/*}/foobar.sh"
    

    This works, but only if I run the checker from the project root (either by specifying foo/bar/foobar.sh as an input file, or with -x), but not if I run it from anywhere else. There should be a way to tell shellcheck to look for a file relative to the checked file's location, not where shellcheck is run. For example, this way:

    # shellcheck source ./foobar.sh
    source "${0%/*}/foobar.sh"
    
    opened by petersohn 24
  • SC2181 suggests to check exit code directly when I check for several possible values

    SC2181 suggests to check exit code directly when I check for several possible values

    • Rule Id: SC2181
    • My shellcheck version: 0.4.7
    • [x] I tried on shellcheck.net and verified that this is still a problem on the latest commit
    • [ ] It's not reproducible on shellcheck.net, but I think that's because it's an OS, configuration or encoding issue

    Here's a snippet that shows the problem:

    
    #!/usr/bin/env bash
    
    gzip --test "$1"
    if [[ $? -eq 0 || $? -eq 2 ]]
    then
        echo ok
    else
        echo bad
    fi
    

    Here's what shellcheck currently says:

    In shellcheck-issue.sh line 4: if [[ $? -eq 0 || $? -eq 2 ]] ^-- SC2181: Check exit code directly with e.g. 'if mycmd;', not indirectly with $?.

    Here's what I wanted or expected to see:

    Nothing, because the successful operation is not the only exit code I'm testing against. gzip possible exit statuses:

    Exit status is normally 0; if an error occurs, exit status is 1. If a warning occurs, exit status is 2.
    

    I want to test for both normal and warning, i.e. any of 0 and 2. And the remaining exit status - 1 falls into the else conditional path.

    Moreover, shellcheck is silent for

    if $? || [[ $? -eq 2 ]]
    

    that is completely wrong. Since testing the first expression $? actually gets executed and rewrites the gzip exit code value. So that the second [[ $? -eq 2 ]] never matches.

    P.S. Of course, I could test just for exit status 1 in my case, but there could be new exit statues beside 0, 1, 2 in general.

    opened by AleXoundOS 20
  • shellcheck: unable to decommit memory: Invalid argument (0.4.4)

    shellcheck: unable to decommit memory: Invalid argument (0.4.4)

    Howdy,

    I recently upgraded my project to using shellcheck 0.4.4 on travis-ci.org to take advantage of the new global file exclusions (#777). After doing so, shellcheck is throwing lots of errors on my project, with the message: +shellcheck -s sh src/winetricks shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument shellcheck: unable to decommit memory: Invalid argument

    What's interesting is that it only occurs on Linux (Ubuntu): https://travis-ci.org/Winetricks/winetricks/jobs/177866938

    But not OS X with 0.4.5: https://travis-ci.org/Winetricks/winetricks/jobs/177866939

    is this a known issue with 0.4.4? I glanced through the commits between 0.4.4 and 0.4.5, but didn't see anything relevant. Unfortunately, Ubuntu's latest is 0.4.4: https://launchpad.net/ubuntu/+source/shellcheck

    so if it is fixed in 0.4.5, I'd like to know so I can ask Ubuntu to bump it.

    P.S., I hate filing a bug for this since it's a previous version, but I couldn't find an IRC channel to ask about this. Is there one I'm unaware of?

    opened by austin987 20
  • install error 0.4.2

    install error 0.4.2

    I tried to install 0.4.2 on my Ubuntu 14.04.3 x64 and got following errors, any thought what seem to be the issue?

    In-place registering QuickCheck-2.8.1...
    Installing library in /root/.cabal/lib/QuickCheck-2.8.1/ghc-7.6.3
    Registering QuickCheck-2.8.1...
    Installed QuickCheck-2.8.1
    Downloading ShellCheck-0.4.2...
    [1 of 1] Compiling Main             ( /tmp/ShellCheck-0.4.2-23628/ShellCheck-0.4.2/Setup.hs, /tmp/ShellCheck-0.4.2-23628/ShellCheck-0.4.2/dist/setup/Main.o )
    
    /tmp/ShellCheck-0.4.2-23628/ShellCheck-0.4.2/Setup.hs:15:25:
        Module `System.Process' does not export `callCommand'
    Failed to install ShellCheck-0.4.2
    cabal: Error: some packages failed to install:
    ShellCheck-0.4.2 failed during the configure step. The exception was:
    ExitFailure 1
    
    opened by gdbtek 20
  • Regarding shell scripts that are only meant to be source (SC2148)

    Regarding shell scripts that are only meant to be source (SC2148)

    Shellcheck looks to the shebang statement at the beginning of a shell script as one means of determining what language is used. This works well for shell scripts that are meant to be called as an executable.

    However, there are non-executable shell files where the convention is to not include the shebang statement in the file because they are meant to be sourced either by the shell during startup (e.g., bashrc) or because they are part of a shell library.

    These files would benefit from spellcheck but can't be used as they are without including a shebang statement.

    I'd like to propose a directive for this specific case that can specify the language. Something like:

    # shellcheck lang=bash
    

    There are other related issues that have brought up this issue but the suggestions were to fall back to sh #215 or ignore the issue #237. I think it'd be best to allow your users the ability to specify the language type to take advantage of language specific features.

    I recognize that shellcheck -s dialect exists but this doesn't help in the case of vim's syntastic plugin.

    Finally, the lang directive should throw a warning if a shebang is used simultaneously.

    Alternatively, the shebang statement could simply be added to these files but I hesitate here because this is not the convention for source files.

    Thoughts?

    opened by chauncey-garrett 18
  • Feature request: Force bash style ( [[ ... ]] ) testing

    Feature request: Force bash style ( [[ ... ]] ) testing

    For new checks and feature suggestions

    • [x] shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
    • [x] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

    Here's a snippet or screenshot that shows the problem:

    #!/bin/bash
    if [ "$1" == 'b' ]; then
        echo 1
    fi
    

    Here's what shellcheck currently says:

    No issues detected!

    Here's what I wanted or expected to see:

    Warning: use bash style ( [[ ... ]] ) testing for better performance

    opened by andras-tim 18
  • Enhancement Request: add IBM Power Linux Platform (ppc64le) support

    Enhancement Request: add IBM Power Linux Platform (ppc64le) support

    Hi,

    I have looked at this and the code builds and all automated tests pass on ppc64le. Since ppc64le is also a supported architecture in travis. per my current understanding, I believe that this is what is needed here:

    • Create a builder repo. similar to the one at https://github.com/koalaman/aarch64-builder and publish the builder images. I have tried building the code natively on a ppc64le debian:buster image and would like to propose that as an alternative to cross compiling it. Besides, the support that is already in Travis, Power VMs can be made available, if needed to accomplish this.

    • add code to build ppc64le binaries in .compile_binaries: and publish in .prepare_deploy

    • enable support in .travis.yaml

    Most of this seems to be just adoption of the multi-arch workflow that is already in place and should be simple. I am willing to make the necessary code contributions to drive this forward with the community, please provide your inputs and thoughts on this!

    Thank you!

    opened by seth-priya 17
  • Add git-describe (with sha1) as version text to Shellcheck

    Add git-describe (with sha1) as version text to Shellcheck

    Especially with the https://github.com/koalaman/shellcheck/releases/tag/latest build, shellcheck --version returning a version string in the format

    v0.7.2-56-g4e703e5

    would make it much easier to identify from where is the latest release built out of.

    If, for some reason, you prefer the Version: xxx field to have the specific parsing (backwards compatible), add an extra line with that information.

    opened by stdedos 0
  • declare -a foo=( $(cmd) ) - no warning about exit status

    declare -a foo=( $(cmd) ) - no warning about exit status

    declare foo=$(cmd) warns about the exit status being lost.

    declare -a foo=( $(cmd) ) should behave the same.

    opened by IsaacG 0
  • find / with rm -rf does produce warning

    find / with rm -rf does produce warning

    For bugs

    • My shellcheck version : online
    • [x] I tried on shellcheck.net and verified that this is still a problem on the latest commit
    • [ ] It's not reproducible on shellcheck.net, but I think that's because it's an OS, configuration or encoding issue

    For new checks and feature suggestions

    • [x] shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
    • [ ] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

    Here's a snippet or screenshot that shows the problem:

    #!/bin/bash
    
    
    find / -exec rm -rf {} \;
    

    Here's what shellcheck currently says:

    $ shellcheck myscript
    No issues detected!
    
    

    Here's what I wanted or expected to see:

    The above command is equivalent to rm -rf / so it should be treated in that way. Thus, I was expecting a warning message

    opened by harish2704 0
  • Publish Debian based Docker image

    Publish Debian based Docker image

    For new checks and feature suggestions

    • [x] https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this
    • [x] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

    Is there opinions against building and publishing a Debian based docker image? While being a lot larger than Alpine (70 MB vs. 6 MB), it would enable the usage of standard GNU tools.

    The use-case I'm currently thinking of is a CI job that recursively finds all shell files and lints them:

    grep \
      --recursive \
      --exclude-dir .git \
      --extended-regexp \
      --files-with-matches \
      '^#!/bin/(bash|sh|env (bash|sh))' \
      . \
      | xargs shellcheck
    

    Long-form options are not allowed and the option --exclude-dir is not available at all on Alpine's grep, unfortunately.

    There is of course the possibility for us to build our own image, but this seems like a not too uncommon use-case and a shellcheck-debian image would serve as a good option to shellcheck-alpine.

    If no objections to this suggestion I can make a PR.

    opened by carlsmedstad 0
  • SC1004: This backslash+linefeed is literal. Command: sed -e '$a\ ...

    SC1004: This backslash+linefeed is literal. Command: sed -e '$a\ ...

    For bugs

    • Rule Id (if any, e.g. SC1000): SC1004
    • My shellcheck version (shellcheck --version or 'online'): online
    • [x] I tried on shellcheck.net and verified that this is still a problem on the latest commit
    • [ ] It's not reproducible on shellcheck.net, but I think that's because it's an OS, configuration, or encoding issue

    For new checks and feature suggestions

    • [x] shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
    • [ ] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

    Here's a snippet or screenshot that shows the problem:

    #!/bin/bash
    
    FILE=/tmp/test.txt
    
    cat <<-EOF >$FILE
    first
    second
    third
    last line
    EOF
    
    echo 'TEST1 Syntax error 1: after \ should be embedded newline'
    sed -e '$a\1APPEND THIS TO BE THE LAST LINE' < "$FILE"
    
    echo 'TEST2 Syntax error 2: after "a" should be \ and embedded newline'
    sed -e '$a2APPEND THIS TO BE THE LAST LINE' < "$FILE"
    
    echo "TEST3 Correct"
    sed -e '$a\
    APPEND THIS TO BE THE LAST LINE' < "$FILE"
    
    

    Here's what shellcheck currently says:

    Line 20	SC1004: This backslash+linefeed is literal. Break outside single quotes if you just want to break the line.
    

    Here's what I wanted or expected to see:

    1. TEST PROGRAM OUTPUT % sh test.sh

    TEST1 Syntax error 1: after \ should be embedded newline sed: 1: "$a\1APPEND THIS TO BE T ...": extra characters after \ at the end of a command TEST2 Syntax error 2: after "a" should be \ and embedded newline sed: 1: "$a2APPEND THIS TO BE TH ...": command a expects \ followed by text TEST3 Correct first second third last line APPEND THIS TO BE THE LAST LINE %

    2.1 Expectation SC1004 should not rise. The syntax of the TEST3 is correct! Of course, all the tests are related to the sed command and not to the shell.

    TODO: Describe expected/desired output Can not guess b/c this is the first time I use this very useful shellcheck :-)

    opened by HarriL 0
  • Warnings about reading and writing when only reading

    Warnings about reading and writing when only reading

    For bugs

    • Rule Id (if any, e.g. SC1000): SC2094, SC2094
    • My shellcheck version (shellcheck --version or 'online'): online
    • [x] I tried on shellcheck.net and verified that this is still a problem on the latest commit
    • [ ] It's not reproducible on shellcheck.net, but I think that's because it's an OS, configuration or encoding issue

    For new checks and feature suggestions

    • [x] shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
    • [ ] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

    Here's a snippet or screenshot that shows the problem:

    #!/bin/sh
    
    while read -r a; do
            read -r b < file.txt
    done < file.txt
    
    echo "$a" "$b"
    

    Here's what shellcheck currently says:

    Line 4	SC2094: Make sure not to read and write the same file in the same pipeline.
    Line 5	SC2094: Make sure not to read and write the same file in the same pipeline.
    

    Here's what I wanted or expected to see:

    No warning.

    The warning should only show up if there is a mixture of reads/writes. Multiple reads should always be safe. Multiple writes might be safe, I'm not sure about how the flushing behaviors are defined (I doubt they are well defined, so this is probably unsafe).

    opened by sboyd-m 0
  • Detect pipe output from cd or umask (creates a subprocess)

    Detect pipe output from cd or umask (creates a subprocess)

    I was recently bitten by some problems in my code that it would be nice if shellcheck could identify.

    Piping output from a command causes the command to run in a subshell, so piping the output of commands like cd, pushd, popd, or umask causes them to have no effect.

    opened by stevecj 0
  • Directive shortcut to disable a single line

    Directive shortcut to disable a single line

    For new checks and feature suggestions

    • [ X] https://www.shellcheck.net/ (i.e. the latest commit) currently gives no useful warnings about this
    • [ X] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

    I searched for "disable shortcut" and disable=

    Here's a snippet or screenshot that shows the problem:

    
    #!/bin/sh
    
    # shellcheck disable=
    set $WANT_STRING_SPLITTING
    
    

    Here's what shellcheck currently says:

    SC2086 warning

    Here's what I wanted or expected to see:

    No warning


    I use this as an example case because I like this rule so I wouldn't want to globally ignore it. So it would be great if the directive # shellcheck disable= cleared any warnings on the next line. However, I understand that reduces posterity so, alternatively if there were semantics for a reason/label as an identifier, then you could do:

    # shellcheck disable='args'

    and then at the top of the file ,

    # shellcheck disable=SC2086,SC#### when='args'

    I think this can be accomplished without having to change upstream, but in my opinion I think it would be nice syntactic sugar to have coming from the directive parser.

    opened by juliusl 0
  • SC2039: does not trigger for dash (does for POSIX sh)

    SC2039: does not trigger for dash (does for POSIX sh)

    For bugs

    • Rule Id (if any, e.g. SC1000): SC2039
    • My shellcheck version (shellcheck --version or "online"): online and 0.7.1
    • [x] The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
    • [x] I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

    Here's a snippet or screenshot that shows the problem:

    #!/bin/dash
    set -o pipefail
    

    Here's what shellcheck currently says:

    Nothing

    Here's what I wanted or expected to see:

    Line 2:
    set -o pipefail
           ^-- SC3040: In POSIX sh, set option pipefail is undefined.
    

    as it does for

    #!/bin/sh
    set -o pipefail
    

    Discussion

    Although lack of support for set -o pipefail in dash was one of the original motivations in #990, and is noted on the SC3040 wiki page, it appears that set -o pipefail is not currently triggered for dash.

    Note: set -o pipefail has been accepted for POSIX 202x and it is becoming more widely supported (e.g. bash, ksh, zsh, busybox ash, FreeBSD sh - although still not dash as of July 2020). At some point it may be worth limiting SC3040 to only shells known to lack support.

    Thanks for considering, Kevin

    opened by kevinoid 0
  • Show info about `set -e` being ignored in process substitutions

    Show info about `set -e` being ignored in process substitutions

    Adds the check mentioned here: https://github.com/koalaman/shellcheck/pull/2303#discussion_r698056295 Example:

    /tmp/a.sh:

    #!/usr/bin/env bash
    set -e
    readarray -t files < <(ls)
    echo "${files[@]}"
    
    % shellcheck /tmp/a.sh --enable=check-set-e-ignored
    
    In /tmp/a.sh line 3:
    readarray -t files < <(ls)
                         ^---^ SC2312: set -e will not cause the script to exit if any command in the process substitution fails. Consider using a command substitution or FIFO.
    
    For more information:
      https://www.shellcheck.net/wiki/SC2312 -- set -e will not cause the script ...
    
    opened by DoxasticFox 3
Releases(v0.7.2)
The user-friendly command line shell.

fish - the friendly interactive shell fish is a smart and user-friendly command line shell for macOS, Linux, and the rest of the family. fish includes

The user-friendly shell 17.4k Sep 17, 2021
Git Extensions is a standalone UI tool for managing git repositories. It also integrates with Windows Explorer and Microsoft Visual Studio (2015/2017/2019).

Git Extensions Git Extensions is a standalone UI tool for managing git repositories. It also integrates with Windows Explorer and Microsoft Visual Stu

Git Extensions 5.8k Sep 23, 2021
Code beautifier

Uncrustify A source code beautifier for C, C++, C#, ObjectiveC, D, Java, Pawn and VALA Features Highly configurable - 742 configurable options as of v

null 2.4k Sep 15, 2021
instant coding answers via the command line (howdoi in rust)

hors Awesome program howdoi which implemented in rust, along with easily usage lib. It's faster than the original howdoi program. For binary usage, pl

null 195 Aug 19, 2021
The Fish Shell Framework

The Fishshell Framework Oh My Fish provides core infrastructure to allow you to install packages which extend or modify the look of your shell. It's f

Oh My Fish! 7.7k Sep 25, 2021
A plugin manager for Fish.

Fisher A plugin manager for Fish—the friendly interactive shell. Manage functions, completions, bindings, and snippets from the command line. Extend y

Jorge Bucaran 5.1k Sep 15, 2021
A plugin to make programming the arduino in eclipse easy

Sloeber, the Arduino IDE for Eclipse The Eclipse IDE (Integrated Developement Environment) is a full featured programming editor with many fantastic f

Sloeber - The Eclipse Arduino IDE 364 Sep 15, 2021
A cross-platform Qt IDE

Qt Creator Qt Creator is a cross-platform, integrated development environment (IDE) for application developers to create applications for multiple des

Qt Creator 1.6k Sep 10, 2021
git-cola: The highly caffeinated Git GUI

git-cola: The highly caffeinated Git GUI git-cola is a powerful Git GUI with a slick and intuitive user interface. Copyright (C) 2007-2020, David Agu

git-cola 1.7k Sep 18, 2021
Gaphor is the simple modeling tool

Gaphor Gaphor is a UML and SysML modeling application written in Python. It is designed to be easy to use, while still being powerful. Gaphor implemen

Gaphor 513 Sep 20, 2021
IntelliJ IDEA Community Edition & IntelliJ Platform

IntelliJ IDEA Community Edition These instructions will help you build IntelliJ IDEA Community Edition from source code, which is the basis for Intell

JetBrains 12.6k Sep 17, 2021
Sourcetrail - free and open-source interactive source explorer

Sourcetrail Sourcetrail is a free and open-source cross-platform source explorer that helps you get productive on unfamiliar source code. Windows: Lin

Coati Software 11.9k Sep 15, 2021
The Pencil Project's unique mission is to build a free and opensource tool for making diagrams and GUI prototyping that everyone can use.

About The Next Version Pencil V3 is a rewrite of Pencil that aims to fix major performance and scalability issues of the application. The new version

Evolus Vietnam 8.2k Sep 13, 2021
A colour picker app for Ubuntu and Linux which allows picking any colour on the screen

Pick A colour picker app for Ubuntu and Linux which allows picking any colour on the screen and remembers the last few you picked. Made with ?? for Bu

Stuart Langridge 232 Aug 22, 2021
Vagrant is a tool for building and distributing development environments.

Vagrant Website: https://www.vagrantup.com/ Source: https://github.com/hashicorp/vagrant HashiCorp Discuss: https://discuss.hashicorp.com/c/vagrant/24

HashiCorp 22.6k Sep 15, 2021
Simple collaboration from your desktop

GitHub Desktop GitHub Desktop is an open source Electron-based GitHub app. It is written in TypeScript and uses React. Where can I get it? Download th

GitHub Desktop 12.9k Sep 15, 2021
A feature-rich WinForms-based HTTP client

User Guide | Downloads | Release Notes | Issues I'm Only Resting is a feature-rich WinForms-based HTTP client that makes building and managing HTTP re

Swensen Software 157 Sep 10, 2021
Official repository for IPython itself. Other repos in the IPython organization contain things like the website, documentation builds, etc.

IPython: Productive Interactive Computing Overview Welcome to IPython. Our full documentation is available on ipython.readthedocs.io and contains info

IPython 15k Sep 15, 2021