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

Shell script best practices, from a decade of scripting things

sharats.me

Post reply on HN
Print view View original

111–120 of 500 posts

Re: Shell script best practices, from a decade of scripting things

#111

Post by bluetomcat »

rethab wrote: post #97
bluetomcat wrote: post #46

Use the shell only if your script is mostly about calling other programs and filtering and redirecting their output. That's what the syntax of these languages is optimised for. As soon as you need any data manipulation (i.e. arrays, computation, etc.) it becomes a pain and Python is the much better fit.

AWK is just fine for data manipulation. And unlike python, you don't need to worry about whether it's installed and in what version.

I see AWK as a general-purpose output filter and aggregator, something like a programmable grep. You read another program's output line by line, and output it filtered and/or summarised. Works nice when the format is known, but in case it isn't, error handling and recovery is not something I would enjoy doing in AWK.

Re: Shell script best practices, from a decade of scripting things

#112

Post by pxtail »

lockedinspace wrote: post #33

This is not a best practices guide, please look forward to: https://mywiki.wooledge.org/BashGuide For example, using cd "$(dirname "$0")" to get the scripts location is not reliable, you could use a more sophisticated option such as: $(dirname $BASH_SOURCE)

And THIS is the primary source of my furious hate in my toxic love-hate relationship with bash. Guy is writing bash FOR 10 FUCKING YEARS and still apparently doing it wrong in 10 letter oneliner.

When it comes to bash search for even simplest command/syntax always ALWAYS leads to stackoverflow thread with 50 answers where bash wizards pull oneliners from sleeves and nitpick and argue about various intricancies

Re: Shell script best practices, from a decade of scripting things

#113

Post by HyperSane »

Beltalowda wrote: post #19

> Use bash. Using zsh or fish or any other, will make it hard for others to understand / collaborate. Among all shells, bash strikes a good balance between portability and DX. I think fish is quite a bit different in terms of syntax and semantics (I'm not very familiar with it), but zsh is essentially the same as bash except without most of the needless footguns and awkwardness. zsh also has many more advanced featur…

sh and bash feel pretty primitive after learning PowerShell.

Re: Shell script best practices, from a decade of scripting things

#114

Post by majkinetor »

HyperSane wrote: post #113
Beltalowda wrote: post #19

> Use bash. Using zsh or fish or any other, will make it hard for others to understand / collaborate. Among all shells, bash strikes a good balance between portability and DX. I think fish is quite a bit different in terms of syntax and semantics (I'm not very familiar with it), but zsh is essentially the same as bash except without most of the needless footguns and awkwardness. zsh also has many more advanced featur…

sh and bash feel pretty primitive after learning PowerShell.

They don't feel primitive, they are primitive.

Re: Shell script best practices, from a decade of scripting things

#115

Post by ognyankulev »

baggiponte wrote: post #13

Nice, but for point 14 I would recommend using pushd/popd instead of cd-ing directly into $0... any reasons to prefer cd directly?

pushd/popd are intended for interactive use, not for use in scripts. It prints the full stack on directories and there is no option to be quiet. Of course, there is always redirecting to /dev/null but it is intentional to not have option to be quiet.

Usually there is no need to return to original directory. Change of directory is process-local (script-local) so the calling process is not affected by this 'cd' in the script.

Re: Shell script best practices, from a decade of scripting things

#116

Post by ndsipa_pomu »

Beltalowda wrote: post #77
ndsipa_pomu wrote: post #67

Earlier quoted context omitted.

The hashbang already specifies the shell, so also having it in the extension seems unnecessary. I don't like using '.sh' as an extension as it differs from other OS commands and I can't think where it's actually helpful.

If you download a script then running "sh script.sh" is a lot quicker and easier than a chmod followed by ./script.sh. You can of course also type "bash script.sh", but I don't always have it installed on every system, and the .bash extension just clarifies it. For things in my PATH I drop any suffixes like that.

I see your point, but you can just as easily run "sh script" although that does imply that you already know that it's a shell script (obviously you wouldn't just run something from the internet without checking it first).

Re: Shell script best practices, from a decade of scripting things

#117

Post by imgabe »

jomar wrote: post #85
imgabe wrote: post #36

Earlier quoted context omitted.

Is there any way to get MacOS to stop nagging you about zsh?

Export $BASH_SILENCE_DEPRECATION_WARNING as described in the Apple web page pointed to by the nag message, or change your shell to your own version of Bash. See also https://apple.stackexchange.com/questions/371997/suppressing... >. I went with the "use an updated brewed Bash" approach, which has been working well. Using `sudo chfn` means you don't need to futz around with editing /etc/shells.

ah, that is lovely. Thank you.

Re: Shell script best practices, from a decade of scripting things

#118

Post by grumblehound »

suprjami wrote: post #55

Use a linter. Pass all scripts through https://www.shellcheck.net/ or use `shellcheck` on the commandline. Learn the things it tells you and implement them in future scripts.

Shellcheck is a godsend. I'm not a linuxy guy but have had to write some bash at work for gitlab pipelines... I was getting very frustrated with it until I found shellcheck and it instantly resolved a lot of annoyances I had. I added it into the pipeline for the repo that holds the CI scripts (using the koalaman/shellcheck-alpine docker image) and installed the VSCode extension locally. Super simple.

Re: Shell script best practices, from a decade of scripting things

#119

Post by lhoursquentin »

dvzk wrote: post #86
jph wrote: post #15

I favor POSIX and dash over bash, because POSIX is more portable. If a shell script needs any kind of functionality beyond POSIX, then that's a good time to upgrade to a higher-structure programming language. Here's my related list of shell script tactics: http://github.com/sixarm/unix-shell-script-tactics

Bash extensions are cool to have in the interpreter. I really don't think we need more than the basic POSIX shell for most scripts. I once wrote a tar replacement in it, with a restricted YAML generator and parser and a state machine — don’t judge me, I think I was manic — and the result was weirdly beautiful.

The lack of arrays, dicts and local variables when trying to be POSIX compliant becomes quickly annoying when writing big programs though. There are of course workarounds to deal with those but I wish we didn't have to use them.

Re: Shell script best practices, from a decade of scripting things

#120

Post by ndsipa_pomu »

suprjami wrote: post #55

Use a linter. Pass all scripts through https://www.shellcheck.net/ or use `shellcheck` on the commandline. Learn the things it tells you and implement them in future scripts.

That should be the zeroth rule of all shell/bash scripting.

I'm almost tempted to put in a self-linting line in scripts so that they won't run unless shellcheck passes completely. (It would be unnecessary to lint the same script every time it's called though, so it's not a serious suggestion).

There should be an option in bash to auto-lint scripts the first time that they're called, but I don't know how the OS should keep track of when the script was last changed and last linted.

Post reply on HN