if [ ${#array[@]} -gt 0 ]; then
if (( ${#array[@]} > 0 )); thenSafe ways to do things in bash
61–70 of 255 posts
Re: Safe ways to do things in bash
#62Highly recommend shellcheck[1]. There is a SublimeLinter plugin[2] that automatically checks your shell scripts as you code them. It generally makes best practice suggestions including quoting. [1] https://github.com/koalaman/shellcheck [2] https://github.com/SublimeLinter/SublimeLinter-shellcheck
Seconding this. Shellcheck is fucking amazing and whenever I visit the wiki page for a specific issue it's extremely descriptive and helps you understand why the flagged behavior is a problem.
Some of the tips are obscure stuff that I never would have realized, like using `command -v` instead of `which` in my (arch) linux install script because command -v is more portable.
And then you have the classic stuff like printf instead of echo -e, using pritnf string formatting, writing `\\n` instead of `\n`, double quoting variables etc
Re: Safe ways to do things in bash
#63Earlier quoted context omitted.
Honest question: what happens when the variable has a quote in it? If FOO is ‹xyz"; rm -r *; "xyz› (where I've used ‹› as delimiters) then won't even "${FOO}" expand to multiple arguments/commands? Or does bash automatically escape the quotes in the situation?
Quotes that arise from substitutions aren't considered to be quotes. Unfortunately, the way GNU Bash handles this sort of requirement is to internally translate these protected quotes into some character that "nobody" would ever use, and then recover them later. That characters code is none other than ASCII 1 (SOH/Ctrl-A). It's known by the preprocessor symbol CTLESC in the Bash sources.
jesus christ is nothing sacred
Re: Safe ways to do things in bash
#64How does one properly quote an argument for a command that can contain spaces? For example: parent_dir = "$(basename $dir)" How to quote $dir here? What if it contains spaces or other special characters? That's what I dislike about Bash. Also, always start your scripts with set -e This prevents script from running after error, without any messages though. Also, I always make mistakes when using [ and [[.
You just add quotes around $dir. Bash understands the quotes properly/recursively.
parent_dir = "$(basename "$dir")"Re: Safe ways to do things in bash
#65From the author of "Russian roulette: how to probably not die", "Staying healthy with fast food" and "Self-immolation for dummies". If you need safety don't use Bash.
Amen. Writing bash scripts (I have been programming in Unix since 1985) is an unnatural, fragile, and error prone endeavor. If is more than 5 lines long, I use Perl (which still far from ideal). When an article is almost solely about what not to do, that tells you something.
Re: Safe ways to do things in bash
#66if it needs to be safe, use python. please don't down vote me
I think Python is made for other tasks than shell. Shell programs mainly consist of invocations for external command-line utilities that you can develop and generalize from interactive shell sessions and one-off automation scripts. Python OTOH is a general-purpose programming language.
Re: Safe ways to do things in bash
#67How does one properly quote an argument for a command that can contain spaces? For example: parent_dir = "$(basename $dir)" How to quote $dir here? What if it contains spaces or other special characters? That's what I dislike about Bash. Also, always start your scripts with set -e This prevents script from running after error, without any messages though. Also, I always make mistakes when using [ and [[.
You quote it like this:
parent_dir="$(basename "$dir")"
Re: Safe ways to do things in bash
#68How does one properly quote an argument for a command that can contain spaces? For example: parent_dir = "$(basename $dir)" How to quote $dir here? What if it contains spaces or other special characters? That's what I dislike about Bash. Also, always start your scripts with set -e This prevents script from running after error, without any messages though. Also, I always make mistakes when using [ and [[.
[deleted]
Re: Safe ways to do things in bash
#69I've written a ridiculous amount of shell script in my day, especially when doing "devops" before we had a term like "devops" to describe it. I've fallen in almost every pit bash has. With that background, here is my opinion.
1. This article contains excellent advice and should be starred for later retrieval.
2. Having basic scripting skills will make you a way better programmer. Many times I've done huge refactors and needle-in-hay-stack searches using only shell commands.
3. Shell is the universal language.
4. Bash isn't that bad once you get used to it (seriously. I'll grant you tho that arrays are still nasty ;-) ).
5. Bash is not that dangerous if you follow best practices. Don't be lazy!
6. You will not regret getting really good at shell script. You'll have to take my word for it now because you don't know what you're missing.
Re: Safe ways to do things in bash
#70Bash strikes me as a bit of a mess, as in people threw the kitchen sink into it for 'portability'. Things like being able to open a socket e.g. using the /dev/tcp/ / stuff give me the willies a bit. I lean towards Ruby if it's going to be anything longer than a few lines, or requires anything but the simplest of logic/commands. Otherwise I was always told /bin/sh is likely to be the most portable, so tend to use that…
I've written two network/telnet game-bots in Bash. It's terribly hacky but fun in it's own way. Using the dev tcp trick and arrays and lots of bashisms.