I've read through all of the examples in the article & they all seem to serve to sole purpose of turning readable multiple line code into one-liners.

One-liners are a cool little artifact of early shell culture & are sometimes still useful today if they're short to avoid the readability problems of `/` when copy pasting a quick shell command to run, but they have no place in scripts.

None of this seems useful to me.

> if you are like me and prefer less typing (gotta go fast)

Yeah, no.

▲

brabel 4 hours ago | parent [-]

Bash scripts should only be used for quick and dirty tasks where brevity is a major benefit. Don’t pretend bash can be readable and maintainable. If you want that use another language that sacrifices brevity for clarity.

	▲	lucideer an hour ago \| parent [-]
		First I agree that bash scripts should only be used for quick or small (& ultimately mostly personal unshared) tasks. There's absolutely no need for it to be either "dirty", & as mentioned in my post, brevity has no material benefit in this context. I want my personal local utility/productivity scripts to be readable: quick to write & quick to modify on the fly. Brevity doesn't help here - wpm optimises for natural language typing & that translates better to idiomatic logical block structures than to symbol-heavy one-liners. I also want the same for the small bash snippets in my CI jobs - this is a particular example where brevity is actively bad: this encourages folk to inline their bash snippets in yaml (no syntax highlighting & unlintable) when they should be packaged in script files in CI directories.