VSCode-Portable Updater (MSYS2)

It's a pretty nice script, I like it. Special thanks for checking the script with shellcheck!

Check for requirements early

The program depends on some non-standard tools such as jq. It's good to check early in the script if the required tools actually exist and fail early with a clear message, rather letting the program crash later due to the missing tool, and without a helpful message.

Check if a file is empty using [[ -s path/to/file ]]

I don't have MSYS at hand to verify, but this should not work:

if [[ $(wc -l "$checkres") = 0 ]]; then

The issue is that when invoked as wc -l path/to/file, the output is formatted as " <path/to/file>", so the condition will never be true.

To get just the count from wc without the path, you could invoke it as wc -l < path/to/file (notice the input redirection):

if [[ $(wc -l < "$checkres") = 0 ]]; then

But since you don't actually need to count lines, you just want to know if the file is empty or not, you could use the test -s builtin:

if ! [[ -s "$checkres" ]]; then

Use the exit code of grep to check if match was found

Instead of Command Substitution with $(...), counting lines and a numeric comparison like this:

if [[ $(ps -eW | grep -c "Code.exe") -gt 0 ]]; then

It's better to use the exit code of grep to check if a match was found or not:

if ps -eW | grep -q "Code.exe"; then

Note that this is especially useful in combination with the -q flag of grep, which makes it stop searching in the input as soon as it found a match.

An aside, in many systems this command would also match the grep command itself. A common workaround is to make the expression to match a pattern:

if ps -eW | grep -q "[C]ode.exe"; then

Get raw values from jq output using -r

This is hacky and inefficient way to strip the enclosing double-quotes from values in the output of jq, using multiple processes:

uver=$(jq .version "$checkres" | cut -c 2- | rev | cut -c 3- | rev)

A much simpler solution is possible thanks to the -r or --raw-output flag:

uver=$(jq -r .version "$checkres")

Use better variable names

I find the script hard to read because the variable names are a bit cryptic. I recommend to rename them so they describe better their purpose, for example:

• lnam -> current_version_name
• lver -> current_version_hash
• unam, uver -> like lnam, lver
• upsum -> expected_checksum
• acsum -> actual_checksum
• ... really, all the variables...

A simpler way to read the first two lines from a command

Instead of:

lver=$(code --version | head -n 2 | tail -n 1)
lnam=$(code --version | head -n 1)

You could use read:

{ read -r lnam; read -r lver; } < <(code --version)

Alternatively, using an array:

version_info=($(code --version))
lnam=${version_info[0]}
lver=${version_info[1]}

Exit with non-zero code in case of failures

The script does exit 0 at multiple places when it detects that something is off. The recommended practice is to exit with a non-zero code to signal that the execution was a failure. Using exit 1 is fine solution.

Use set -euo pipefail to fail fast on errors

A common mistake in scripts is forgetting to check that some important command runs successfully, and by default Bash will continue running the rest of the script, which may cause severe harm.

A good simple safeguard is to include set -euo pipefail at the top of the script, which will make Bash abort on the first failure, and also treat referencing unassigned variables as an error, among other things. For more details see help set and man bash.

Minor nits

echo "" is really the same as echo, no need for the empty string parameter.

In a command like curl -s "long url" -o "short value" I prefer to rearrange the terms as curl -s -o "short value" "long url" to keep the most important part of the command visible without horizontal scrolling. If anything important goes at the far right end of a line, there is a higher risk of overlooking it.

instdir, checkdir, and checkres are constants with static values, therefore it's good to group them together at the top of the script.