koalaman
Repos
16
Followers
605
Following
2

ShellCheck, a static analysis tool for shell scripts

30036
1453

The contents on linuxatemyram.com

274
26

Haskell implementation of gzip-compatible `pack` compression from the early 1980s

32
0

The source code for FiniteCurve.com

C
7
0

Events

closed issue
Doesn't recognize BASH_ARGV0

I'm assigning in a bash script the variable BASH_ARGV0, which is the way of modifying the value of $0. Unfortunately, checkshell doesn't recognize it and shows an SC2034 UNUSED VARIABLE. Tested online and with version 0.8.0.

Example code:

#!/bin/bash

# emulate "exec $@" with "source"
BASH_ARGV0=$1
shift
# shellcheck source=/dev/null
source "$0"
  • [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
Created at 3 days ago
issue comment
Support more Bash internal variables

Thanks!

Created at 4 days ago
closed issue
SC2034 false positive on shell-internal variables

Version 0.7.0, using Shellcheck on .bashrc yields false SC2034 positives on lines setting bash-internal variables (eg EXECIGNORE).

Created at 4 days ago

Reflow lists of internal shell variables

No functional changes; this just makes the next few commits cleaner.

Remove duplicate "COPROC" from internal vars list

Recognize more Bash internal variables

  • BASH_ARGV0, introduced in Bash 5.0
  • BASH_COMPAT, 4.3
  • BASH_LOADABLES_PATH, 4.4
  • CHILD_MAX, 4.3
  • EPOCHREALTIME, 5.0
  • EPOCHSECONDS, 5.0
  • EXECIGNORE, 4.4
  • INSIDE_EMACS, 4.4
  • PS0, 4.4
  • READLINE_ARGUMENT, 5.2
  • READLINE_MARK, 5.1
  • SRANDOM, 5.1

Fixes #1780 and #2554.

Add READLINE_POINT to list of variables without spaces

Merge pull request #2581 from larryv/updatebashvars

Support more Bash internal variables

Created at 4 days ago
pull request closed
Support more Bash internal variables

This PR adds support for the following Bash internal variables (fixing at least #1780 and #2554):

It also adds READLINE_POINT to the list of variables without spaces (as far as I can tell, it always has an integer value) and removes a redundant instance of COPROC.

Created at 4 days ago
issue comment
False positive SC2094

Fixed by @DoxasticFox, thanks!

Created at 4 days ago
issue comment
SC2311 shouldn't appear with set -o posix

Fixed by @DoxasticFox, thanks!

Created at 4 days ago
issue comment
Suppress SC2311 with `set -o posix`

Thanks!

Created at 4 days ago
closed issue
SC2311 shouldn't appear with set -o posix

For bugs

  • Rule Id (if any, e.g. SC1000): SC2311
  • My shellcheck version (shellcheck --version or "online"): online
  • [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

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

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

#!/usr/bin/env bash
# shellcheck enable=all

set -e
set -o posix

test_func()
{
  :
}

_test="$(test_func)"

Here's what shellcheck currently says:

SC2311 (info): Bash implicitly disabled set -e for this function invocation because it's inside a command substitution. Add set -e; before it or enable inherit_errexit.

Here's what I wanted or expected to see:

set -o posix has the effect to also enable inherit_errexit, so SC2311 shouldn't appear

Created at 4 days ago

Suppress SC2311 with set -o posix

Merge pull request #2586 from DoxasticFox/issue-2537

Suppress SC2311 with set -o posix

Created at 4 days ago
pull request closed
Suppress SC2311 with `set -o posix`

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

Created at 4 days ago
issue comment
Add `mapfile` to harmless commands for SC2094

Thanks!

Created at 4 days ago

Add mapfile to harmless commands for SC2094

Merge pull request #2588 from DoxasticFox/issue-2563

Add mapfile to harmless commands for SC2094

Created at 4 days ago
closed issue
False positive SC2094
  • SC2094
  • [x] The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2094)
  • [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
mapfile -t foo <foo

Here's what shellcheck currently says:

Make sure not to read and write the same file in the same pipeline. See SC2094.

Here's what I wanted or expected to see:

Nothing 🙂. mapfile creates a variable, not a file.

Created at 4 days ago
pull request closed
Add `mapfile` to harmless commands for SC2094

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

Created at 4 days ago
closed issue
Suggest putting continuation indicators at the start of the 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

Here's a snippet that shows the problem:

#!/usr/bin/env bash
grep … | \
    sed … | \
    cut … || \
    echo …

Here's what shellcheck currently says:

No issues detected!

Here's what I wanted or expected to see:

Put continuation indicators at the start of the line:

grep … \
    | sed … \
    | cut … \
    || echo …

Rationale: It's easier to tell apart the various command separators if they are lined up and separate from other distracting syntax like \. Black does the same thing for Python.

Created at 4 days ago
issue comment
Suggest putting continuation indicators at the start of the line

Check out shfmt which supports both styles (shfmt -bn for the latter), and auto-formats them better than ShellCheck could. For the most part, ShellCheck focuses on issues related to semantics and does not try to arbitrate style.

Created at 4 days ago
issue comment
SC2086 requiring quotes for `$?` et al. again

It's definitely unexpected that the warning is only emitted when the function is not invoked. In this case it was in fact a bug related the ShellCheck's data flow analysis.

ShellCheck examines the flow of the program, and processes any functions as they're invoked with the context they're invoked in. Any uninvoked functions are in a sense dead, but will in practice be invoked later by a sourcing script. Therefore, ShellCheck processes any uninvoked functions with the state the script would be in after exiting.

The bug was that ShellCheck used the wrong state during this processing.

It should have used the initial state plus any modifications made by the script, but instead it only used the modifications. This means that it effectively forgot that shell variables like $BASHPID and $COLUMNS are set whether or not the script assigns them, and $? is one of those. With $? gone, it was assumed to be unknown instead of numeric, causing the issue in uninvoked functions.

This is now fixed, thanks!

(For reminders to quote all variables to account for things like IFS=0, enable quote-safe-variables)

Created at 1 week ago

Include inherited env for DFA of leftover functions (fixes #2560)

Created at 1 week ago
issue comment
Shellcheck v8.0.0 runs out of memory on linux OS for big sh files

Are you running via qemu user emulation by any chance, such as with Docker on macOS/ARM?

Created at 1 week ago
Expired TLS certificate on shellcheck.net

Let's Encrypt certificate for shellcheck.net and www.shellcheck.net expired on the 18th of September, 2022. Screenshot from 2022-09-19 11-02-33

Created at 1 week ago
issue comment
Expired TLS certificate on shellcheck.net

Fixed, thanks

Created at 1 week ago
issue comment
Certificate expiry for shellcheck.net

Blerk, previous automation attempt didn't work and I missed the emails. Should be good now.

Created at 1 week ago
closed issue
Incorrectly parsing escaped script

For bugs

  • Rule Id (if any, e.g. SC1000): SC1010, SC1010
  • 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

        ssh root@server set -eu\; data=\"\$\(some_command\)\"\; \
	  if ! echo \"\$data\" \| json_pp\; then \
	    echo \"JSON format could not be pretty-printed.  Raw JSON:\"\; \
	    echo \"\$data\"\; \
	  fi 2>&1

Here's what shellcheck currently says:

Line 4	SC1010: Use semicolon or linefeed before 'then' (or quote to make it literal).
Line 7	SC1010: Use semicolon or linefeed before 'fi' (or quote to make it literal).

Here's what I wanted or expected to see:

While I can recognize that this is rather complicated with the escaping, I was still hoping shellcheck would be able correctly parse it.

Created at 1 week ago
issue comment
Incorrectly parsing escaped script

ShellCheck is emitting an warning since unquoted, literal then is frequently a bug (a la if true then echo foo fi), but does still parse it correctly.

You could choose to ignore the warning (including permanently in .shellcheckrc if this is a mistake you're unlikely to make), or quote the "then" and "fi" to clarify that you did indeed intend these as literal words to be passed to ssh so that the warning is suppressed.

(You could of course also make the whole thing more readable by using one pair of single quotes instead of 20+ backslashes)

Created at 1 week ago
closed issue
Is shellcheck support security issues on scripts?

Is shellcheck support security issues like fork bomb on scripts ?(and other dangerous commands)

Created at 1 month ago
issue comment
Is shellcheck support security issues on scripts?

ShellCheck aims to detect common correctness issues in shell scripts. Outside of this, it does not aim to determine whether or not a script is safe to run.

Created at 1 month ago
issue comment
Shellcheck says that a function "references arguments" when it only checks if any argument has been passed

There is some logic in excluding $#, but empirically it appears to be pretty rare to check it without then using $@ or $1 based on the result. Is this part of a larger example?

Created at 1 month ago
issue comment
Feature request: Support overriding the current shell dialect

I see the problem, though it's quite niche compared to the refactoring it would take. You can leave the issue open, but I think your best bet is to specify shell=bash and just manually vet the code up until the re-execution line. (Also note that shellcheck -s sh will override both the shebang and the directive in case you'd want to kludge something with head/sed | shellcheck -s sh -)

Created at 1 month ago
closed issue
Nested double quotes inside date format not caught as invalid

For bugs

  • Rule Id (if any, e.g. SC1000):
  • 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
  • [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:

#!/usr/bin/env bash
/bin/bash /home/ubuntu/gitlab_backup.sh 2>&1 | tee -a "/home/ubuntu/backup_logs/$(date +"%Y-%m-%d")_backup_cron.log"; 

Here's what shellcheck currently says:


Here's what I wanted or expected to see:

TODO: Describe expected/desired output

Only found this out after the cron entry failed and I noticed the split.

root@coolserver:~# sudo grep -is root /var/log/{cron*,syslog*}| grep CRON | grep 'gitlab_backup.sh'
/var/log/syslog.1:Aug 11 01:00:01 gitlab1 CRON[4372]: (root) CMD (/bin/bash /home/ubuntu/gitlab_backup.sh 2>&1 | tee -a "/home/ubuntu/backup_logs/$(date +")
root@coolserver:~# 
Created at 1 month ago