Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Safe ways to do things in bash

github.com

Post reply on HN
Print view View original

71–80 of 255 posts

Re: Safe ways to do things in bash

#71

Post by theamk »

If you get to the point when you need to write

    IFS=$'\v' read -d '' -ra a
it is a good sign that it's time to switch to some other language. For example in python, it will be just

    a = s.split("\v")
(and yes, sometime you have legacy system, or writing initrd script. But how often does this happen? Any why does your initrd has full bash anyway, as opposed to dash or sh?)

Re: Safe ways to do things in bash

#72

Post by JauntyHatAngle »

saagarjha wrote: post #14
koolba wrote: post #8

From 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 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 teams and seeing what changes have been made to it over time? Seemingly simple problems can be caused by minor changes which are very visible if its under source control.

Just because its simple doesn't make it any less important. Complexity is not a good measure of its importance.

Especially when you start trying to implement IAC in legacy areas...

Re: Safe ways to do things in bash

#73

Post by codedokode »

zeroimpl wrote: post #64
codedokode wrote: post #59

How 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")"

So I finally found the answer. Thanks.

Re: Safe ways to do things in bash

#74

Post by devhead »

nice write up, starred it for future hand outs to my friends.

I do find that once my bash script is going over a hundred lines or so it's likely a good time to move to python.

I love bash, it's great; at some point setting up a proper script (in bash) with arguments, options, logging and or validation you end up spending more time getting it to work than you do on solving the actual problem; enter your favorite programming language here.

Re: Safe ways to do things in bash

#75

Post by koala_man »

codedokode wrote: post #59

How 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 [[.

$(..) is its own context so you just put double quotes around any variables like you normally would:

    parent_dir="$(basename "$dir")"
[ and [[ can indeed be tricky. You may find ShellCheck useful, since it recognizes common problems like [ a=b ], [-e .bashrc], [ 1 > 2 ], [ -n var ], [ false ] and several others.

Re: Safe ways to do things in bash

#76

Post by koala_man »

kazinator wrote: post #45

> Quoting inhibits both word splitting and wildcard expansion, for variables and command substitutions. The result of a variable substitution isn't subject to wilcard expansion, whether quoted or not. If your only reason to quote "$foo" is because you think foo expands to a globbing pattern, and no other reason is justified, you can drop the quotes.

It is subject to wildcard expansion. You can verify this with

    var="/*"; echo $var

Re: Safe ways to do things in bash

#77

Post by gitgud »

JauntyHatAngle wrote: post #72
saagarjha wrote: post #14

Earlier quoted context omitted.

> 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 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…

I completely agree, source control is not used to track complexity. It's to track changes and the reasons for those changes... however small they may be.

Re: Safe ways to do things in bash

#78

Post by Xcelerate »

I 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.

Re: Safe ways to do things in bash

#79

Post by occams_chainsaw »

JauntyHatAngle wrote: post #72
saagarjha wrote: post #14

Earlier quoted context omitted.

> 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 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

Re: Safe ways to do things in bash

#80

Post by LeoPanthera »

Xcelerate wrote: post #78

I 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.
Post reply on HN