[jigglesniggle]

I highly recommend running shellcheck on all of your bash code. It is what finally taught me the practical difference between [[ and [. There are some tests that will always pass in [, for example, but work properly in [[; one project never realized.

[mankyd]

My (personal) better recommendation is to avoid bash scripts whenever possible ;)

I generally tell people that, once a script is longer than ~100 lines and/or you start adding functions, you're probably better off with something like Python.

I know that's not a popular opinion with shell enthusiasts, but it's saved me so much frustration both in writing new scripts and coming back to them later for refactoring.

[cauthon]

> I generally tell people that, once a script is longer than ~100 lines and/or you start adding functions, you're probably better off with something like Python.

Agreed. My threshold is usually "when you want to start using arrays or dictionaries". I find bash best for file manipulation and running programs in other languages

[progman]

Bash is a typical Unix tool, and Unix follows the KISS principle. Hence, also Bash scripts should be KISS.

If you need >100 lines of code your code is too complex in the script world, and you should split it into several scripts where each does one thing, and that one thing well. Usually, bash scripts are applied with pipes. A sequence like cat x | tr a b | sort >output is much more likely and easy to handle then a single script which does all these things.

KISS with Bash is a very different approach compared to other scripting languages like Python and Perl. There you can write long code easily and conveniently. However, things can get tough when larger scripts need to be maintained.

I consider the examples in the "Bash Bible" a collection of useful black boxes. It's fine if they just work. Regarding the "unreadable" trim_string for instance, if you have problems to understand that code, and you have to change something then you can simply write your own new trim_string script, even in Python or Perl if you like. Pipes work also well with them.

Update: Another advantage of bash and pipes over Python/Perl is that the Unix system can assign each script in a pipe to a separate thread. That means, simple bash scripts with pipes can work _much_ faster than single scripts in Python or Perl.

[tracker1]

I tend to work in Windows, Linux and MacOS pretty regularly... so I tend to follow a similar approach (node instead of python though). Windows-isms under msys(git) bash in Windows just gets painful to coordinate at times.

I am curious if people will uptake PowerShell Core (though not much of a fan there either).

[shrimp_emoji]

I'm so glad I'm not alone in this.

I never even bothered to learn Bash properly because even that's difficult, and I figured it'd be "good mental money after bad". And, now that Python ships with all distros, I feel even less need to.

I do like Bash's range syntax though:

    for i in {0..5} ; do echo $i ; done

Like Ruby's. It's so nice! D: I lament Python's lack of it.

[yesenadam]

    echo {1..5} 

is even nicer. Or

    echo {1..5}{1..5}{1..5}

[dec0dedab0de]

My rule of thumb is to use a real language if there is more than one if fi block.

[jascii]

So, what in your opinion constitutes a "real language", and why?

[dec0dedab0de]

a "real language" would be any programming language that is primarily designed and presented as a programming language.

[jascii]

Nice recursive definition..

The practice of programming in shell languages was well established when Bash was designed and Bash was definitely designed with that use in mind. So by your definition Bash is a "real" programming language.

Lisp on the other hand, was much more designed as a system and formal notation to reason about certain classes of logic problems.. So, Lisp is not a "real" language?

[dec0dedab0de]

Bash is primarily a shell, it even has the word shell in its full name.

[jigglesniggle]

By "programming language" he probably means something that has robust flow control mechanisms and metaprogramming facilities.

You can definitely tell there's a different "feel" to bash and Tcl, Python, Perl, Go, etc, yes? Shell languages basically evolved out of batch processing languages that were meant to only run programs in sequence and it shows.

[jigglesniggle]

I agree, but I like phrasing it as "only run commands with substituted arguments." There's some more discussion on this below. :)

In the past I almost exclusively used Python, but I'm starting to like Go.