WIP - Improvements to bash code w/ test suite #2810
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This style is preferred as it makes it possible to use more modern bash on systems where /bin/bash is ancient. (looking at you, macos)
`set -u` guards against using unassinged vars but most of this code would break. We'll address this later on a file by file basis, with tests.
The first test is to apply shellcheck linting to the bash code. The following commits will address the linting errors found here.
The `[` is just a command with args and expects/ignores the `]` final arg. That means you need to be very concerned about what's inside `[ ... ]`. The `[[ ... ]]` is Bash syntax and everything inside is handled as syntax. That means you don't need to quotes variable expansions. Bash knows what you want and does it properly. Some related changes were made in this context: * [[ $foo ]] same as [[ -n $foo ]] same as [[ $foo != "" ]] * [[ -z $foo ]] same as [[ $foo == "" ]] * Prefer == over = for string equality * Prefer -eq over == for numeric equality * $* means all aregs expanded into 1 string * Words without meta chars are strings in Bash. No need to quote them. Note: the RHS of a == or != op must be quoted if it is a variable expansion, but shellcheck would complain if you didn't quote it. All the files are still shellcheck compliant. Very confident of this commit.
(in lein and bump) Added a couple tests but need more rigorous testing to make sure everything works without error.
In Bash `foo=$bar` or `foo=$( bar $baz )` is smart about parsing and doesn't blindly expand vars with spaces or meta chars. Arguments with expansions, on the other hand, need quoting. Preferred to only use double quotes when expansions are present. Else use single quotes.
Makes code cleaner and easier to read. Makes it obvious when things are going to stdout or stderr. Note: `printf` repeats its pattern until all args are consumed, so the `msg` function will print a line for each arg.
Unlike vars, functions in bash can contain most of the chars found in file names, which makes sense as a command can either be a function or a PATH command. A Lisper should like it.
Note: you can end a line with && || or | and it will continue without using \.
command is a bash builtin
Syntax available since bash 3.2
$(dirname "$SCRIPT"$) makes not sense to me. Surprised it's not a bash syntax error though
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a set of improvements to the bash code for leiningen.
It's a work in progress and will take some time to complete.
The PR includes a test suite that can be run with: