Safe ways to do things in bash

Post by rkeene2 » Tue, May 15, 2018, 2:41 AM UTC

dredmorbius wrote: post #56

_kst_ wrote: post #31

Earlier quoted context omitted.

I've worked on systems where env was installed as /bin/env and not as /usr/bin/env . (I think it was SunOS 4.) For that matter, under Termux on Android it's /data/data/com.termux/files/usr/bin/env (but termux has a hack to make normal shebangs work).

Termux rewrites scripts via termux-fix-shebang.

Post by floatingatoll » Tue, May 15, 2018, 2:51 AM UTC

Hello71 wrote: post #96

floatingatoll wrote: post #60

The advice to double-quote everything is an interesting way to circumvent "detailed knowledge may be required". I wish it noted that you can't quote regular expressions, though: $ cat - > foo #!/bin/bash a="BCD" [[ $a =~ .C. ]] && echo 1 [[ $a =~ ".C." ]] && echo 2 ^D $ bash foo 1 $

this is intentional, since you can store your regular expression in a variable: $ a=BCD; b=.C.; [[ $a =~ $b ]]; echo $?; [[ $a =~ "$b" ]]; echo $? otherwise, interpolating variables in regular expressions as text would require other syntax (more confusing). also, "cat -" is redundant, use "cat". this behavior is specified by POSIX.

Post by theamk » Tue, May 15, 2018, 2:54 AM UTC

TheGrassyKnoll wrote: post #88

p3llin0r3 wrote: post #54

Recently I've replaced most of my bash scripting with the python library invoke. It's written by the same people who wrote the python ssh scripting framework fabric. http://www.pyinvoke.org/ Works great!!

I'll have to try that one. I've done a few things with: Python process launching http://amoffat.github.com/sh

Post by geofft » Tue, May 15, 2018, 3:12 AM UTC

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.

    foo () {
        python3 -c 'import sys, foo; print(foo.bar(sys.argv[1:]))' "$@"
    }

    a="$(foo "$baz" "$quux")"

Post by freedomben » Tue, May 15, 2018, 3:33 AM UTC

aequitas wrote: post #9

nodesocket wrote: post #3

Highly 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

Not only does it make suggestions, almost all of the 'error codes' have extensive documentation on why something is wrong and often multiple alternative solutions for each use case (eg: https://github.com/koalaman/shellcheck/wiki/SC2086 ). I learned more bash from Shellcheck than all tutorials and references combined.