On Nov 14, 2013, at 12:21 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
On Thu, Nov 14, 2013 at 5:13 PM, Nate Coraor <nate@bx.psu.edu> wrote:
Bash is easily obtained on these systems and I think the extra functionality available in post-Bourne shells ought to be allowed. I also question how many people are going to run tools on *BSD since most underlying analysis tools tend to only target Linux.
So could bash be declared an expected Galaxy dependency? i.e. The core system libraries and tools which Tool Authors may assume, and which Galaxy Administrators should install?
It’s my opinion that it could. I’ll start a discussion about this shortly so we can hammer out the rest.
That said, shell code should be restricted to Bourne-compatible syntax whenever there’s no good reason to use non-Bourne features, e.g. if all you’re doing is `export FOO=foo`, you should not be forcing the use of bash. In cases where bash really is required (say, you’re using arrays), the script should explicitly specify '#!/bin/bash' (or '#!/usr/bin/env bash'?) rather than '#!/bin/sh'.
I agree that any shell script (e.g. a tool wrapper) which is bash specific should say that in the hash-bang line, rather than '#!/bin/sh'.
What about command line magic like -num_threads \${GALAXY_SLOTS:-8} in a <command> tag using bash specific environment variable default values?
${FOO:-default} is, surprisingly, Bourne-compatible.
What about bash specific if statements in <action type="shell_command"> sections of a tool_dependencies.xml file (which is what the BLAST+ packages currently use on the main Tool Shed, pending an update to use arch/os specific tags as tested on the Test Tool Shed)?
This is a bit tricker, since there’s currently no way to specify installation actions to run on a system other than the Galaxy application server. However, if we are saying that bash should be available to tools, I’d think there is no reason to say that it’s not expected to be available to tool installation. Unfortunately, I believe the current installation methods use subprocesses’ default, which is sh, which is not going to be bash on some systems (on Debian, it’s dash). —nate
Peter