allow the expansion of ~ when sourcing files

[travi]

In scripts that I use across multiple systems, I use ~ when referencing my home directory since it is at a different location on each system. However, recent versions have been giving me warnings related to SC1091 even when running as shellcheck -x for files that do exist.

Would it be reasonable to enable shellcheck to follow paths that include ~ like this?

[deryni]

Why ~ instead of $HOME? Which I would imagine shellcheck would handle better.

[travi]

I would be open to that too, but the same problem exists. Shellcheck does not expand $HOME and gives the (very similar) SC1090 warning. This warning was added to shellcheck earlier, which ended up being part of the reason I became more consistent with using ~ instead.

[deryni]

Ah. Sounds like shellcheck should possibly understand ~ in that location as non-constant and get you back to SC1090 then. =)

shellcheck not assuming $HOME is valid for the current environment somewhat unreasonable. It might be nice to have a way to tell shellcheck what the "environment" of the running script will look like for things like this to work though.

[travi]

Sounds reasonable, but I do hope that expanding both ~ and $HOME could be supported as both are valid and I personally think ~ is a bit cleaner.

Also, I've realized that not all of the cases where I use shellcheck are in a shell instance (like the atom plugin, so env vars would not be available directly. I do think that populating the "environment" would be important.

[deryni]

$HOME is unambiguous in its expansion.

~ is a prefix to a number of possible expansions (which isn't a reason not to support the simple expansion this is just a comment).

$HOME also expands in variables where ~ doesn't (and while this doesn't come up much in general it is surprisingly common for people to try and get confused when it doesn't just look on StackOverflow for example).

That being said I'm not sure using either of those in scripts is all that good of an idea. Finding the location of the currently executing script and using that to find bundled scripts seems like a more robust plan to me (and would be something that shellcheck could, I think, easily detect the common idioms for and support but that's not my decision).

[travi]

All good points. I do believe that shellcheck already warns about ~ not expanding in certain circumstances. Probably related: when using $HOME, shellcheck also applies its normal variable rules and recommends things like quoting to prevent word splitting, etc. Using ~ should be able to avoid those steps safely because of the difference in how expansion works, correct?

My primary use case for using either of these is related to my dotfiles where many of the scripts need to be relative to the home directory. However, I version all of the scripts in a separate directory and symlink them from there to the proper location. Because of that, referencing them relative to the home directory definitely simplifies things.

[deryni]

Yes, tilde expansion is implicitly quoted and not subject to field splitting and pathname expansion.

From the spec:

The pathname resulting from tilde expansion shall be treated as if quoted to prevent it being altered by field splitting and pathname expansion.

And yeah, I see why you want to use ~ there instead of $HOME.

[koalaman]

It would be both reasonable and convenient, and source resolution needs more work in general.

However, to postpone any decisions about whether to use shellcheck's HOME or the script's HOME or the user's home dir or whether to support ~foo and ~+ and ~- and whether to account for PATH with ./ as fallback like bash does or PATH with no fallback like dash does, and again which PATH to use, 630f20e just adds a kludge so shellcheck doesn't consider ~/ a static path (just so you'll get a more understandable error message).

Maybe you can add an example config in the script's source dir and use that, or run shellcheck from the dir with the include files you want?

[travi]

I think the change to get the other error reporting was an appropriate step, but I don't understand what you mention about a config? I found some other issues mentioning a ~/.shellcheck file, but don't find any concrete reference to something like that.

Could you expand on how I could do what you are referring to?

[travi]

any chance there is a better recommendation than simply disabling the SC1090 rule for this use case by this point?

[reynoldscem]

@travi Did you ever find a nice way around this? I also want to use shellcheck with my dotfiles (and so refer to things relative to my home).

[travi]

I don't believe so, but it has been a bit of time since I've tried very hard. It looks like i have a mix of switching ~ to $HOME and leaving ~, but disabling SC1090 with a comment. I dislike the fact that I'm not consistent, but I must have lost motivation since there wasn't a supported was to lint for consistently using the "right" way.

Interesting timing with your question though, I also got a notification about a thread I've been following for nvm, which suggests that ~ is faster than $HOME. I haven't done anything to verify the claim, but if true, I'd want to undo any of my changes to use $HOME.

[stdedos]

Maybe you can add an example config in the script's source dir and use that, or run shellcheck from the dir with the include files you want?

Well, an example file could be the Ubuntu's default .bashrc:

...
if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi
...

We can freely argue semantics; but I'd like for it to be "clean cut and working out of the box" without (much) additional changes/configs/lintings.