[seorphates]

Most of the responses here so far that do not include some sort of a guide are not the responses you're looking for (imho).

Mind your pipes and quotes. Guard your variables with braces. Do not export everything, test for and (try to) handle return codes and conditions and keep it simple (emphasis simple) but most of all just write it.

BASH (or Bourne) is ubiquitous when dealing with systems (vs programs). You don't need to be on the fashionable lang of the day by any measure. BASH, for most cases, will always be there, always ready and, in most cases, is the default human interface for deployed systems. As scripting languages go you don't need "better", you need dependability, zero dependencies with no requirement for modules or any other whizbangwoohoo plug-in. Language Fashionistas and personal preferences aside at least some level of fluency with BASH should be mandatory for anyone interfacing with a system.

[curiousgal]

https://www.google.com/search?q=whizbangwoohoo

[fredley]

Google Whack!

[quickthrower]

Technically no. A Googlewhack requires 2 dictionary words. Dave Gorman won't be visiting us.

[n4s33r]

nice, you made a Googlewhack

[wybiral]

If there's a term of photobombing a Googlewhack, I think I just did that.

[curiousgal]

I am surprised by how quickly that took! Google's crawlers are hard working.

[joshstaiger]

1000 times this.

You're going to get a lot of snark from people saying things like "don't", or "learn python instead".

This epitomizes "a little knowledge is a dangerous thing".

Bash has many cringeworthy aspects, but we have to deal with the world as it is, not the world as we would like it to be, and the reality is that bash is the default shell on 99.9% of unix boxes you encounter — even if you use an alt shell on your machine.

Coworkers machine? Bash. Default AWS AMI? Bash. init script to bootstrap $DAEMON? Bash. ssh to a server at your workplace? Bash. Random O'Reilly Linux tutorial? Assumes bash.

My advice?

Take some time.

Sit down.

and read "man bash"

cover-to-cover.

at least once.

A lot of the illogical things in bash make a lot more sense once you understand its parsing/expansion rules. And once you understand what is in the language vs an external terminal program in your PATH.

Since that sounds unappealing (and I scoffed at that very advice for many years), I've also found the wooledge bash guide to be very helpful.

[ktRolster]

Bash is unbeatable as a functional concept for chaining command-line tools together. Once you start getting functions or even a lot of if/while constructs, it's usually time to switch to Python/Perl.

[sethrin]

I wrote a guide to the shell (posted elsewhere here). I concur with this statement wholeheartedly. Bash as a command language is exceptional, as a scripting language it is sub-par at best. I've been using Ruby a lot lately in command line scripting, little things like

$ ls /*.orig | ruby -e 'while f = gets do ... end'

It's not quite as easy as the shell tools for little things, but I feel like the crossover point where the lack of programming constructs begins to outweigh the initial ease of Bash scripting is about ten lines of Bash. Which is not to say that it's not useful -- I do think that Bash is something that every developer should know -- but that you really need to have Bash and another command line scripting language in your toolbox, and know when to use each.

[ktRolster]

I used to think of it in terms of "number of lines" but then I found a task that worked quite well in a longer bash script (creating a .deb file). In fact, it worked better than if it were a python script, because all the commands were right there.

Now my metric is, "if it needs a function, or even a complex while loop，switch to perl/ruby"

[sethrin]

I think that what I would tell new people would be "more than ten lines, OR using more than two variables, OR any flow control constructs". Bash can make even simple conditional statements difficult, and while my rule is absurdly restrictive, Bash can still be amazingly useful within those bounds. Probably mine is the lower bound for "anything less complex than this is fine to write in Bash" and yours is "anything more complex than this should definitely not be written in Bash", with the middle ground being "have a good reason why Bash is the best tool for the job".

[qrbLPHiKpiux]

I've been using linux since 1992 and if there's one thing I can't stress enough is to use full directories and not anything abbreviated. After 25 years, I still find myself slipping up, overlooking some minute detail, causing data loss.

[ori_b]

I use a variety of operating systems, many of which put things in different locations. Hell, even across linuxes, locations differ.

Don't do this. $PATH exists for a reason.

[mmphosis]

I've heard this suggestion to use full paths for a long time. Why use full paths?

[tyingq]

I'm sure there are other reasons, but the big one is that your scripts may get called in an environment other than your normal logged in shell.

Cron, for example, doesn't have the same $PATH as your login shell. So no full paths means you can fail to run some commands, or run the wrong copy of one.

There's also the security aspect. If your script has "." in it's $PATH, or something else writeable, I may be able to coerce it to run an imposter command.

[uhhfcuvv]

This is terrible advice, if you expect your PATH to be something, just set it at the top of the script and be done with it.

No need to make it 100 times harder to read.

[yebyen]

Why even expect binaries to be in the same place on different systems with different default PATHs? Know how many times I've seen problems caused by (#!/usr/bin/bash|#!/bin/bash) pointing to the wrong place?

After reading this thread though, I'm not sure I want to suggest people write `#!/usr/bin/env bash` either... since that depends on the path being correctly set, and bash being in the path!

[mobilethrow]

I've started to dislike /usr/bin/env too. At least use -i. Otherwise you're one PATH manipulation away from executing a malicious program as your intended shell.

[tyingq]

A PATH, though, is global.

Situations exist where you need more granularity.

There's also things like "watch" and "at" you might use in a shell script. They don't inherit the parent's environment, so setting PATH doesn't help.

You're correct in that "full paths" isn't a definitive answer though. I suppose the more generic advice to not depend on your environment to have it right is better.