bash scripts: snake-case variables, deduplicate $RANDOM, satisfy LSP #154

Manually merged
Niols merged 5 commits from kiara/fediversity:shellcheck into main 2025-02-19 19:10:16 +01:00
Owner
No description provided.
kiara self-assigned this 2025-02-19 09:45:20 +01:00
kiara changed title from $(git log --pretty=%s | head -n 1) to bash scripts: snake-case variables, deduplicate $RANDOM, satisfy LSP 2025-02-19 09:47:20 +01:00
kiara removed their assignment 2025-02-19 09:47:38 +01:00
@ -12,3 +12,3 @@
readonly node=node051
readonly tmpdir=/tmp/proxmox-provision-$RANDOM$RANDOM
readonly tmpdir=/tmp/proxmox-provision-$RANDOM$

Trailing $

Trailing $
kiara marked this conversation as resolved
fricklerhandwerk left a comment

LGTM

LGTM
kiara force-pushed shellcheck from 7ff57a0518
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 21s
to a0bbfd518f
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 21s
2025-02-19 10:03:55 +01:00
Compare
Niols left a comment

I feel most of what this PR does is making happy a chatty LSP at the cost of human readability.

The three actual changes:

  • remove second $RANDOM
  • add -r to read
  • use snake_case instead of lowercase

seem all fine although not particularly important.

The PR introduces at least two bugs (the die thing and the readonly thing) and there are too many changes for me to be confident that it didn't introduce others. Let's fix those few bugs, then test it the afternoon, @kiara?

I feel most of what this PR does is making happy a chatty LSP at the cost of human readability. The three actual changes: - remove second `$RANDOM` - add `-r` to `read` - use `snake_case` instead of `lowercase` seem all fine although not particularly important. The PR introduces at least two bugs (the `die` thing and the `readonly` thing) and there are too many changes for me to be confident that it didn't introduce others. Let's fix those few bugs, then test it the afternoon, @kiara?
@ -1,17 +1,17 @@
#!/usr/bin/env sh
#!/usr/bin/env bash
Owner

The whole script is POSIX-compliant, so why make it a bash script here?

The whole script is POSIX-compliant, so why make it a bash script here?
Author
Owner

the LSP had it $RANDOM is not POSIX-compliant

the LSP had it `$RANDOM` is not POSIX-compliant
Owner

Oh nice, I learned something today. Still feels a bit sad to turn a whole script to bash, but that now sounds like the thing to do!

Oh nice, I learned something today. Still feels a bit sad to turn a whole script to bash, but that now sounds like the thing to do!
Niols marked this conversation as resolved
@ -12,3 +12,3 @@
readonly node=node051
readonly tmpdir=/tmp/proxmox-provision-$RANDOM$RANDOM
readonly tmpdir=/tmp/proxmox-provision-$RANDOM$
Owner

I put two initially for increased entropy, but I suppose that's overkill and one is more than enough. Without the trailing $ though.

I put two initially for increased entropy, but I suppose that's overkill and one is more than enough. Without the trailing `$` though.
kiara marked this conversation as resolved
@ -49,2 +49,2 @@
die () { printf '\033[31m'; printf "$@"; printf '\033[0m\n'; exit 2; }
die_with_help () { printf '\033[31m'; printf "$@"; printf '\033[0m\n'; help; exit 2; }
die () { printf '\033[31m'; printf "%s" "$@"; printf '\033[0m\n'; exit 2; }
die_with_help () { printf '\033[31m'; printf "%s" "$@"; printf '\033[0m\n'; help; exit 2; }
Owner

No, this is changing the semantics in the wrong way. The goal is precisely to pass the arguments of die to printf directly so that we can do eg. die '%s %d' foo 2. This also risks passing many more arguments to printf. Please revert those two lines.

No, this is changing the semantics in the wrong way. The goal is precisely to pass the arguments of `die` to `printf` directly so that we can do eg. `die '%s %d' foo 2`. This also risks passing many more arguments to `printf`. Please revert those two lines.
kiara marked this conversation as resolved
@ -56,2 +56,2 @@
--username) readonly username=$1; shift ;;
--password) readonly password=$1; shift ;;
--username) readonly username="$1"; shift ;;
--password) readonly password="$1"; shift ;;
Owner

While adding " can in general make things safer and avoids needing global reasoning, adding them here is just useless in all situations; word splitting does not happen in an assignment word. If the suggestion comes from the LSP, this is very wrong.

While adding `"` can in general make things safer and avoids needing global reasoning, adding them here is just useless in all situations; word splitting does not happen in an assignment word. If the suggestion comes from the LSP, this is very wrong.
Owner

Re this one, the handling of the arguments of the readonly built-in seems to differ between Shell implementations. The POSIX standard seems to suggest that word expansion should not happen, but it isn't extremely clear.

More importantly, standard or not, if dash and bash exhibit different behaviours, we should avoid it altogether. Quoting sounds like the right solution here.

Re this one, the handling of the arguments of the `readonly` built-in seems to differ between Shell implementations. The POSIX standard seems to suggest that word expansion should not happen, but it isn't extremely clear. More importantly, standard or not, if `dash` and `bash` exhibit different behaviours, we should avoid it altogether. Quoting sounds like the right solution here.
kiara marked this conversation as resolved
@ -63,3 +63,3 @@
-h|-\?|--help) help; exit 0 ;;
-*) die_with_help 'Unknown argument: `%s`.' "$argument" ;;
-*) die_with_help "Unknown argument: \`\%s\`." "$argument" ;;
Owner

I find this sad.

I find this sad.
Author
Owner

I feel you.
I understand the advice's point about ensuring we do not accidentally hard-code bash-y stuff.
I could instead disable the particular check for this line with a comment.
Would you find that preferable for these cases?

I feel you. I understand the advice's point about ensuring we do not accidentally hard-code bash-y stuff. I could instead disable the particular check for this line with a comment. Would you find that preferable for these cases?
Owner

Is there a risk of something bash-y? I thought the advice was just

oh probably the person won't understand why things are not expanding within `; let me give them a hand

which is fair depending on the LSP's target, I suppose. Also, I didn't notice the first time, but do we need to escape %?

Is there a risk of something bash-y? I thought the advice was just > oh probably the person won't understand why things are not expanding within `` ` ``; let me give them a hand which is fair depending on the LSP's target, I suppose. Also, I didn't notice the first time, but do we need to escape `%`?
Owner

I suppose a compromise that should make your LSP happy while remaining readable is to go for

die_with_help "Unknown argument: '%s'." "$argument"

WDYT?

I suppose a compromise that should make your LSP happy while remaining readable is to go for ```sh die_with_help "Unknown argument: '%s'." "$argument" ``` WDYT?
Author
Owner

apologies for not having come up with that - that one seems much nicer alright!

apologies for not having come up with that - that one seems much nicer alright!
kiara marked this conversation as resolved
@ -74,2 +73,3 @@
{ read -r username; read -r password; } < .proxmox
else
die_with_help 'Required: `--username` and `--password`.\n'
die_with_help "Required: \`--username\` and \`--password\`.\n"
Owner

I find this sad.

I find this sad.
kiara marked this conversation as resolved
@ -105,0 +103,4 @@
readonly ticket
ticket=$(echo "$response" | jq -r .data.ticket)
readonly csrfToken
csrfToken=$(echo "$response" | jq -r .data.CSRFPreventionToken)
Owner

I'm curious where the change comes from. Making this variables read only before writing to them is just not going to work!

I'm curious where the change comes from. Making this variables read only before writing to them is just not going to work!
Owner

Also, if we're going for snake_case, we might as well be consistent and use csrf_token.

Also, if we're going for `snake_case`, we might as well be consistent and use `csrf_token`.
Owner

Just like in Fediversity/Fediversity#154 (comment), I believe this change makes sense. It is still wrong to have the readonly line before the assignment, but we should either

  • put a readonly X after the assignment to X
  • quote the $( ... ) subshell
Just like in https://git.fediversity.eu/Fediversity/Fediversity/pulls/154#issuecomment-4182, I believe this change makes sense. It is still wrong to have the `readonly` line before the assignment, but we should either - put a `readonly X` after the assignment to `X` - quote the `$( ... )` subshell
Author
Owner

thanks for catching the casing inconsistency. i do see some discussion on casing leaning toward snake-case for bash variable names as well, so fair enough. i pushed to reflect that now.

thanks for catching the casing inconsistency. i do see [some discussion](https://unix.stackexchange.com/questions/42847/are-there-naming-conventions-for-variables-in-shell-scripts) on casing leaning toward snake-case for bash variable names as well, so fair enough. i pushed to reflect that now.
Owner

I don't have any particular opinion on casing in Shell. I guess I have seen often snake_case indeed, so maybe that's fairly standard? Either way, it makes sense to try and stick to one style.

I don't have any particular opinion on casing in Shell. I guess I have seen often `snake_case` indeed, so maybe that's fairly standard? Either way, it makes sense to try and stick to one style.
Author
Owner

thanks, looks like i should not have assumed bash to work like TypeScript here.
unfortunately, just quoting the assignment appears not to satisfy the rule (SC2155 Declare and assign separately to avoid masking return values).
i'll put the readonly statements after assignment then, as you suggested.

thanks, looks like i should not have assumed bash to work like TypeScript here. unfortunately, just quoting the assignment appears not to satisfy the rule (SC2155 Declare and assign separately to avoid masking return values). i'll put the `readonly` statements after assignment then, as you suggested.
kiara marked this conversation as resolved
@ -109,3 +111,3 @@
}
release_lock () {
rmdir $tmpdir/lock-$1
rmdir "$tmpdir/lock-$1"
Owner

Now we're entering the realm where adding quotes makes sense for local reasoning. Like we know that $tmpdir and $1 do not contain spaces but that's only with global reasoning. I understand a linter might complain and I guess this might also make us a bit more future proof; let's keep those.

Now we're entering the realm where adding quotes makes sense for local reasoning. Like we know that `$tmpdir` and `$1` do not contain spaces but that's only with global reasoning. I understand a linter might complain and I guess this might also make us a bit more future proof; let's keep those.
kiara marked this conversation as resolved
@ -137,3 +139,3 @@
running) sleep 1 ;;
stopped) break ;;
*) die 'unexpected status: `%s`' "$status" ;;
*) die "unexpected status: \`\%s\`" "$status" ;;
Owner

Also sad.

Also sad.
kiara marked this conversation as resolved
@ -234,3 +236,3 @@
running) sleep 1 ;;
stopped) break ;;
*) printf ' unexpected status: `%s`\n' "$status"; exit 2 ;;
*) printf " unexpected status: \`\%s\`\n" "$status"; exit 2 ;;
Owner

Sad.

Sad.
kiara marked this conversation as resolved
@ -275,2 +277,2 @@
for vmid in $vmids; do
provision_vm $vmid &
for vm_id in $vm_ids; do
provision_vm "$vm_id" &
Owner

This is where we know that $vm_id is safe and never needs to be quoted, because it comes from a for loop, and that's why all the $1 above didn't need to be quoted also.

This is where we know that `$vm_id` is safe and never needs to be quoted, because it comes from a `for` loop, and that's why all the `$1` above didn't need to be quoted also.
Author
Owner

Sure - I don't doubt you had already verified any present behavior.

Now, given LSP hints that may be overly careful, our options seem:

  1. follow the advice after all
  2. add comments to disable given checks for any such lines
  3. add comments to disable specific linting rules in general
  4. ignore the advice, leaving LSP noise in case you would like to get notified of potential issues
  5. improve LSP behavior

in this PR i opted for following the advice - would you prefer another option in cases like this one?

Sure - I don't doubt you had already verified any present behavior. Now, given LSP hints that may be overly careful, our options seem: 1. follow the advice after all 1. add comments to disable given checks for any such lines 1. add comments to disable specific linting rules in general 1. ignore the advice, leaving LSP noise in case you would like to get notified of potential issues 1. improve LSP behavior in this PR i opted for following the advice - would you prefer another option in cases like this one?
Owner

My preference would be 5, but I don't think it would be a good use of our time. I'm just annoyed by the noise and poor quality of Shell tooling, and LSPs in particular. (I spent 5 years of my life writing static and dynamic analysers for Shell, so this is a problem I have at heart!)

Let's try to do 1., follow the advice to reduce LSP noise: some of the LSP suggestions were actually catching interesting things (eg. the readonly stuff), so it would be a shame to drown this under the rest. However, some suggestions are just plain wrong, so these can obviously not make the cut, and I would try to find ways to get around the LSP's suggestions sometimes without hindering readability (eg. with the '..`..`..' thing).

So let's try to fix what needs to be fixed in this PR and merge it!

My preference would be 5, but I don't think it would be a good use of our time. I'm just annoyed by the noise and poor quality of Shell tooling, and LSPs in particular. (I spent 5 years of my life writing static and dynamic analysers for Shell, so this is a problem I have at heart!) Let's try to do 1., follow the advice to reduce LSP noise: some of the LSP suggestions were actually catching interesting things (eg. the `readonly` stuff), so it would be a shame to drown this under the rest. However, some suggestions are just plain wrong, so these can obviously not make the cut, and I would try to find ways to get around the LSP's suggestions sometimes without hindering readability (eg. with the ``'..`..`..'`` thing). So let's try to fix what needs to be fixed in this PR and merge it!
kiara marked this conversation as resolved
@ -1,17 +1,17 @@
#!/usr/bin/env sh
#!/usr/bin/env bash
Owner

Same as other file.

Same as other file.
Niols marked this conversation as resolved
@ -41,2 +41,2 @@
die () { printf '\033[31m'; printf "$@"; printf '\033[0m\n'; exit 2; }
die_with_help () { printf '\033[31m'; printf "$@"; printf '\033[0m\n'; help; exit 2; }
die () { printf '\033[31m'; printf "%s" "$@"; printf '\033[0m\n'; exit 2; }
die_with_help () { printf '\033[31m'; printf "%s" "$@"; printf '\033[0m\n'; help; exit 2; }
Owner

Same as other file.

Same as other file.
kiara marked this conversation as resolved
@ -51,3 +51,3 @@
-h|-\?|--help) help; exit 0 ;;
-*) die_with_help 'Unknown argument: `%s`.' "$argument" ;;
-*) die_with_help "Unknown argument: \`\%s\`." "$argument" ;;
Owner

Sad times.

Sad times.
kiara marked this conversation as resolved
@ -62,2 +61,3 @@
{ read -r username; read -r password; } < .proxmox
else
die_with_help 'Required: `--username` and `--password`.\n'
die_with_help "Required: \`--username\` and \`--password\`.\n"
Owner

Sad times.

Sad times.
kiara marked this conversation as resolved
@ -80,0 +78,4 @@
readonly ticket
ticket=$(echo "$response" | jq -r .data.ticket)
readonly csrfToken
csrfToken=$(echo "$response" | jq -r .data.CSRFPreventionToken)
Owner

Same as other file.

Same as other file.
kiara marked this conversation as resolved
@ -111,3 +113,3 @@
running) sleep 1 ;;
stopped) break ;;
*) die 'unexpected status: `%s`' "$status" ;;
*) die "unexpected status: \`\%s\`" "$status" ;;
Owner

Sad times.

Sad times.
kiara marked this conversation as resolved
kiara force-pushed shellcheck from a0bbfd518f
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 21s
to c1e51e6323
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 9s
/ check-peertube (pull_request) Successful in 21s
2025-02-19 10:31:45 +01:00
Compare
kiara force-pushed shellcheck from c1e51e6323
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 9s
/ check-peertube (pull_request) Successful in 21s
to 89ec24d534
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 20s
2025-02-19 11:33:12 +01:00
Compare
kiara force-pushed shellcheck from 89ec24d534
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 20s
to 3e34200594
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 21s
2025-02-19 11:35:25 +01:00
Compare
kiara force-pushed shellcheck from 3e34200594
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 21s
to 20493966b0
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 21s
2025-02-19 11:38:44 +01:00
Compare
kiara force-pushed shellcheck from 20493966b0
All checks were successful
/ check-pre-commit (pull_request) Successful in 25s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 21s
to eeed642dd4
All checks were successful
/ check-pre-commit (pull_request) Successful in 24s
/ check-website (pull_request) Successful in 12s
/ check-peertube (pull_request) Successful in 20s
2025-02-19 11:44:57 +01:00
Compare
kiara force-pushed shellcheck from eeed642dd4
All checks were successful
/ check-pre-commit (pull_request) Successful in 24s
/ check-website (pull_request) Successful in 12s
/ check-peertube (pull_request) Successful in 20s
to 92a7e66900
All checks were successful
/ check-pre-commit (pull_request) Successful in 26s
/ check-website (pull_request) Successful in 9s
/ check-peertube (pull_request) Successful in 22s
2025-02-19 11:55:25 +01:00
Compare
Author
Owner

@Niols thanks again for all the feedback - let's do that!

@Niols thanks again for all the feedback - let's do that!
kiara force-pushed shellcheck from 92a7e66900
All checks were successful
/ check-pre-commit (pull_request) Successful in 26s
/ check-website (pull_request) Successful in 9s
/ check-peertube (pull_request) Successful in 22s
to 3addd3fd1a
All checks were successful
/ check-pre-commit (pull_request) Successful in 26s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 22s
2025-02-19 12:11:16 +01:00
Compare
Niols force-pushed shellcheck from 3addd3fd1a
All checks were successful
/ check-pre-commit (pull_request) Successful in 26s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 22s
to 1ab3cbe5db
All checks were successful
/ check-pre-commit (pull_request) Successful in 26s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 22s
2025-02-19 18:26:15 +01:00
Compare
Owner

Rebased on current main, tracked down and fixed issues. Now it seems to work fine, I have tested it successfully. @kiara> Happy with the new commits?

Rebased on current `main`, tracked down and fixed issues. Now it seems to work fine, I have tested it successfully. @kiara> Happy with the new commits?
Niols force-pushed shellcheck from 1ab3cbe5db
All checks were successful
/ check-pre-commit (pull_request) Successful in 26s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 22s
to 18a14d29ab
All checks were successful
/ check-pre-commit (pull_request) Successful in 26s
/ check-website (pull_request) Successful in 10s
/ check-peertube (pull_request) Successful in 22s
2025-02-19 18:29:38 +01:00
Compare
Owner

(Rebased again, we merge things fast in this country :p)

(Rebased again, we merge things fast in this country :p)
Author
Owner

@Niols looks great, thank you! 🙈

@Niols looks great, thank you! 🙈
Niols manually merged commit b6e11c893b into main 2025-02-19 19:10:16 +01:00
Sign in to join this conversation.
No reviewers
No milestone
No project
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
fediversity/fediversity!154
No description provided.