[yamtaddle]

Bash isn't that bad... except there are 20 ways to do anything and 18 of them are wrong, but only 1% of online examples will use either of the two correct approaches and simply reading docs won't always clue you in about how the technique or syntax it's describing is actually subtly wrong and you should ~never use it.

[jakogut]

I find integrating shellcheck into my text editor was one of the best things I've done for increasing my productivity when writing shell scripts.

[danielheath]

Yep - in the same way that you want govet, eslint, rubocop etc - but to a higher degree, because bash hides subtle bugs as soon as you use a variable without knowing the quoting rules.

[sureglymop]

Yes, i did the same! I also recommend following Stephane Chazelas on stackoverflow. The guy is a shell wizard who writes multiple quality answers a day. He's also the guy who found the "shellcheck" vuln some years ago. Learned a lot by reading the RSS feed of his SO profile every day.

[freddref]

I've always been sheepish about this, but bash is my favorite programming environment! Not really because of any language features as such, more it's terseness and simplicity. Another big draw for me is bash's ubiquity. All of this makes bash the ultimate glue layer. That said, if a bash script goes longer than ten lines long I'll usually rewrite in python.

[alganet]

Bash _itself_ (or any other shell) is very small. You're talking about the ecosystem (shell + other command line utilities).

Commands like awk, find, grep, sed, cut and so many others are not strictly part of the language. They're external tools commonly provided by the operating system or distribution. That's why there are so many inconsistencies between their options.

Here are the very few commands that actually are part of any modern shell: cd, printf, test, read, command. The control structures (if/elif/fi, while/do/done, for/do/done, case/esac) are also part of the shell, so is declaring functions and fd redirection. Some shells might do more (bash itself has a handful of other builtins, dash has fewer, ksh has different ones).

Stuff like find, mv, cp and dd are very uniform across implementations and often don't change much, but they are external tools nonetheless.

Once you internalize this distinction, and start to see these external commands like npm packages, scripting gets a lot easier.

[Izkata]

> Bash _itself_ (or any other shell) is very small. You're talking about the ecosystem (shell + other command line utilities).

I'm not so sure. They mentioned syntax, and the single biggest issue among my co-workers who don't like bash is that they think ' and " work like they do in python or javascript.

[alganet]

They mentioned "20 ways of doing things", I'm replying to that complaint.

Quoting is an issue if you don't understand the IFS and command expansion. It's an old fashioned style, but it is consistent and there's only one way of doing it (quoting every variable and subshell use).

Think of shell variables as non first-class citizens, they can only be used interpolated within a string, like "$var". The shellcheck tool enforces this perspective, which makes ' and " behave very much like python or JS.

[Izkata]

To give a more solid example, they don't understand why

  npm test

works and why they don't need

  npm "test"

[alganet]

That's just lazy. How that works is on any shell man page. If you fiddle with it a little bit you figure it out:

    set -- "foo"
    echo $#
    set -- foo
    echo $#
    set -- "foo bar"
    echo $#
    set -- foo bar
    echo $#

Of course, people just want their commands to run and not learn a whole new language. Then I come back to my initial point: the language itself is small and easy to remember once you internalize it, what makes it scary is the umbrella of different command line utilities that _seems_ to be a part of the language but it's not.

[ungamedplayer]

User error.