Safe ways to do things in bash • Hacker News Board

Re: Safe ways to do things in bash

#41

Post by dozzie » Mon, May 14, 2018, 10:55 PM UTC

mehrdadn wrote: post #40

dozzie wrote: post #38

Earlier quoted context omitted.

> The point I'm making here is that it's actually quite difficult to get a string that literally has the contents you want. It's not difficult, it's just tedious. foo=$(whatever). foo=${foo%.}

That's not general POSIX, right? I seem to recall it's Bash-specific? (P.S. I think you forgot quotes?) The other problem (which I guess I accidentally brushed under the rug when I singled out "variables") is that having to do this actually means you need to put it in a variable . If you're nesting subshells, this gets pretty darn tedious, easy to forget about, and difficult to read pretty quickly... it seems you wou…

> That's not general POSIX, right? I seem to recall it's Bash-specific? (P.S. I think you forgot quotes?)

Wrong. (And no, I did not.)

POSIX, or rather SUS (I've never had an access to POSIX), mandates ${foo%...} syntax and its three cousins. And assignment is not subject to word splitting for variable expansion.

Re: Safe ways to do things in bash

#42

Post by tootie » Mon, May 14, 2018, 11:00 PM UTC

jonnycomputer wrote: post #34

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.

Re: Safe ways to do things in bash

#43

Post by oblio » Mon, May 14, 2018, 11:07 PM UTC

dwheeler wrote: post #21

Twisol wrote: post #17

Earlier quoted context omitted.

What's wrong with `#!/usr/bin/env sh`?

POSIX doesn't include shebang (#!) at all. It should , but it currently doesn't.

> currently doesn’t

Yeah, we should be gentle with POSIX, it’s only 30 years young :)

Re: Safe ways to do things in bash

#44

Post by oblio » Mon, May 14, 2018, 11:11 PM UTC

dozzie wrote: post #41

mehrdadn wrote: post #40

Earlier quoted context omitted.

That's not general POSIX, right? I seem to recall it's Bash-specific? (P.S. I think you forgot quotes?) The other problem (which I guess I accidentally brushed under the rug when I singled out "variables") is that having to do this actually means you need to put it in a variable . If you're nesting subshells, this gets pretty darn tedious, easy to forget about, and difficult to read pretty quickly... it seems you wou…

> That's not general POSIX, right? I seem to recall it's Bash-specific? (P.S. I think you forgot quotes?) Wrong. (And no, I did not.) POSIX, or rather SUS (I've never had an access to POSIX), mandates ${foo%...} syntax and its three cousins. And assignment is not subject to word splitting for variable expansion.

Regarding POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...

Re: Safe ways to do things in bash

#45

Post by kazinator » Mon, May 14, 2018, 11:11 PM UTC

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

Re: Safe ways to do things in bash

#46

Post by chubot » Mon, May 14, 2018, 11:15 PM UTC

I don't agree with the advice to use arrays and set -u together. Sometimes you just need to get something done, and being pedantic works against you.

This advice only works in bash 4.4, and many common distros are on bash 4.3, like Ubuntu 16.02 LTS. (bash 4.4 was released September 2016.) Because of this bug, the section "how to begin a bash script" is version-specific and awkward IMO.

If you need to process untrusted filenames, use arrays, but otherwise it's probably more trouble than it's worth. [1]

I want my scripts to work on older versions of bash, and I think 'set -u' is important, so I mostly get by without arrays. It's not ideal, but shell is full of compromises.

A workaround is to use ${a[@]+"${a[@]}"}, which avoids the bug in bash 4.3, but that seems too ugly to recommend.

More details in this comment I wrote on the same article: https://lobste.rs/s/4jegyk/how_do_things_safely_bash#c_kmldw...

[1] Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays http://www.oilshell.org/blog/2016/11/06.html

Re: Safe ways to do things in bash

#47

Post by mehrdadn » Mon, May 14, 2018, 11:15 PM UTC

dozzie wrote: post #41

mehrdadn wrote: post #40

Earlier quoted context omitted.

That's not general POSIX, right? I seem to recall it's Bash-specific? (P.S. I think you forgot quotes?) The other problem (which I guess I accidentally brushed under the rug when I singled out "variables") is that having to do this actually means you need to put it in a variable . If you're nesting subshells, this gets pretty darn tedious, easy to forget about, and difficult to read pretty quickly... it seems you wou…

> That's not general POSIX, right? I seem to recall it's Bash-specific? (P.S. I think you forgot quotes?) Wrong. (And no, I did not.) POSIX, or rather SUS (I've never had an access to POSIX), mandates ${foo%...} syntax and its three cousins. And assignment is not subject to word splitting for variable expansion.

Whoa interesting, thanks! Didn't know that.

Re: Safe ways to do things in bash

#48

Post by kazinator » Mon, May 14, 2018, 11:17 PM UTC

quietbritishjim wrote: post #15

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…

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.

Re: Safe ways to do things in bash

#49

Post by xyzzyz » Mon, May 14, 2018, 11:23 PM UTC

oblio wrote: post #43

dwheeler wrote: post #21

Earlier quoted context omitted.

POSIX doesn't include shebang (#!) at all. It should , but it currently doesn't.

> currently doesn’t Yeah, we should be gentle with POSIX, it’s only 30 years young :)

Newest revision is from 2017, so they certainly had time to fix that, if they consider it a problem.

Re: Safe ways to do things in bash

#50

Post by nunez » Mon, May 14, 2018, 11:23 PM UTC

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