1

For some reason, I cannot get AppleScript's "do shell script" to use the latest (GPLv3) Bash:

do shell script "/usr/local/bin/bash; echo $BASH_VERSION"
-- Result: "3.2.57(1)-release"

Strangely, it does work with an external .sh script:

#!/usr/local/bin/bash
echo $BASH_VERSION

Calling it like:

do shell script "~/Library/Scripts/Script.sh"
-- Result: "5.0.17(1)-release"

What's the difference and can I get it to work inside the .scpt script as well?

  • The first one doesn't issue the echo $BASH_VERSION in the sub shell you created. Whereas the scripts have the she-bang that specifies exactly which shell to execute the code in. – Allan Apr 26 at 18:43
  • @Allan I'm still not sure if my issue can be solved then. Can I get the subshell inside my .scpt file to use the latest Bash? – Daan Apr 26 at 19:18
  • @abc I'm getting some errors but I don't think that works. – Daan Apr 26 at 19:19
  • You should be able to, but remember, if you've changed your environment path, for the GUI, you probably need to log out/in for it to get the changes. Confirm it by do shell script "echo $PATH" and see if it has the new values before logging out and then again after logging back in. – Allan Apr 26 at 19:33
  • @Daan what errors are you getting? – airsquared Apr 26 at 19:35
1

do shell script always uses /bin/sh, even if your default shell, shebang, or $PATH variable is set to something else.

To force it to use a different shell, you will need to call that shell. To run a command in bash, use the argument -c:

/usr/local/bin/bash -c 'echo $BASH_VERSION'

If you only want to run a single bash script, you can omit the -c with: /usr/local/bin/bash /path/to/script.bash


In AppleScript:

do shell script "/usr/local/bin/bash -c 'echo $BASH_VERSION'"

The man page entry for bash -c:

-c command_string

If the -c option is present, then commands are read from the first non-option argument command_string.

| improve this answer | |
  • It's good to run do shell script "set" just by itself to see what's available by default when shelling out. – user3439894 Apr 26 at 20:17
  • Thank you, that works. My confusion was caused by the fact that I see things like do shell script "/bin/tcsh my-command-file-path" (from an Apple doc), which made me think that it works the same for direct commands. Isn't the shell specifier redundant to begin with if you use a shebang in the external script file? – Daan Apr 26 at 21:43
  • It will ignore the shebang because it will attempt to execute the script using /bin/sh instead of treating the script like an executable. If you want to run only a bash script (not a command) you can just use do shell script "/usr/local/bin/bash /full/path/to/script.bash" – airsquared Apr 26 at 21:53
  • Alright. But if my script is already an executable (which it needs to be) with the shebang I can just do something like do shell script "~/Library/Scripts/Script.sh" right? I'll probably go for that option. – Daan Apr 26 at 21:56
  • 1
    Yeah, odd. You're sure your script is executable? I've set it to chmod u+x. – Daan Apr 28 at 11:01
0

In your shell scripts, you should use #!/usr/bin/env bash.

Why?

It will use the bash that you've specified in your $PATH because the /bin/bash may be entirely different than the bash in /usr/local/bin/bash that you installed after the fact.

To ensure that you "get" the correct bash version, make sure that it's directory precedes the original in your path statement. For instance, if it's located in /opt/local/bin, your path may look something like this:

/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
| improve this answer | |
  • Thank you - useful to know. I've changed my scripts with this line. Indeed, I have the paths saved in /etc/paths with /usr/local/bin as the first line. – Daan Apr 26 at 19:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .