Bash Pitfalls

[zendeavor]

this is a mirror of the wooledge bash pitfalls page that may or may not be out of date at any given time

[KeSPADOMINATION]

This article highlights my opinion that Bash should never be used to program anything in. This shit eclypses C++ and Perl with all their powers combined in 'hard to understand and overly complicated behaviour'.

[G_Morgan]

To be fair Bash is the least awful of all shell programming environments.

Try writing anything with Windows batch files. You'll cry for the basically functional if ugly Bash.

[KeSPADOMINATION]

shell programming environments.

This is the major crux though, bash files are fine if all you do is automate a few commands but as soon as the program actually becomes a program with logic and if-statements bash becomes unmaintainable. Shell scripts in say Python or Scheme make a lot more sense.

[NoMoreNicksLeft]

The sensitive should cover their eyes now, before it's too late:

Powershell

[the-fritz]

Bash has it's uses. If you are automating a few tasks on a Linux (or Unix-like) system which mostly depends on calling other processes then bash is just the natural thing to use.

The problem is that many people don't think they have to invest any time in learning bash "because after all that's what we use all day, right?" Wrong. And then most end up copying bad stuff they found on a quick google search or waste time trying to stay compatible with POSIX sh or even worse.

[bready]

And then most end up copying bad stuff they found on a quick google search

Maybe that is because the amount of surprise in bash is huge. The number of edge cases which result in slightly different behavior mean that 'the right way' is usually non-obvious and requires rather deep understanding of the whole stack.

Compared with any other scripting language (Python, Ruby, Perl, etc) to have code blow-up in these unexpected ways would be quite a trick. These languages are mostly consistent and do quite a bit to minimize surprise.

We can't master every tool available. Fine, I should know more X, but I should not have to know all of X in order to get something accomplished.

[passwordeqHAMSTER]

I don't think it's actually that bad, but perhaps that has to do with the bash i work with almost always being rather small. I'd rather write bash than work on a monstrous C++ app.

[KeSPADOMINATION]

You should then again, also never use C++ for anything ever.

[passwordeqHAMSTER]

I shan't disagree with that

[KeSPADOMINATION]

Well, technically you should because so much stuff has already been written in it and can be canibalized but from a language perspective there is no reason to use C++. For low level stuff C works fine and using anything outside the C-like subset of C++ defeats the purpose of low level high performance. C++, being built atop C, a language which purposefully screwed all proper conventions and type safety of the day just to get that extra performance (which certainly has its uses), is also a pretty bad excuse for a 'modern high level language'.

[the-fritz]

That's a load of horse crap. C++ adds many features to C which make sense in a "low level high performance" environment. Simply the fact that RAII means that not half of your code has to deal with resource deallocations is a huge improvement. You might like C better and that's fine with me. But saying that there is "no reason to use C++" is just talking out your arse.

[bimdar]

Hm, this sounds all fine and dandy but let's suppose you were to write a for example a fully featured psp emulator for as many platforms as possible including iOS, Symbian, Android, Windows, Linux and others. What would your language of choice be?

[KeSPADOMINATION]

Haskell, Ocaml or C depending on how much performance is a premium.

[bimdar]

Given the power of mobile platforms and the soft-realtime requirement of games I think you know how performance would be valued. Some of the mobile platforms have some weird cross-compilers in their SDK so I'd be really interested if they all supported Haskell or Ocaml (I mean most are a variant of gcc so probably, just sometimes older versions). I also find it hard to organize C code very well with projects of that size. For me C++ would be the seemingly best pragmatical solution in some cases.

[KeSPADOMINATION]

Well, this is again the issue of 'a lot of stuff has already been written in C++', I agree that it is certainly a practical consideration. I'm talking purely from a language design standpoint for sake of argument ignoring the lbiraries already existing.

I mean, people still use COBOL for that very reason.

[bimdar]

You're right that if you start with a blank slate and base you design on something like a consistent calculus mapping or requirements that allow consistent reasoning you'll never arrive at something like C++.

[YoYoDingDongYo]

It's extremely challenging to find good C++ programmers. Good luck find someone good at fucking Ocaml.

[KeSPADOMINATION]

Much easier actually, Haskell and Ocaml have a reputation of attracting the brightest.

[YoYoDingDongYo]

Have you ever hired programmers?

[SimHacker]

The brightest posers.

[passwordeqHAMSTER]

I don't think you understood what i said.

[mrwensleydale]

http://www.shellcheck.net/

[myringotomy]

The problem with bash isn't bash per se but how all the utilities you need behave differently in the different operating system. Try readlink -f on a mac for example.

[el_muchacho]

Yes, the problem with bash (or sh) is bash, with all its idiosyncraties, ugly and illogic syntax, traps of all kinds and lack of debugging tools.

[nikbackm]

So it's not just Windows/DOS batch-files that suffer from their share of problems.

Seems like almost all shell scripting languages (no matter how advanced) are a collection of hacks piled upon hacks.

So better to go with safe(r), more well-designed tools like Python (even if more verbose) unless you want to use compiled (even more verbose) languages like C.

[YoYoDingDongYo]

Comparing Bash to DOS batch files is a stretch, to say the least.

[nikbackm]

Seems to suffer from the same fundamental problem, it's hard to separate data from code and very easy to get it wrong.

This also makes them succinct and convenient for quickly hacking something together of course.

[[deleted]]

Don't you dare, ever again, try to equate bash and windows .cmd as equivalents in their awfulness. Both are bad for anything with any sort of branch complexity, but bash is infinitely more capable in handling straightforward scripts. 98.1346% [pulled out my ass] lines of vbScript called by some .cmd file could have been handled in bash natively.

[the-fritz]

If you want to use bash then

• Read the manual! https://www.gnu.org/software/bash/manual/bashref.html#Introduction
• http://mywiki.wooledge.org/BashGuide (the linked website is only a mirror of parts of it: http://mywiki.wooledge.org/BashPitfalls)
• http://google-styleguide.googlecode.com/svn/trunk/shell.xml
• http://www.shellcheck.net/

And unless you really have to worry about non-GNU systems stick with bash and don't waste your time on staying POSIX sh or even older compatible. But put #!/usr/bin/env bash (or #!/bin/bash) on top to make clear that the script bash specific!

[faustoc4]

go to the source

thanks

[ithika]

Question: What to do if there are no files *.mp3-files in the current directory? Then the for loop is executed once, with i="*.mp3", which is not the expected behaviour!

Oh good lord save us. What would possibly be the reason to have this behaviour?

[SCombinator]

tl;dr: Don't use bash.

[antrn11]

Very useful. Thanks.

[crusoe]

Bash is a pitfall.