<p>Bioinformatics tools written in shell and other shell scripts generally specify the shell they want to use (via <code>#!/bin/sh</code> or e.g. <code>#!/bin/bash</code> if it matters), so won't be affected by your choice of user shell.</p>

<p>If you are writing significant shell scripts yourself, there are reasons to do it in a Bourne-style shell.  See <em>Csh Programming Considered Harmful</em> and other essays/polemics.</p>

<p>A Bourne-style shell is pretty much the industry standard, and if you choose a substantially different shell you'll have to translate some of the documentation of your bioinformatics tools.  It's not uncommon to have things like</p>

<blockquote>
  <p>Set some variables pointing at reference data and add the script to your PATH to run it:</p>

<pre><code>export FOO_REF=/path/to/stuff
export PATH=/path/to/foo-x.y:$PATH
foo blah blah
</code></pre>
</blockquote>

<p>These will typically be shown in Bourne-shell syntax.  By using a different shell you have to translate the <code>export</code> commands to your local syntax, and especially PATH munging is somewhat shell-dependent.</p>

<p>If you're experienced in Unix, this will be only a minor niggle.  If you're a beginner, IMHO this will add a non-negligible amount of friction on top of all the other things you're learning.</p>

CC BY-SA 4.0
2019-06-18T11:24:04.693Z
**Do not** use `#!/bin/bash` in the shebang. Having Bash installed in a nonstandard location is common enough that doing so will break often. Use `#!/usr/bin/env bash` instead, it should have no disadvantage.
Konrad Rudolph
CC BY-SA 3.0
2017-06-01T15:53:21.003Z
2017-06-01T15:53:21.003Z
John Marshall
<p><strong>TL;DR</strong></p>

<p>SH adheres to an official industry standard, but it is not suitable for scientific computing. Bash is considered an informal standard (e.g., by Google). Bash 3 is preferable in most of situations in the world of bioinformatics.</p>

<p><strong>Long answer</strong></p>

<p>As already described in other answers, SH (<code>/bin/sh</code>, plain Bourne shell, the original UNIX shell) should fully adhere to POSIX which is a real industry standard. However, SH is too limited for scientific computing since many key features were incorporated later in SH successors, especially in Bash (<code>/bin/bash</code>, Bourne Again Shell): <code>set -o pipefail</code>, <code>[[ ... ]]</code>, or process substitutions <code>&lt; ()</code> to name at least few.</p>

<p>In practice, it is much more difficult to write "safe" scripts in pure SH and only shell experts are usually capable to prevent unexpected behavior. For example, it may be hard to ensure that no command in a pipeline failed in the middle of computation. For Bash, various easy-to-follow defensive-programming recommendations have been developed and they should prevent all these problems. From this reason, many computer scientists, software engineers and companies use Bash as a kind of a standard. For instance, Google internal policy allows <a href="https://google.github.io/styleguide/shell.xml?showone=Which_Shell_to_Use#Which_Shell_to_Use" rel="nofollow noreferrer">only Bash</a> for writing any shell scripts. </p>

<p>Even though we cannot expect that Bash is present on completely every Unix machine (e.g., on mobile devices as @terdon pointed out), a vast majority of *nix machines used for scientific computation should have it. We also should be aware of the fact that Bash can be slower than SH and that it has recently suffered from  major <a href="https://www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability" rel="nofollow noreferrer">security issues</a>. Moreover, various Bash versions exist and scripts working on modern Linux machines with <a href="http://wiki.bash-hackers.org/bash4" rel="nofollow noreferrer">Bash 4</a> might not work on OS X, which is still based on Bash 3. </p>

<p>To sum up, Bash 3 is probably be the most reasonable choice for scientific computing.</p>

<p><strong>Edit</strong></p>

<p>I addressed the comments from @terdon and @John Marshall. In particular, I added an explanation why Bash is more suitable for scientific computing than SH (in my opinion).</p>

CC BY-SA 3.0
2017-06-02T14:28:47.423Z
Bash is not present in every Unix machine, `sh` is and that is not the same. Yes, Linux tends to have `/bin/sh` pointing to bash, but Linux is not Unix and, anyway, even in Linux `/bin/sh` is not always `bash` (Debian based systems use dash instead, for example). You can safely expect the Bourne shell (sh) to be present on a POSIX-compliant system, but not necessarily the Bourne again shell (bash).
terdon
CC BY-SA 3.0
2017-06-02T14:47:53.390Z
@terdon Could you provide any reference, please? According to https://wiki.debian.org/Bash, bash is the default shell on Debian. Do you know about any (modern) *nix distro where bash would not be installed?
Karel Břinda
CC BY-SA 3.0
2017-06-02T14:50:15.327Z
@terdon I will answer my question – e.g., FreeBSD. https://www.freebsd.org/doc/en/articles/linux-users/shells.html says that "Bash is not included in the default installation". Do you have an example of a Linux distribution without bash?
Karel Břinda
CC BY-SA 3.0
2017-06-02T14:52:41.600Z
Some (all?) embedded Linux systems won't have bash and will instead have busybox sh. The main issue is that people tend to think that `sh` and `bash` are the same thing but they aren't. They are similar and bash is an extension of sh, but they are not the same.
terdon
CC BY-SA 3.0
2017-06-03T17:31:36.623Z
@Karel: Asking about the “default shell” is ambiguous. As per https://wiki.debian.org/Shell, these days on Debian the default `/bin/sh` is dash while the default login shell (as listed in `/etc/passwd`) remains `/bin/bash`. This means that portable shell scripts that identify themselves with `#!/bin/sh` need to restrict themselves to POSIX shell facilities, while scripts that want to use bash extensions need to use `#!/bin/bash`.  This got tidied up the hard way a few years ago when various distributions switched to dash for `/bin/sh`…
John Marshall
CC BY-SA 3.0
2017-06-05T15:26:32.340Z
@terdon @John Marshall Thank you for your comments. Compared to bash, I consider "pure" sh very limited and inappropriate for scientific computing, in particular because of some missing, but very important, features such as `set -o pipefail` or `[[ ... ]]`. My experience is that sh scripts can be very susceptible to unexpected behavior (unless the developer is a shell expert, which is usually not the case in bioinformatics). Several good and simple defensive programming strategies for scientific computing exist for bash.
Karel Břinda
CC BY-SA 3.0
2017-06-05T15:35:02.740Z
This is why I would like to know whether `/bin/bash` might not return anything, or return a non-bash shell (I have seen such a problem only once with some obscure bioinformatics distribution).
Karel Břinda
CC BY-SA 3.0
2017-06-05T19:33:51.027Z
I wouldn't do "scientific computing" in a shell no matter what shell it was. The shell should be used for, at most, handling the plumbing for basic utilities and applications. Computing should be handled by utilities and applications designed for those tasks.
Kusalananda
CC BY-SA 3.0
2017-06-05T19:41:45.020Z
@Kusalananda  How do you do scientific computing without shell? I believe that you use it at least for running your programs. If it is so, do you agree that the way how it handles errors matters?
Karel Břinda
CC BY-SA 3.0
2017-06-06T19:31:45.773Z
@Karel I wouldn't do computing of any kind _without_ a shell, but not _in_ (with) a shell.
Kusalananda
CC BY-SA 3.0
2018-01-18T10:45:43.910Z
I’m a bit puzzled why this answer recommends the ancient Bash 3 instead of Bash 4, which itself is now almost 10 years old (announced in 2009). Bash 3 lacks crucial features such as associative arrays so it’s a severe restriction. True, macOS still ships with Bash 3 but so what? macOS is generally known to lag behind in its unix tools (and even for its Ruby and Python). Also, nitpick: it’s “Bash”, not “BASH”.
Konrad Rudolph
CC BY-SA 3.0
2018-03-02T00:25:33.620Z
@KonradRudolph Thank you for the comment. I fixed the capitalization issue. Concerning Bash 4, I completely agree that it has many useful features. However, if it cannot be used on a substantial proportion of machines, it's a fatal problem. Whereas Python 3 can be easily installed (e.g., using Conda), upgrading Bash is complicated and easily results in serious problems. As for the associative arrays, the Google standard says the following: "If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python."
Karel Břinda
CC BY-SA 3.0
2018-03-02T11:21:52.183Z
@Karel I have a few choice word for the Google coding guidelines, none of which are acceptable in polite company. Anyway, upgrading Bash is actually trivial. Replacing it for the *login shell* may not be but in practice that’s unnecessary: on macOS you specify the shell in the terminal app, and other systems ship with Bash 4.
Konrad Rudolph
CC BY-SA 3.0
2018-03-05T23:42:39.743Z
strongly agree with @Kusalananda, trying to write your pipelines entirely *in* shell is a mistake. There are plenty of [workflow frameworks](https://github.com/common-workflow-language/common-workflow-language/wiki/Existing-Workflow-systems); I am partial to Nextflow, and a lot of my peers use Snakemake. Entirely shell-based pipelines quickly become unmanageable, overly complex, confusing to understand, and extremely difficult to debug. If you *must* use Bash, then you should aim for POSIX compliant implementations.
user5359531
CC BY-SA 3.0
2018-03-05T23:44:41.847Z
additionally, a lot of horrible Bash code for simpler scripts can be accomplished better with Makefiles. For beginners, you should aim to learn how to use these after you've become comfortable with basic shell scripting.
user5359531
CC BY-SA 3.0
2017-06-01T15:59:22.890Z
2018-03-02T00:21:03.057Z
2018-03-02T00:21:03.057Z
Karel Břinda
<p>The generic command <code>sh</code> is quite literally an industry standard, a POSIX standard, to be precise (IEEE 1003.2 and 1003.2a, available for purchase for hundreds of dollars at various websites). In theory, any script that starts with <code>#!/bin/sh</code> should conform to this standard. In practise, most Linux systems have a shell that is close to this standard, but has a few quirks and extensions.</p>

<p>Problems crop up when these quirks and extensions become standard practise in shell scripts. The Debian operating system changed to <code>dash</code> as their <code>sh</code> shell to encourage people to stop using "bashisms" in shell scripts that didn't specify a particular shell, i.e. those that began with <code>#!/bin/sh</code>. The <code>dash</code> shell tries to be as standards-compliant as possible:</p>

<blockquote>
  <p>dash is the standard command interpreter for the system.  The current version of dash is in the process of being changed to
       conform with the POSIX 1003.2 and 1003.2a specifications for the shell.  This version has many features which make it
       appear similar in some respects to the Korn shell, but it is not a Korn shell clone (see ksh(1)).  Only features designated
       by POSIX, plus a few Berkeley extensions, are being incorporated into this shell.  This man page is not intended to be a
       tutorial or a complete specification of the shell.</p>
</blockquote>

<p>I'm not familiar with the differences, and generally try to stick to the <code>sh</code> man pages to instruct me with regards to correct standards-compliant shell scripts.</p>

CC BY-SA 3.0
2017-06-02T14:31:12.610Z
Note that sh is not bash. Even on systems whose `/bin/sh` points to `bash`, being invoked as `sh` changes bash's behavior and causes it to run in POSIX-compliant mode. The "real" `sh` shell (bourne shell) is something else again and not the same as `bash` (bourne again shell).
terdon
CC BY-SA 3.0
2017-06-06T17:35:44.007Z
In Debian the default interactive shell, i.e. the one you'll be using on the command-line is bash https://wiki.debian.org/Shell yes `/bin/sh` will be symlinked to `/bin/dash` but the one people will be using live will be bash.
Matt Bashton
CC BY-SA 3.0
2017-06-02T03:42:33.323Z
2017-06-06T19:45:54.183Z
2017-06-06T19:45:54.183Z
gringer
<p>I would not say bash as a "standard", but it is indeed likely to be the most widely used unix shell and available by default on most modern unix/linux distros. There are a few other more convenient shells like <a href="http://www.zsh.org" rel="noreferrer">zsh</a> that are broadly compatible with <code>/bin/sh</code>, but they are not as widely available. There is also C-shell and in particular its open-source implementation <a href="https://en.wikipedia.org/wiki/Tcsh" rel="noreferrer">tcsh</a>. C-shell is quite different from bash. Over ten years ago, I saw it was used from time to time, but nowadays, I rarely see its use, except by programmers from older generations.</p>

CC BY-SA 3.0
2017-06-01T15:44:33.430Z
2017-06-01T15:44:33.430Z
user172818
<p><a href="http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/" rel="nofollow noreferrer">The Open Group Base Specifications Issue 7
IEEE Std 1003.1™-2008, 2016 Edition</a>, or "The POSIX Standard" for short, is the standard that defines the interfaces and utilities provided by a Unix system.  Among these is the command line shell language and tools (see "Shell &amp; Utilities" in the main index on the page linked above).</p>

<p>As far as I know, there is no shell that implement <em>exactly</em> what's specified by the standard, but both <code>bash</code> and <code>ksh93</code> does a pretty good job of adhering to the standard along with their own, sometimes conflicting, extensions. The <code>ksh93</code> shell in particular has had a big impact on the past development of the POSIX shell specification, but future POSIX specifications <em>may</em> borrow more from <code>bash</code> due to its wide use on Linux.</p>

<p>The <code>bash</code> shell is pretty much ubiquitous on Linux systems, and may be installed on all other Unices too. <code>ksh93</code> is also available for most Unices but is usually not installed by default on Linux. <code>ksh93</code> is available by default on at least macOS (as <code>ksh</code>) and Solaris.</p>

<p>If you are concerned about portability when writing a shell script (which is IMHO a good thing to be concerned about), you should make sure that you use only the POSIX utilities and their POSIX command line flags, as well as only use POSIX shell syntax. You should then ensure that you script is executed by <code>/bin/sh</code> which is supposed to be a shell that understands the POSIX specification.  <code>/bin/sh</code> is often implemented by <code>bash</code> running in "POSIX mode", but it may also be <code>dash</code>, <code>ash</code> or <code>pdksh</code> (or something else) depending on what Unix you are using.</p>

<p>For a Linux user, the most difficult bit in writing a portable script is often not the shell per se, but the multitude of non-standard command line flags provided by the GNU implementation of the many shell utilities.  The GNU coreutils (basic shell utilities) may, like <code>bash</code>, be installed on all Unices though.</p>

<p>Also note that <code>bash</code>, when running in POSIX mode (either when invoked as <code>/bin/sh</code> or with its <code>--posix</code> command line flag), is not <em>strict</em> about its POSIX conformance and may accept some syntax extensions to the POSIX standard.</p>

CC BY-SA 3.0
2017-06-02T06:54:02.307Z
2018-01-18T06:46:26.083Z
2018-01-18T06:46:26.083Z
Kusalananda
<p>As someone who's beginning to delve into bioinformatics, I'm noticing that like biology there are industry standards here, similar to Illumina in genomics and bowtie for alignment, many people use bash as shell. </p>

<p>Is using a shell besides bash going to cause issues for me?</p>

CC BY-SA 3.0
2017-06-01T16:41:52.620Z
I would adjust the examples you provided. Illumina is a standard for short reads, but there are many genomics labs working mostly with PacBio or Nanopore. Bowtie is hardly a standard. Even versions 1 and 2 are very different.
burger
CC BY-SA 3.0
2017-06-01T16:47:40.583Z
@burger what do you suggest then?
EMiller
CC BY-SA 3.0
2017-06-01T16:58:10.003Z
No suggestion. Although I agree with all the answers so far, bioinformatics is not good with standards. Even something like a SAM/BAM file that is technically a properly defined standard that almost everyone in genomics uses has many fields that are treated differently, causing issues for a lot of tools.
burger
CC BY-SA 3.0
2017-06-01T19:54:13.180Z
A statement "this is not meant to be opinionated" doesn't help much with such a broad question like this. Do you have a particular application that you would like to use a shell for, or an indication of what "industry" you're interested in?
gringer
CC BY-SA 3.0
2017-06-02T10:50:59.763Z
@burger: Do you have specific problematic SAM/BAM fields in mind?  You could raise issues at https://github.com/samtools/hts-specs/issues or at least this suggests another question to ask here…
John Marshall
CC BY-SA 3.0
2017-06-02T17:28:20.570Z
@JohnMarshall I don't think there is a "bug" with the SAM/BAM standard. It's just that it's open-ended and different tools require different fields. I have had to modify my BAM files many times in the past because some tool expected it in a slightly different format. Technically, it's still a valid BAM before and after, but one is compatible and one isn't. If you have a BAM, you have no idea if it will work with a tool that requires a BAM file.
burger
CC BY-SA 3.0
2017-06-03T17:12:35.343Z
@burger: If you want this situation to improve, you'll have to say which particular fields you have had to modify and what the various tools' expectations were. If you do this, specs can be clarified, tools can be modified, and everyone's bioinformatics pipelines can run a little more smoothly. Otherwise, it's just FUD.
John Marshall
<linux><shell>
Using shells other than bash
# Using shells other than bash

(Asked by: username_0 on 2017-06-01)

As someone who's beginning to delve into bioinformatics, I'm noticing that like biology there are industry standards here, similar to Illumina in genomics and bowtie for alignment, many people use bash as shell.

Is using a shell besides bash going to cause issues for me?

**Tags:** linux, shell
> **Comments:**
> **username_1**: I would adjust the examples you provided. Illumina is a standard for short reads, but there are many genomics labs working mostly with PacBio or Nanopore. Bowtie is hardly a standard. Even versions 1 and 2 are very different.  
> **username_0**: @burger what do you suggest then?  
> **username_1**: No suggestion. Although I agree with all the answers so far, bioinformatics is not good with standards. Even something like a SAM/BAM file that is technically a properly defined standard that almost everyone in genomics uses has many fields that are treated differently, causing issues for a lot of tools.  
> **username_2**: A statement "this is not meant to be opinionated" doesn't help much with such a broad question like this. Do you have a particular application that you would like to use a shell for, or an indication of what "industry" you're interested in?  
> **username_3**: @burger: Do you have specific problematic SAM/BAM fields in mind?  You could raise issues at https://github.com/samtools/hts-specs/issues or at least this suggests another question to ask here…  
> **username_1**: @JohnMarshall I don't think there is a "bug" with the SAM/BAM standard. It's just that it's open-ended and different tools require different fields. I have had to modify my BAM files many times in the past because some tool expected it in a slightly different format. Technically, it's still a valid BAM before and after, but one is compatible and one isn't. If you have a BAM, you have no idea if it will work with a tool that requires a BAM file.  
> **username_3**: @burger: If you want this situation to improve, you'll have to say which particular fields you have had to modify and what the various tools' expectations were. If you do this, specs can be clarified, tools can be modified, and everyone's bioinformatics pipelines can run a little more smoothly. Otherwise, it's just FUD.  

---

## 5 answers

### Answer by username_3 on 2017-06-01. Score: 18 | Accepted answer

Bioinformatics tools written in shell and other shell scripts generally specify the shell they want to use (via #!/bin/sh or e.g. #!/bin/bash if it matters), so won't be affected by your choice of user shell.
If you are writing significant shell scripts yourself, there are reasons to do it in a Bourne-style shell.  See Csh Programming Considered Harmful and other essays/polemics.
A Bourne-style shell is pretty much the industry standard, and if you choose a substantially different shell you'll have to translate some of the documentation of your bioinformatics tools.  It's not uncommon to have things like

Set some variables pointing at reference data and add the script to your PATH to run it:
export FOO_REF=/path/to/stuff
export PATH=/path/to/foo-x.y:$PATH
foo blah blah


These will typically be shown in Bourne-shell syntax.  By using a different shell you have to translate the export commands to your local syntax, and especially PATH munging is somewhat shell-dependent.
If you're experienced in Unix, this will be only a minor niggle.  If you're a beginner, IMHO this will add a non-negligible amount of friction on top of all the other things you're learning.

> **Comments:**
> **username_4**: **Do not** use `#!/bin/bash` in the shebang. Having Bash installed in a nonstandard location is common enough that doing so will break often. Use `#!/usr/bin/env bash` instead, it should have no disadvantage.  

---

### Answer by username_5 on 2017-06-01. Score: 11

**TL;DR**

SH adheres to an official industry standard, but it is not suitable for scientific computing. Bash is considered an informal standard (e.g., by Google). Bash 3 is preferable in most of situations in the world of bioinformatics.

**Long answer**

As already described in other answers, SH (`/bin/sh`, plain Bourne shell, the original UNIX shell) should fully adhere to POSIX which is a real industry standard. However, SH is too limited for scientific computing since many key features were incorporated later in SH successors, especially in Bash (`/bin/bash`, Bourne Again Shell): `set -o pipefail`, `[[ ... ]]`, or process substitutions `< ()` to name at least few.

In practice, it is much more difficult to write "safe" scripts in pure SH and only shell experts are usually capable to prevent unexpected behavior. For example, it may be hard to ensure that no command in a pipeline failed in the middle of computation. For Bash, various easy-to-follow defensive-programming recommendations have been developed and they should prevent all these problems. From this reason, many computer scientists, software engineers and companies use Bash as a kind of a standard. For instance, Google internal policy allows [only Bash](https://google.github.io/styleguide/shell.xml?showone=Which_Shell_to_Use#Which_Shell_to_Use) for writing any shell scripts.

Even though we cannot expect that Bash is present on completely every Unix machine (e.g., on mobile devices as @terdon pointed out), a vast majority of \*nix machines used for scientific computation should have it. We also should be aware of the fact that Bash can be slower than SH and that it has recently suffered from major [security issues](https://www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability). Moreover, various Bash versions exist and scripts working on modern Linux machines with [Bash 4](http://wiki.bash-hackers.org/bash4) might not work on OS X, which is still based on Bash 3.

To sum up, Bash 3 is probably be the most reasonable choice for scientific computing.

**Edit**

I addressed the comments from @terdon and @John Marshall. In particular, I added an explanation why Bash is more suitable for scientific computing than SH (in my opinion).

> **Comments:**
> **username_6**: Bash is not present in every Unix machine, `sh` is and that is not the same. Yes, Linux tends to have `/bin/sh` pointing to bash, but Linux is not Unix and, anyway, even in Linux `/bin/sh` is not always `bash` (Debian based systems use dash instead, for example). You can safely expect the Bourne shell (sh) to be present on a POSIX-compliant system, but not necessarily the Bourne again shell (bash).  
> **username_5**: @terdon Could you provide any reference, please? According to https://wiki.debian.org/Bash, bash is the default shell on Debian. Do you know about any (modern) *nix distro where bash would not be installed?  
> **username_5**: @terdon I will answer my question – e.g., FreeBSD. https://www.freebsd.org/doc/en/articles/linux-users/shells.html says that "Bash is not included in the default installation". Do you have an example of a Linux distribution without bash?  
> **username_6**: Some (all?) embedded Linux systems won't have bash and will instead have busybox sh. The main issue is that people tend to think that `sh` and `bash` are the same thing but they aren't. They are similar and bash is an extension of sh, but they are not the same.  
> **username_3**: @Karel: Asking about the “default shell” is ambiguous. As per https://wiki.debian.org/Shell, these days on Debian the default `/bin/sh` is dash while the default login shell (as listed in `/etc/passwd`) remains `/bin/bash`. This means that portable shell scripts that identify themselves with `#!/bin/sh` need to restrict themselves to POSIX shell facilities, while scripts that want to use bash extensions need to use `#!/bin/bash`.  This got tidied up the hard way a few years ago when various distributions switched to dash for `/bin/sh`…  
> **username_5**: @terdon @John Marshall Thank you for your comments. Compared to bash, I consider "pure" sh very limited and inappropriate for scientific computing, in particular because of some missing, but very important, features such as `set -o pipefail` or `[[ ... ]]`. My experience is that sh scripts can be very susceptible to unexpected behavior (unless the developer is a shell expert, which is usually not the case in bioinformatics). Several good and simple defensive programming strategies for scientific computing exist for bash.  
> **username_5**: This is why I would like to know whether `/bin/bash` might not return anything, or return a non-bash shell (I have seen such a problem only once with some obscure bioinformatics distribution).  
> **username_7**: I wouldn't do "scientific computing" in a shell no matter what shell it was. The shell should be used for, at most, handling the plumbing for basic utilities and applications. Computing should be handled by utilities and applications designed for those tasks.  
> **username_5**: @Kusalananda  How do you do scientific computing without shell? I believe that you use it at least for running your programs. If it is so, do you agree that the way how it handles errors matters?  
> **username_7**: @Karel I wouldn't do computing of any kind _without_ a shell, but not _in_ (with) a shell.  
> **username_4**: I’m a bit puzzled why this answer recommends the ancient Bash 3 instead of Bash 4, which itself is now almost 10 years old (announced in 2009). Bash 3 lacks crucial features such as associative arrays so it’s a severe restriction. True, macOS still ships with Bash 3 but so what? macOS is generally known to lag behind in its unix tools (and even for its Ruby and Python). Also, nitpick: it’s “Bash”, not “BASH”.  
> **username_5**: @KonradRudolph Thank you for the comment. I fixed the capitalization issue. Concerning Bash 4, I completely agree that it has many useful features. However, if it cannot be used on a substantial proportion of machines, it's a fatal problem. Whereas Python 3 can be easily installed (e.g., using Conda), upgrading Bash is complicated and easily results in serious problems. As for the associative arrays, the Google standard says the following: "If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python."  
> **username_4**: @Karel I have a few choice word for the Google coding guidelines, none of which are acceptable in polite company. Anyway, upgrading Bash is actually trivial. Replacing it for the *login shell* may not be but in practice that’s unnecessary: on macOS you specify the shell in the terminal app, and other systems ship with Bash 4.  
> **username_8**: strongly agree with @Kusalananda, trying to write your pipelines entirely *in* shell is a mistake. There are plenty of [workflow frameworks](https://github.com/common-workflow-language/common-workflow-language/wiki/Existing-Workflow-systems); I am partial to Nextflow, and a lot of my peers use Snakemake. Entirely shell-based pipelines quickly become unmanageable, overly complex, confusing to understand, and extremely difficult to debug. If you *must* use Bash, then you should aim for POSIX compliant implementations.  
> **username_8**: additionally, a lot of horrible Bash code for simpler scripts can be accomplished better with Makefiles. For beginners, you should aim to learn how to use these after you've become comfortable with basic shell scripting.  

---

### Answer by username_7 on 2017-06-02. Score: 7

[The Open Group Base Specifications Issue 7
IEEE Std 1003.1™-2008, 2016 Edition](http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/), or "The POSIX Standard" for short, is the standard that defines the interfaces and utilities provided by a Unix system. Among these is the command line shell language and tools (see "Shell & Utilities" in the main index on the page linked above).

As far as I know, there is no shell that implement *exactly* what's specified by the standard, but both `bash` and `ksh93` does a pretty good job of adhering to the standard along with their own, sometimes conflicting, extensions. The `ksh93` shell in particular has had a big impact on the past development of the POSIX shell specification, but future POSIX specifications *may* borrow more from `bash` due to its wide use on Linux.

The `bash` shell is pretty much ubiquitous on Linux systems, and may be installed on all other Unices too. `ksh93` is also available for most Unices but is usually not installed by default on Linux. `ksh93` is available by default on at least macOS (as `ksh`) and Solaris.

If you are concerned about portability when writing a shell script (which is IMHO a good thing to be concerned about), you should make sure that you use only the POSIX utilities and their POSIX command line flags, as well as only use POSIX shell syntax. You should then ensure that you script is executed by `/bin/sh` which is supposed to be a shell that understands the POSIX specification. `/bin/sh` is often implemented by `bash` running in "POSIX mode", but it may also be `dash`, `ash` or `pdksh` (or something else) depending on what Unix you are using.

For a Linux user, the most difficult bit in writing a portable script is often not the shell per se, but the multitude of non-standard command line flags provided by the GNU implementation of the many shell utilities. The GNU coreutils (basic shell utilities) may, like `bash`, be installed on all Unices though.

Also note that `bash`, when running in POSIX mode (either when invoked as `/bin/sh` or with its `--posix` command line flag), is not *strict* about its POSIX conformance and may accept some syntax extensions to the POSIX standard.


---

### Answer by username_2 on 2017-06-02. Score: 5

The generic command `sh` is quite literally an industry standard, a POSIX standard, to be precise (IEEE 1003.2 and 1003.2a, available for purchase for hundreds of dollars at various websites). In theory, any script that starts with `#!/bin/sh` should conform to this standard. In practise, most Linux systems have a shell that is close to this standard, but has a few quirks and extensions.

Problems crop up when these quirks and extensions become standard practise in shell scripts. The Debian operating system changed to `dash` as their `sh` shell to encourage people to stop using "bashisms" in shell scripts that didn't specify a particular shell, i.e. those that began with `#!/bin/sh`. The `dash` shell tries to be as standards-compliant as possible:

> dash is the standard command interpreter for the system. The current version of dash is in the process of being changed to
> conform with the POSIX 1003.2 and 1003.2a specifications for the shell. This version has many features which make it
> appear similar in some respects to the Korn shell, but it is not a Korn shell clone (see ksh(1)). Only features designated
> by POSIX, plus a few Berkeley extensions, are being incorporated into this shell. This man page is not intended to be a
> tutorial or a complete specification of the shell.

I'm not familiar with the differences, and generally try to stick to the `sh` man pages to instruct me with regards to correct standards-compliant shell scripts.

> **Comments:**
> **username_6**: Note that sh is not bash. Even on systems whose `/bin/sh` points to `bash`, being invoked as `sh` changes bash's behavior and causes it to run in POSIX-compliant mode. The "real" `sh` shell (bourne shell) is something else again and not the same as `bash` (bourne again shell).  
> **username_9**: In Debian the default interactive shell, i.e. the one you'll be using on the command-line is bash https://wiki.debian.org/Shell yes `/bin/sh` will be symlinked to `/bin/dash` but the one people will be using live will be bash.  

---

### Answer by username_10 on 2017-06-01. Score: 5

I would not say bash as a "standard", but it is indeed likely to be the most widely used unix shell and available by default on most modern unix/linux distros. There are a few other more convenient shells like [zsh](http://www.zsh.org) that are broadly compatible with `/bin/sh`, but they are not as widely available. There is also C-shell and in particular its open-source implementation [tcsh](https://en.wikipedia.org/wiki/Tcsh). C-shell is quite different from bash. Over ten years ago, I saw it was used from time to time, but nowadays, I rarely see its use, except by programmers from older generations.


---

