Live data from Hacker News

How to do things safely in Bash (2018)

github.com

21–30 of 98 posts

Re: How to do things safely in Bash (2018)

#21

I've been shell scripting intermittently for a long time and have written some bash scripts that have seen a lot of use. This document really showed me how bad some of my programming is. But then again, the first thing I tell people when demonstrating one of these programs: "I am not a programmer. I am a bash scripter. And, a bad one." The stuff still works. But I would feel a lot better if I were doing things the ri…

Shellcheck helped me learn a lot about bash.

https://www.shellcheck.net/

Re: How to do things safely in Bash (2018)

#24
I personally have found that AWK is a surprisingly good alternative to shells for scripts bigger than average.

Why?

1. Portability (AWK is a part of POSIX)

2. Very clean syntax

3. Powerful associative arrays

4. Super-powerful string manipulations facilities

5. Easy shell interoperability

As an example here is a simplistic build tool [1] I’ve developed in AWK. As you can check [2] it runs unchanged under Linux/macOS/Win (via Git Bash).

[1] https://github.com/xonixx/makesure/blob/main/makesure.awk

[2] https://github.com/xonixx/makesure/actions/runs/702594092

Re: How to do things safely in Bash (2018)

#25
post #15

When calling shell from bash (to use pipes etc.), I found it useful to pass variables via the environment, like this: def safe_call(command, **keywds): return subprocess.check_call(f'set -euo pipefail; {command}', shell=True, env=keywds) safe_call('command1 -- "$bar" | command2 --baz="$baz" | command3 > "$output_file"', bar=bar, baz=baz, output_file=output_file)

The main difficulty I have with this method is that I don't have an easy way to pass a Python array to bash as an array of parameters.

Re: How to do things safely in Bash (2018)

#26

I've recently taken to not bothering with shell scripts at all. I just use Python instead. The type system, while it's by no means state of the art, is still miles ahead of the stringly-typed bash. The libraries are excellent; much can be done with the standard library alone. The scripts are much faster (even though the language isn't particularly tuned for performance), since I don't need to spawn a subprocess for e…

Same. I feel like I spend 45 minutes every time I write a shell script to determine simple things like "is this environment variable set". Stack Overflow always has 100 answers on how to do this, and every one has someone replying "well that doesn't work if..."

In general, after 20 years of using Unix, I'm starting to sour on the "everything is a string" and "streams are just newline separated plain-text records". The shell is a pretty good REPL, and glue like seq, find, xargs, grep, etc. are very good. But honestly, I find myself reaching for purpose-built tools rather than ad-hoc pipelines more and more. fdfind does more of what I want on average than find; rg does more of what I want than 'find | xargs grep'. I also find myself using more and more structured data, and write more jq pipelines than I do bash pipelines. Finally, I am getting more and more frustrated at basic shell mechanics like history handling. I have 5 terminals open on average, and I don't understand why C-r in one won't find history in another (I know why, of course, but I don't like it). I'm getting pretty close to just writing my own shell and toolchain. I feel like if the Unix shell needed to be fundamentally reimagined, someone would have already done it. But they haven't. They just hacked Unicode and remote RPCs into shell prompts so that pressing "enter" on an empty shell prompt takes 25 seconds to run. I'm not sure why people are so focused on the polish and not the core inadequacies, but they are, and I feel like I'm going to have to fix that myself in the next couple years...

Re: How to do things safely in Bash (2018)

#27
post #6

The fact that you have to use quoting nearly everywhere is a design flaw in the Borne shell. Some shells, like Plan 9's rc, for example, don't expand after variable substantiation. They have an operator to call if you want to explicitly force expansion. That's so much cleaner and less error prone.

> The fact that you have to use quoting nearly everywhere is a design flaw in the Borne shell

I disagree. This can be considered a design flaw in other places, like filesystems that allow filenames with spaces and other idiotic complexity-inducing things.

Re: How to do things safely in Bash (2018)

#28
If you're gonna Bash, definitely use shellcheck for everything. If you're writing Bash in vim, I'd highly recommend installing Syntastic and enabling the checker below:

``` let g:syntastic_sh_checkers = ["shellcheck", "-e", "SC1090"] ```

Re: How to do things safely in Bash (2018)

#29

I think the best way to write things safely is to not write them in Bash in the first place. Better pick a strongly typed language of your choice.

How many strongly typed languages are: + Installed everywhere + Even within 20% as concise as bash

Indeed. Python does not win over bash in either category, and it is slower.

I wish there was a super-fast shell-like scripting language everywhere that could serve as a general programming language. Like Perl, but simpler rules and readable syntax. But there is nothing. Who would have thought, I may have to learn Perl eventually.

Re: How to do things safely in Bash (2018)

#30

I've recently taken to not bothering with shell scripts at all. I just use Python instead. The type system, while it's by no means state of the art, is still miles ahead of the stringly-typed bash. The libraries are excellent; much can be done with the standard library alone. The scripts are much faster (even though the language isn't particularly tuned for performance), since I don't need to spawn a subprocess for e…

This, and I mean very specifically this with python always as the go-to replacement, comes up every single time anyone even utters the words "shell" or "bash" and every time all I can think is that the people saying it aren't writing the same kinds of shell scripts I ever see, use, or wind up writing. And every time I've ever seen something that's allegedly "a shell script replaced with a python script" it's way more…

Hum, no those people are probably writing the same kind of script you do. Their Python versions are indeed longer and more verbose.

I always recommend Python anyway if you care about edge cases (what is not always). That longer script handles them on the obvious way, while the short and more readable shell script does something absolutely crazy every time a detail is different from planed. And if you try to correctly handle the edge cases in Bash (you'll fail), you'll get something much more complicated than the Python version anyway.

Post reply on HN