I really love shellharden so far, since that allows me to quickly rewrite scripts that I wrote too hastily :slightly_smiling_face: . But when I ran it on a script I put a lot of effort in, it suggested to remove the braces ({, }), in places that do not strictly need them, which is something I prefer to do.

A variable in bash is like a hand grenade – take off its quotes, and it starts ticking.

For the same reason I prefer to always use the braces. Since I do not know how the line will change in the future.

Would it be possible to make shellharden do this? Perhaps as a configuration option?

A simple example which would have been prevented by always using braces:

my_file='abc.txt'
cp "$my_file"{,_copy}
ls "$my_file"

my_file='abc.txt'
cp "$my_file"{,_copy}
ls "$my_file_copy"  # error, unset variable

Running shellharden erratic-script on macOS (via Homebrew) simply outputs the script as-is. No syntax highlighting or no suggestions. For comparison, shellcheck erratic-script outputs a bunch of errors. What could be wrong?

Hi I just saw your app and if you need a new logo or widget design i can help you You can tell me what kind of a logo do you want I am waiting for you reply

I've grown accustom to not quoting the right hand side of variable assignments,

var=$othervar
var=$(subshell)
var=value

This is perfectly safe in all POSIX shells (AFAIK). Reference.

Shellharden adds quotes to all of these. Do you consider this a bug?

I was wondering why you didn't use Cargo. Is it a matter of choice or it is because you're not comfortable with it?

Furthermore, using Cargo will allow you to publish your project on Crates.io and setup a test suite more easily.

Quoting is generally not needed when variables are used between double brackets ([[ and ]]).

Here is a test case that does not expand:

x='*'; if [[ $x == '*' ]]; then echo not expanded; fi

While with single brackets, this is the result:

x='*'; if [ $x == '*' ]; then echo not expanded; fi
bash: [: too many arguments

shellharden wants to add double quotes around $x in the first case, but this is not really needed.

In reply to https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md#should-i-use-curly-braces :

Correct: some_command "${arg1}" "${arg2}" "${arg3}" Better: some_command "$arg1" "$arg2" "$arg3"

Curly braces should be preferred in order to limit the risk that a variable named a prefix of other variables does not alter other variables. An example:

arg="example"
some_command "$arg1" "$arg2" "$arg3"
some_command "${arg1}" "${arg2}" "${arg3}"

Version 4.1.1 is the most recent release according to https://github.com/anordal/shellharden/releases, but looking at the https://github.com/anordal/shellharden/tags, it looks like there are also 4.1.2, 4.1.3, and 4.2.0?

Is it an oversight that those versions are not "released"?

Pacstall is a community-driven AUR-like package manager for Ubuntu. We have an ongoing pull request to add shellharden to our repository.

We have a few questions for you:

• Would you like to maintain the pacscript (similar to a PKGBUILD) yourself? We can maintain it for you if you decide not to.
• Could you include a section in your documentation showing Pacstall as a valid method of installation for Shellharden for Debian/Ubuntu users? We could make a pull request for that if you want.

@anordal In echo → printf, the guide is trying to make a case that printf should be preferred over echo; however in a lot of other places within the guide (eg. Corollary: Use while loops to iterate strings and command output), echo is being used extensively. Do we want to consolidate the guide and rewrite examples in printf wherever possible?

Hello,

The section on using arrays could really do with an example of using an array in a loop.

https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md#use-arrays-ftw

maybe

xs=(
 a
 b
)
for x in "${xs[@]}" ; do 
 echo "$x"
end

But I did not submit a PR because I am not sure that is actually correct.

Thanks for the great resource!

Brilliant tool. Thanks. I just learned about it today, and I found it hard to figure out exactly what the tool was, or if there were multiple tools without downloading/installing it. I'd like to suggest adding a section to the README.md that shows some example calls, e.g.

$ shellharden script.sh

maybe immediately above each screenshot example.

Another thing that would help people "passing by" could be to add:

# Usage

` ```
$ shellharden --help
Shellharden: The corrective bash syntax highlighter.

Usage:
	shellharden [options] [files]
	cat files | shellharden [options] ''

Shellharden is a syntax highlighter and a tool to semi-automate the rewriting
of scripts to ShellCheck conformance, mainly focused on quoting.

The default mode of operation is like `cat`, but with syntax highlighting in
foreground colors and suggestive changes in background colors.

Options:
	--suggest         Output a colored diff suggesting changes.
	--syntax          Output syntax highlighting with ANSI colors.
	--syntax-suggest  Diff with syntax highlighting (default mode).
	--transform       Output suggested changes.
	--check           No output; exit with 2 if changes are suggested.
	--replace         Replace file contents with suggested changes.
	--                Don't treat further arguments as options.
	-h|--help         Show help text.
	--version         Show version.

The changes suggested by Shellharden inhibits word splitting and indirect
pathname expansion. This will make your script ShellCheck compliant in terms of
quoting. Whether your script will work afterwards is a different question:
If your script was using those features on purpose, it obviously won't anymore!

Every script is possible to write without using word splitting or indirect
pathname expansion, but it may involve doing things differently.
See the accompanying file how_to_do_things_safely_in_bash.md or online:
https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md
` ```

## Usage advice

Don't apply `--transform` blindly; code review is still necessary: A script that relies on unquoted behavior
(implicit word splitting and glob expansion from variables and command substitutions) …

which of course requires more work, since you need to remember to update it whenever --help output changes

Enables a user to run shellharden in a Docker container.

• Add Dockerfile & entrypoint
• Update README.md
  • Add Docker usage
  • Wrap lines to make it easier to read from CLI
  • Correct misc. grammar & punctuation

I did this so I can use it in a CI/CD pipeline, but thought it might be worth contributing back. If you want, I can publish it to docker hub before you accept this PR.

Thanks for such a great tool!

Signed-off-by: Vladislav Doster [email protected]

Hi there!

shellharden looks fantastic, and I was considering integrating it into some lint infrastructure we have. However, it looks like the only stable interface is a binary. Would you consider separating out the checks into a library and providing a Rust API as well?

A bonus would be if you could read files from memory rather than the file system -- perhaps via a trait that specifies how files should be read.

I do something similar for a tool I'm the primary author of, cargo-guppy, where there's both a Rust interface (guppy) and a CLI tool (cargo-guppy).

Thank you!