You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related issues exist, but I haven't found the same.
Consider this code:
#!/bin/bash
. my_script.sh
To keep things simple, let's assume there is no my_script.sh in directories listed in $PATH.
By default, ShellCheck issues SC1091 (info): Not following: my_script.sh was not specified as input (see shellcheck -x). If I use the -x switch, ShellCheck happily follows the script, provided it exists in the current directory. I believe this behavior is bad. The bash manual tells us on source (or .):
(...) When bash is not in posix mode, the current directory is searched if no file is found in PATH. (...)
I conclude that:
ShellCheck should not follow the sourced script, because it cannot know what the current directory will be when the primary script is executed.
Sourcing a script with a relative path is generally a bad idea, and so ShellCheck should issue a warning like this: Path of sourced file is relative to $PATH or the current directory.
By the way, an extreme example of incorrect sourcing was my attempt at nested sourcing of scripts named common.sh in several directory levels. I wanted each script (except for the top level) to source the script in the parent directory, and so I wrote:
. ../common.sh
The result was a segfault, because the second script indefinitely sourced itself. This fatal error was not detected by ShellCheck.
In contrast, consider this code:
#!/bin/bash
. ~/my_script.sh
Unlike the previous case, this code is pretty specific in what script is to be sourced. Yet ShellCheck says: SC1090 (warning): ShellCheck can't follow non-constant source. Use a directive to specify location.
This problem was already reported as Issue #507, but you seem to have closed it without resolving it.
I admit that ~ is generally non-constant, as the script might be used by different users. However, users typically write scripts for themselves, and so I think ShellCheck should follow the script if the -x option is used.
Lastly, I'd like to use this opportunity to say thank you for ShellCheck. It's an incredible piece of software, which is not only very useful, but often seems to be smarter than I am. The issue I'm reporting is the first major problem I've encountered.
The text was updated successfully, but these errors were encountered:
I'm using version 0.8.0, but:
Related issues exist, but I haven't found the same.
Consider this code:
To keep things simple, let's assume there is no
my_script.sh
in directories listed in$PATH
.By default, ShellCheck issues SC1091 (info): Not following: my_script.sh was not specified as input (see shellcheck -x). If I use the
-x
switch, ShellCheck happily follows the script, provided it exists in the current directory. I believe this behavior is bad. The bash manual tells us onsource
(or.
):I conclude that:
By the way, an extreme example of incorrect sourcing was my attempt at nested sourcing of scripts named
common.sh
in several directory levels. I wanted each script (except for the top level) to source the script in the parent directory, and so I wrote:The result was a segfault, because the second script indefinitely sourced itself. This fatal error was not detected by ShellCheck.
In contrast, consider this code:
Unlike the previous case, this code is pretty specific in what script is to be sourced. Yet ShellCheck says: SC1090 (warning): ShellCheck can't follow non-constant source. Use a directive to specify location.
This problem was already reported as Issue #507, but you seem to have closed it without resolving it.
I admit that
~
is generally non-constant, as the script might be used by different users. However, users typically write scripts for themselves, and so I think ShellCheck should follow the script if the-x
option is used.Lastly, I'd like to use this opportunity to say thank you for ShellCheck. It's an incredible piece of software, which is not only very useful, but often seems to be smarter than I am. The issue I'm reporting is the first major problem I've encountered.
The text was updated successfully, but these errors were encountered: