I'm at the level where any Bash book/guide/etc that wants my attention needs to prove that it's more useful than Greg's Wiki.<p>Chances are, it isn't.<p><a href="https://mywiki.wooledge.org/BashGuide" rel="nofollow">https://mywiki.wooledge.org/BashGuide</a><p><a href="https://mywiki.wooledge.org/BashFAQ" rel="nofollow">https://mywiki.wooledge.org/BashFAQ</a><p><a href="https://mywiki.wooledge.org/BashPitfalls" rel="nofollow">https://mywiki.wooledge.org/BashPitfalls</a>
I'm a huge fan of Bash, and am always interested in upping my skills. My only question is this: Is it better than the (free) <i>Bash Guide</i>?<p><a href="https://mywiki.wooledge.org/FullBashGuide" rel="nofollow">https://mywiki.wooledge.org/FullBashGuide</a><p>Because that is a pretty amazing resource.
> It is not even theoretically possible to write a piece of software which will behave the same no matter how and where it is run.<p>Can you elaborate on that? I'm sure it's both true and false depending on your definition of "how and where it is run," but wondering what you had in mind specifically.
Slightly off topic, is there a nice/modern way to deal with filenames that can have spaces in bash scripts? The only solutions I have seen use tons of quotes are are unreadable/unmaintainable.
This one hopefully has a bit of an original twist by being focused on maintainability and understanding some of why Bash is different from most programming languages, and by being aimed at software developers mainly working in other languages.<p>I'd like to write a follow-up article about the process of getting there if there's any interest. AMA.