text: user33: 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?
  
  user37: 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 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. 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.
  
  user73: 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.
  
  user434: The Open Group Base Specifications Issue 7
  IEEE Std 1003.1™-2008, 2016 Edition, 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.
  
  user425: 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 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. Moreover, various Bash versions exist and scripts working on modern Linux machines with Bash 4 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).
  
  user134: 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.
  
original_text: 33: <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>
   37: <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>
   73: <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>
   434: <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>
   425: <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>
   134: <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>
  