cc @dongcarl

Concept ACK, I'd be happier adding extensions to the scripts or renaming the extension when it's a rare one (e.g. '.bash' => change to '.sh').

The interpreter is meant to be defined in the first line of the script,
not in its extension.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

Rebased c6f7b89 -> 93a7c37 (pr23506.01 -> pr23506.02) due to the conflict with #23462.

Concept ACK! I'm guessing shellcheck does not work with relative paths for the source= directive?

I'm guessing shellcheck does not work with relative paths for the source= directive?

It seems shellcheck tries to resolve them relatively to its own directory.

Concept ACK

and it fixes discovered shellcheck warnings.

What warnings are being fixed here? Looks like it's just updating the source= directives?

and it fixes discovered shellcheck warnings.

What warnings are being fixed here? Looks like it's just updating the source= directives?

For instance:

$ test/lint/lint-shell.sh 

In contrib/guix/guix-attest line 10:
source "$(dirname "${BASH_SOURCE[0]}")/libexec/prelude.bash"
       ^-- SC1091: Not following: libexec/prelude.bash: openBinaryFile: does not exist (No such file or directory)

For more information:
  https://www.shellcheck.net/wiki/SC1091 -- Not following: libexec/prelude.ba...

I mean, "just updating the source= directives" is a fix.

@hebasto Did you look into if it'd be possible to do relative to script path? I'm seeing on the man page that you can use a source-path directive? I'm just thinking it might make it easier if we were to rename directories in the future to not have to touch all the source= directives

Updated 93a7c37 -> a3f6167 (pr23506.02 -> pr23506.03, diff).

Addressed @dongcarl's #23506 (comment):

@hebasto Did you look into if it'd be possible to do relative to script path? I'm seeing on the man page that you can use a source-path directive? I'm just thinking it might make it easier if we were to rename directories in the future to not have to touch all the source= directives

@fanquake

./test/lint/lint-all.sh
....
In contrib/guix/guix-clean line 37:
    path_residue="${2##${1}}"
                       ^--^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.

Did you mean: 
    path_residue="${2##"${1}"}"

For more information:
  https://www.shellcheck.net/wiki/SC2295 -- Expansions inside ${..} need to b...
^---- failure generated from ./test/lint/lint-shell.sh

Looks like you're using shellcheck v0.8.0, while for now

@fanquake Please consider #23635.

Code Review ACK a3f6167, this is a good robustness improvement for our shell scripts.

crACK a3f6167

Introduces shellcheck coverage, passes CI - sounds good to me.

Looks like you're using shellcheck v0.8.0, while for now

I don't understand this logic. The whole point of this PR was to start checking these scripts, and fix any issues. An issue was pointed out, and then just ignored, because it was found with a newer version of a tool. If someone found an issue in our C++ code, with a newer version of a sanitizer, we'd hardly ignore that just because we weren't using that exact version in our CI.

Looks like you're using shellcheck v0.8.0, while for now

I don't understand this logic.

My assumption was that CI and local environments should be consistent for lint tasks. Otherwise, the local lint task could just fail with default settings. If this assumption is wrong maybe document the correct one?

An issue was pointed out, and then just ignored, because it was found with a newer version of a tool.

No, it was not ignored at all. To address the pointed issue, the #23635 was opened.

@fanquake

Sorry about that. I never ignored your comments before.

I think it was fine to split up the two pulls. And after all it is just the linters, so it shouldn't matter too much if it was split up or not.