if it needs to be safe, use python. please don't down vote me
Safe bash is what Perl was invented for. Don't downvote me.
someday i might even add it to my toolkit
Safe ways to do things in bash
101–110 of 255 posts
Re: Safe ways to do things in bash
#102if 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.
Yes, Python is a general purpose language; however it has powerful libraries to safely interact with command line utilities. The main drawback is their verbosity. But you get a lot in the exchange. For small scripts of a few hundred lines, bash (or some equivalent) is the way to go. But anything more than that, you need something like python or perl (in my opinion, of course)
Re: Safe ways to do things in bash
#103From the article: > Should I use curly braces? Bad: some_command $arg1 $arg2 $arg3 Extra bad (cargo culting unnecessary braces): some_command ${arg1} ${arg2} ${arg3} Correct: some_command "${arg1}" "${arg2}" "${arg3}" Better: some_command "$arg1" "$arg2" "$arg3" > In the "extra bad" and "correct" examples, braces compete with quotes under the limits of tolerable verbosity. > Shellharden will rewrite all these variant…
> You are source controlling your shell scripts right? My personal heuristic for shell scripts are that if I care enough about them to put them under source control, they shouldn't be a shell script.
My sequence is wiki steps, script, shebang (better scripting language), application. Every step is under version control of some form or other.
The shell script is just locking down some sequential command line interaction into something less error prone.
Re: Safe ways to do things in bash
#104Interesting stuff, but given bash's - Relative unportability - Poor noncompliant sh interpreter - Poor performance (can be 4x slower than POSIX sh shells like dash for certain tasks) I personally think bash is always the wrong choice. Use POSIX sh (or a real language). POSIX sh is 98% the same thing, there's no good reason to even use bash over sh in the vast majority of cases. It's just this blight that won't go awa…
[[ alone is reason enough to prefer bash over sh on teams where you inevitably have non-experts making changes. Safe Bash is hard to teach, posix is far harder.
Re: Safe ways to do things in bash
#105I always think — when a programming/scripting language requires this much bizarre knowledge just to write basic code that performs basic tasks, perhaps it is time for that language to be retired. I really don't understand why bash still exists. I've switched to fish and am much happier with the change.
Because it is ubiquitous. You can virtually guarantee that bash will be found on any arbitrary unix-like system.
[deleted]
Re: Safe ways to do things in bash
#106[deleted]
Re: Safe ways to do things in bash
#107Earlier quoted context omitted.
My personal experience would disagree, and I feel that is throwing caution to the wind. As any software person knows, you really can't tell what's going to happen to the code/scripts you put out, not committing it to source control is a dangerous game to play. If you have a simple shell script sitting on a server doing some basic task, why would you not have it under source control where it can be viewed by future te…
At that point, you care enough to put it under source control, and it shouldn't be a shell script. That's the entire point of the comment you replied to
And that's a stupid heuristic. Simple bash scripts can be critical to a processing pipeline while still being the best tool for the job.
Re: Safe ways to do things in bash
#108I always think — when a programming/scripting language requires this much bizarre knowledge just to write basic code that performs basic tasks, perhaps it is time for that language to be retired. I really don't understand why bash still exists. I've switched to fish and am much happier with the change.
Because it is ubiquitous. You can virtually guarantee that bash will be found on any arbitrary unix-like system.
Same reason I always cook my eggs using a shoe.
Re: Safe ways to do things in bash
#109Shellcheck made me a MUCH better Bash developer. Also, I prefer using [ condition ] for tests instead of the less-portable [[ cond ]] syntax despite the latter being more feature-rich. Didn’t see that one in there.
Why do you prefer the former?
Re: Safe ways to do things in bash
#110Interesting stuff, but given bash's - Relative unportability - Poor noncompliant sh interpreter - Poor performance (can be 4x slower than POSIX sh shells like dash for certain tasks) I personally think bash is always the wrong choice. Use POSIX sh (or a real language). POSIX sh is 98% the same thing, there's no good reason to even use bash over sh in the vast majority of cases. It's just this blight that won't go awa…
I stick with bash to avoid implementation differences due to POSIX ambiguity [0]. I know that all my bash scripts will run on at least bash-4.0 but I have no idea what shell /bin/sh is going to be for any given system. I haven't written a single shell script where the performance difference matters, nor do I expect to. And there are a few nice bashisms besides arrays. I'm not sure what portability issues you're referring to.