set -o errexit # or set -e if you prefer

    set -o pipefail

    ls *.ssjkfle | wc -l

  DEST_PATH=/opt/$VENDOR/$DEST_DIRNAME
  #remove destination
  VERSION=`cat "$DEST_PATH/bin/.version"`
  if rm -fr "$DEST_PATH"; then
  	echo "INFO: $APP_NAME (ver.$VERSION) has been uninstalled successfully."
  ...

Scary to see a big company like Samsung release code this bad.

    function cleanup {
        ...
    }
    trap cleanup EXIT

    trap "{ echo; exit 1; }" INT

  #!/usr/bin/env bash

  #!/bin/bash

http://en.wikipedia.org/wiki/Shebang_(Unix)#Portability

The other thing is, if you're targeting obscure systems, wouldn't it be just as likely that there wouldn't be a /usr/bin/env, /usr/ might not be mounted, or that bash might not be installed at all?

I suppose what I'm asking is: for practical purposes, is the lowest common denominator /usr/bin/env or is it /bin/sh?

I don't use env on my shebang lines specifically because it's then PATH ordering dependent (there used to be a thing where /usr/local/bin and GNU tools were last in root's path, but first in non-root users' path). I'm more confident (perhaps incorrectly) that /bin/bash or /usr/local/bin/bash is what I expect it is vs the first thing found in PATH that is named bash is what I think it is (however, this applies moreso to coreutils-like things, that have different SysV vs BSD semantics/options, vs a shell such as bash, which is known everywhere to be GNU bash). Some tools, like ssh, can propagate environment settings based on local, remote or config file settings, and I'd rather not be surprised.

This used to be a bigger deal on systems that put reasonable (where "reasonable" == "what you're used to") tools in /usr/ucb or /opt/gnu, rather than system paths. If you're going to create something that's intended to be "portable", you've got bigger fish to fry than if and where bash is available, and it's wise to abstract system differences to different scripts (run.linux.sh, run.freebsd.sh, run.osx.sh, run.aix.sh, etc) than try to keep everything in one massive script anyway.

  FreeBSD = /usr/local/bin/bash
  OpenBSD = /usr/local/bin/bash

Yes there are.

OpenBSD for instance installs third party software under /usr/local. Bash is not a part of the base system.

env(1) on the other hand is a POSIX standard utility and comes with the OS.

Usually Solaris would get GNU tools installed beneath /opt, or similar, rather than in /bin.

    #!/bin/sh
    if [ -z "$BASH_VERSION" ]; then
        if which bash >/dev/null 2>/dev/null; then
            exec bash "$0"
        else
            echo "ERROR: bash was not in your PATH" >&2
            exit 1
        fi
    fi

    # now start using bash-only shortcuts safely
    if [[ "hello" == "hello" ]]; then
        echo Bash has been achieved.
    fi

Those sort of deployments got a lot of milage out of /usr/bin/env

https://en.wikipedia.org/wiki/Unix_directory_structure#Conve...

Not that this rule of thumb helps define the location of bash. It may or may not be considered essential for recovery.

[1] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard http://www.linuxfoundation.org/collaborate/workgroups/lsb/fh...

Basically everything that isn't a typical gnu/linux distro or osx. Bash is not a standard tool, it is a gnu specific shell. Posix requires env to exist, and requires it to exist in /usr/bin/. If you are using bashisms, then using /usr/bin/env bash will let people without bash see that your script is a bash script, and install bash to solve the problem. If you hardcode /bin/bash they have to fix your script.

> is the lowest common denominator /usr/bin/env or is it /bin/sh

Ideally you should use /bin/sh of course. But it is missing functionality some people want to use, so in that case using bash the portable way is preferred over using bash the unportable way.

    your script is longer than a few hundred lines of code
    you need data structures beyond simple arrays
    you have a hard time working around quoting issues
    you do a lot of string manipulation
    you do not have much need for invoking other programs or pipe-lining them
    you worry about performance

People who insist on rewriting an ENTIRE program in Python, Perl, or Ruby fail to understand the Unix philosophy (this is a real misunderstanding I've encountered in my work, not a straw man).

You can just write the complex part in another language, but keep the rest in bash. In other words, main() stays in bash. Python et. al. is used as just another process. bash is a language for coordinating processes.

You don't want a 2000 line bash script. But it can be worse to have a 5,000 line Python script that shells out to tons of other utilities, or awkwardly and verbosely reimplements 'xargs -P' or 'sed -i'. Often you can do the same job with 500 lines of bash and 500 lines of Python (or C), and that is the ideal solution.

Python and bash are pretty radically different languages, and they are not interchangeable (the advices "just rewrite in Python" seems to imply they are). You can use each one for the things they are good at.

I work with some deployment systems that chain together small scripts in a bunch of different languages. They are a nightmare to troubleshoot.

I'd much rather the spaghetti was all on one plate than follow it from table to table...

The biggest mistake I see people making is to hard code paths, ports, user names, configuration, etc. inside Python/Perl scripts. All that stuff belongs in shell. All the logic and control flow goes in the scripts. If it's factored this way, then you have a very natural way of testing the scripts with test parameters (i.e. not production parameters).

I don't doubt that there are many multi language shell scripts that are spaghetti. Factoring into processes is definitely a skill that takes thought and effort, and I don't think anyone really teaches it or writes about it. The only books I can think of know of is The Art of Unix Programming by ESR and the Unix Programming Environment.

But it's definitely made me way more productive once I started thinking like this. People say talk about the "Unix philosophy" for a reason. It's a real thing :) It's not an accident that Unix is wildly popular and has unprecedented longevity.

Verbose, and almost guaranteed to be more accurate. The thing about python/ruby/perl is that when you do things the programmatic way you get safety by default. You don't have to remember to 'find -0 | xargs -0' and thing aren't going to bite you in the butt when filenames have spaces in them.

Yes, you can make all that work with shell (heaven knows I've done it), but it's more work and sadly isn't shell's default state.

  python3 - <<'END'
  print('hello world')
  END

Remember to use the <<'END' variant so variable expansion isn't done inside the heredoc. On the other hand, $ doesn't do anything in python and if you're feeling like it (please make sure everybody else is also feeling like it) you can use variable substitution there, in effect generating a python script and executing it.

http://tldp.org/LDP/abs/html/quoting.html

http://tldp.org/LDP/abs/html/here-docs.html

As mentioned above, things that belong in shell, and NOT in Python:

  - file system paths (these are parameters to Python scripts, not hard coded)
  - port numbers
  - user names
  - other config values
  - concurrency -- you can get really far with xargs -P, and sometimes &
  - pipelines (try doing this in Python without shelling out; it's horrible)

  - complex control flow (e.g. I rarely write loops in bash; never a nested loop)
  - data structures (bash has hash tables, but I never use them)
  - arithmetic
  - parsing and cleaning individual lines or fields of data

To be honest, I trust myself more manipulating paths in a language like Python than to put all quotes in the correct places in Bash :(

  - Avoid paths with spaces :)
  - If you have to handle paths with spaces, use double quotes everywhere,
    e.g. "$pidfile".   
  - Always use "$@".  I've never found a reason to use $@ or $* unquoted.

That's it. I don't think it's hard at all, although you will certainly see scripts in the wild where the author was confused about quoting, and quoting hacks pile upon hacks. If you use a consistent style, it's very smiple.

There is a learning curve like there is with any language, but it's totally worth it. Shell is an extremely powerful language, and saves you MANY lines of Python code.

I would say Python is definitely the easiest language to learn, but bash is not harder than say JavaScript.

I'd like to add: Always use double quotes around paths. Or is there something I'm missing here?

  $ ls -l "*"
  ls: cannot access *: No such file or directory

  $ ls -l "path with/lots of spaces/"*

That's because a double-quoted expression is supposed to evaluate to a single word. Wildcard expansion can result in multiple words, but parameter expansion doesn't.

(Except for things like "$@". With bash, the rules always have exceptions.)

Then, when bash isn't enough, I write the difficult parts in Python as standalone utilities and use those from bash. Consequently, I already have a library of little tools in my ~/bin that are generic enough so that I can just use them from bash right away. But every now and then I need to write a special tool that my bash program can use.

Most of my programs "finish" after this stage and they can live for years as a completed bash script calling helper programs. They do their job and there's nothing to add. As long as the program continues to "live on" I just make changes to the bash script or the helper programs.

If at some point I need features that bash can't offer, such as more speed or more complex data processing, I begin to consider rewriting my program in one language. But this is only after the first revision of the program is already complete and I know exactly what to do when porting.

Thus, porting the program is initially only about rewriting in another language, not developing it further at the same time. The first months or years of using the bash script turn into a prototyping stage, and this allows my rewrite be concise, well-thought and clear-partitioned.

In other words, the rewrite becomes a new stable baseline that contains only the best of my bash prototyping, and only solves a perfectly scoped problem. As soon as the port becomes a drop-in replacement for my original bash program I switch to using it and start a development branch to support the new features, if any. Usually the newly gained speed is enough already.

And usually the rewrite happens using C or Scheme. There's rarely enough point in rewriting the script in Python which may already be used to some extent in utility programs that the script calls. At that point I don't want to extend the program but lift it onto a new platform to cut some old baggage that's not needed anymore. There's a certain kind of joy rewriting in a new language something that you know completely before hand. This allows you to only work with the language since the underlying problem is already solved.

Coincidentally, this new C or Scheme program might then, one day in the future, be called from a new bash script...

Python is my choice when I need a bit of logic in my scripts, but it's just a personal choice of course. A good addition for simplifying execution is the "sh" library that lets you call system commands easily as if they were python functions: http://amoffat.github.io/sh/

The advice on functions also gives me pause because that helps you write longer Bash scripts...not a good idea. Functions are of limited use because they can't really return values (just an exit status.) If a function has to return something, it generally prints it to stdout...which requires use of command substitution to get the result...nasty.

Shells are good for interactive use and for starting other programs, but it's a lot easier to take a full-featured language and make it work like a shell than it is to take a shell and make it behave like a full-featured language.

I'd take this blog post, add considerably to the "when you shouldn't use Bash" list, and put that at the top of the blog post, and then say "but if you absolutely must use Bash for something that is not trivial, here are some things that can make the process manageably nasty instead of truly horrid."

Actually, it was kinda neat for the first 3 months or so, to have reason to dive deep and flesh out the dark corners of my bash knowledge. There's a few things I picked up that have served me well since - and I'd lived in the shell for years beforehand... The balance wasn't kinda neat.

So very often people lose track of when to use what tools. (Although admittedly, so very often people are forced into some tools by external constraints.)

http://www.etalabs.net/sh_tricks.html

Shell scripts are great, I use and write them every day (and quite advanced ones, too). But it's very hard to make a shell script robust.

Unfortunately it's hard to find a replacement that is stable and installed everywhere. Perl is pretty close. And python too, if you are careful about making your script compatible with all the different versions.

What if you invested in learning POSIX sh?

Wouldn't your scripts and one liners written in POSIX sh work in zsh, bash, etc.?

You could be comfortable on any server, no matter what the shell.

Even servers that default to tcsh still have /bin/sh.

But if you're going to dive deep on any of them, bash has a pretty unique and strong argument for being quite likely to be available on most of the machines you work with on a day to day basis.

The servers I use do not have bash installed by default.

The only time I use it is when I am forced to by an installation script.

I install bash on an as needed basis, and when I'm done using it, I uninstall it. I just have no need for it otherwise.

What is the shell on Android? Is it bash?

Many servers don't have bash installed as part of their base distribution, but if they're going to have another shell already installed it's much more likely to be bash than zsh.

And thanks to oh-my-zsh (https://github.com/robbyrussell/oh-my-zsh) it really requires very little fiddling, maybe 10 minutes worth.

Here is a great gallery of oh-my-zsh themes: http://zshthem.es/all/

What's really neat is you can even use it on Windows.

My personal setup is Cygwin Zsh inside Console2 (tabbed cmd.exe shell) proxied via ansicon.exe (makes cmd.exe ansi color escape aware). It's not quite as nice as say Konsole on linux or iTerm2 on a mac, but it's the best I've found for windows.

Setup guide:

Setup console2 like this http://www.hanselman.com/blog/Console2ABetterWindowsCommandP...

This post sets up ansicon: http://www.kevwebdev.com/blog/in-search-of-a-better-windows-...

https://code.google.com/p/conemu-maximus5/

I haven't tried Console2, so I can't provide a comparison, but here's Scott Hanselman deciding to switch: http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol...

What are some of the differences that made such a difference for you?

- tab completion on a shit-ton of stuff (configure scripts, makefiles, ssh hosts, aptitude packages, git branches)

- partially entered command? push up to look at similar commands you have previously entered

- immediate propagation of zsh_history to all open shells

you could (correctly) argue that you can do all that in bash. of course, shell scripting is turing complete, so yes, you can. but with zsh, it's already there, and ready.

I use bash's reverse incremental search ("C-r") to do that. Is the zsh that much better than that?

The history sounds neat, except that I tend to segregate my terminal tabs to specific tasks/projects so I'm not very likely to want a command from one tab in another. Also I always set my bash history file to /dev/null so I don't have to worry about leaving sensitive data lying around, which means I new tabs are always a clean slate.

i don't doubt that at all - but it's hardly default bash, and i frequently don't have root on the systems i use (whereas zsh is usually there)

> I use bash's reverse incremental search ("C-r") to do that. Is the zsh that much better than that?

hands down yes. nobody had to explain how "up-complete" (i don't know what's it's called, but i'm calling it that because that's what it does) works to me. simple and intuitive!

> Also I always set my bash history file to /dev/null

fair enough - different people have different uses for things, i thoroughly recommend you try zsh though, because, why not! have a poke around the excellent oh-my-zsh as well, try out some themes.

i thought i had a good work flow with bash, and that there was really any room for improvement. after a few hours of zsh on my laptop, it was my shell everywhere :)

For Bash, M-# (alt-shift-3) puts a comment token '#' at the start of the current line and begins a new empty line. Handy if you are 150 characters deep in a command and realise you need to do something else for a moment (i.e. momentarily in the correct sense). You can store your 150 char command and come back to it, it is in the history and can be retrieved with a couple of Up-arrows.

mark . marks the current directory in a folder full of symlinks.

jump <tab> expands to a list of your favorite folders.

super simple and extremely low overhead.

[1] http://jeroenjanssens.com/2013/08/16/quickly-navigate-your-f...

  cd s*/l*/f*/p*

  complete -r

Disabling it saves a lot of frustrated tab-banging.

I think I "solved" it by ensuring I'd correctly typed the start of what I wanted before hitting tab. Which is better and faster anyway. It fixed me...

BTW: Ahem. Good sir, I know what tab completion is. I've even added to it for some of my scripts (nothing fancy though).

You can even preemptively fire up a master connection to commonly accessed hosts to avoid the initial delay.

[1] https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

Thank you very much, I’ll try to play around with it :)

Neither of those is what I was talking about though, as they aren't really part of the smart complete. To answer your question, I don't have an example, I just know that I tried ubuntu a while ago and smart complete would hang all the time. I don't currently have an ubuntu machine, so I can't try to track it down.

  cat <<REQUEST_BODY |      
  {
    "from" : 0,
    "size" : 40
  }
  REQUEST_BODY
  curl http://localhost -d @-

    curl http://localhost -d @- <<REQUEST_BODY
    {
      "from" : 0,
      "size" : 40
    }
    REQUEST_BODY

    request_body() {
        cat <<REQUEST_BODY |      
        {
            "from" : 0,
            "size" : 40
        }
        REQUEST_BODY
    }

    get_url() {
        curl http://localhost -d @-
    }

    request_body | get_url

/readability sometimes trumps YAGNI

    cat <<REQUEST_BODY | curl http://localhost -d @-
      {
        "from" : 0,
        "size" : 40
      }
    REQUEST_BODY

I use fish as my main shell and its slightly better, but just testing things on variables can be a huge mess.

Do you have any recommendations to make fish play better with shell scripts intended for bash?

I was jumping into bash a lot working with ROS until I made my own ROS fish bindings and still go back when I'm copying and pasting, e.g., code for grabbing some commit from Gerrit.

shok proposes that the solution to awkward-shell-syntax is to syntactically separate the programming language from program-invocation.

See http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03...

One of my main complaints with bash.. the file is evaluated in order - you can't call a function on the line before it's declared.

This fails:

    #!/usr/bin/env bash
    bar='bar'
    foofunction

    foofunction(){
      echo 'foo'
      echo $bar
    }

You probably want the interpreter to be smart: "Am I loading a script from a file, or am I receiving instructions interactively on the command-line?" But now there's two modes of execution, and code in a bash script won't work if you type it into the prompt yourself. That's a bit uncomfortable.

    #! /usr/bin/env bash
    set -e -u
    bar='bar'
    
    main() {
      foofunction
    }
    
    foofunction() {
      echo 'foo'
      echo $bar
    }

    main "$@"

Project page: http://www.zx2c4.com/projects/password-store/ Source: http://git.zx2c4.com/password-store/tree/src/password-store....

Googling bashlint, shlint turns up some discussion (bash -n, ksh -n, zsh -n, some github projects), but I doubt they cover this article's specifics - though most (all?) of it could be automatically checked. I think some could be automatically added (e.g. set -o nounset) - perhaps a bash-subset (or coffeescript-style language) possible...

    :SyntasticInfo

I can see universal application of ${} being advantageous in avoiding accidental "$foo_bar where you meant ${foo}_bar" situations, and ${} makes it clearer that you're referencing a variable. The only cost would seem to be more typing.

Better is subjective... About half my scripts depend on those features. For default arguments, and fail early.

    COULD_BE_SET=${COULD_BE_SET:altvalue}

  set -e

  set -o err

I think "set -e" in bash should become common on the same level, it's pretty rare that you really want a script to continue after an unguarded error return.

Given that, I think it's nice to be a bit more explicit, as it means the person who reads your script to copy and paste a bit out of it is more likely to learn something new in the process.

Not that the copy and paste approach to learning a language is good, but that's how these things typically go in practice.

  #! /bin/bash -eu

If i was more selective in my use of those flags, then i would agree that the long forms were preferable, for the reasons given.

  % bash script.sh

As you can guess, I've done this by mistake. One case is after transferring or unarchiving files where execute flags get turned off by mistake. Or using utilities, like job schedulers, that are tricky in whether they run the script as an executable, or via a shell interpreter.

. ./file

versus

source ./file

Try googling for that if your Google foo is weak. "shell script dot"? "bash dot"? (edit: it seems Google search has gotten smarter or probably has an improved profile for me since this time it actually points to somewhat useful stuff; last time I searched for this was 8 or so years ago)

But "set -e"? Oh yeah, I use that all the time. It also has the benefit of being the same name as the command line option. That's especially useful for "set -x" which I use all the time when debugging bash, especially in the form "bash -x myscript".

I would never say "tar --extract --file" either–it's just not done.

Anecdotally, I've nearly always seen "set -e" in bash scripts I've worked with over the years (if the option is there at all).