nixCraft 🐧Feb 16

At top of your bash script add this after `#!/bin/bash` line to aborts the script immediately and add robustness to your script
```
set -euo pipefail
```

Use the following to trap error and show line number where your script failed to debut at run time or development time:
```
_failed() {
echo "$0 - Script failed at line $1"
}

# Trap the ERR
trap '_failed $LINENO' ERR
```

See `man bash` or `help set` for more.

Show threadgrefengFeb 16

@nixCraft Make the shebang portable with

```
#!/usr/bin/env bash
```

Show threadnaikrovek
@grefeng @nixCraft that looks a lot like a global variable to me, and you're relying on it. pro tip: don't rely on things which can change underneath you, such as $PATH
Feb 16 at 1:47pmWeb
Show threadgrefengFeb 16
@naikrovek Not quite. The shebang is the first line in a text file (marked with #! at left most), that the loader tells which interpreter to use. By using `/usr/bin/env bash` it picks the first bash found in PATH variable. That way the admin of the system (globally) the user can change the default bash to use, which can be a newer/patched version than the vendor delivered. On some systems /bin/bash or /usr/bin/bash lies on RO filesystems. So with /usr//bin/env you decouple and are portable.
Show threadnaikrovekFeb 16
@grefeng who cares about portability? I stick the shebang line on as i deploy/build, choosing the correct one depending on the OS. `env` is dangerous. how can it not be?
Show threadgrefengFeb 16
@naikrovek If you write the scripts only for yourself, than your approach is doable. If you have to write scripts for potential thousands of customers, then you care about portability and compatibility. And I dont see (currently) any harm in using `env`. Of course the scripts, that depends on specific features checks for the current setup.
Maybe we have just different requirements with our "scripting targets" – mine are not fixed but very flexible. (edit: typos)