Currently in 5.1 the shell wrapper is like this:

# Pass in the path to php so that drush knows which one
# to use if it re-launches itself to run subcommands.  We
# will also pass php options if any are defined.
if [ -z "$php_options" ] ; then
  exec "$php" $php_options "$SCRIPT_PATH" --php="$php" "$@"
else
  exec "$php" $php_options "$SCRIPT_PATH" --php="$php" --php-options="$php_options" "$@"
fi

Quoting the command string doesn't work on Bash or MacOS. Not sure why it was set up like that but it fails pretty much always. I believe we should nix the quotes from "$php" at the first part of the exec.

CommentFileSizeAuthor
#1 exec-quotes-1559556-1.patch552 bytesjoshk

Comments

joshk’s picture

joshk commented
StatusFileSize
new exec-quotes-1559556-1.patch552 bytes

Patch

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Postponed (maintainer needs more info)

I'm afraid that I don't understand your report. Quoting the $php is necessary if there are spaces in the path to PHP. Lots of people use Drush on Bash and on MacOS, so I would have to say that the quoting is, generally speaking, functional. Could you be more specific about the problem you are having?

joshk’s picture

joshk commented

Quoting the $php is necessary if there are spaces in the path to PHP.

That's not the case. I have a custom $php value so I can specify a different ini file. Previous versions of Drush have always worked fine and there is no problem with passing a longer command to exec(). However, quoting something that is not a simple executable will cause it to fail.

Try this simple script:

#!/usr/bin/env sh

# Doesn't work
exec "php -i"

# Works, sort of
exec "php" -i

This will give you "./test.sh: line 4: exec: php -i: not found" every time, just like Drush 5.1 does (though on line 87). This fails reliably on my MacOS and Linux (fedora) environments now.

I think if you don't have any extra values to pass to $php then this works, though it causes the calling session to fail immediately, which I don't think is intentional. Adding anything (e.g. a path to a ini file, the -q option) causes it to fail with "the not found." This seems to be opposite of what we're trying to achieve.

What is an example of a $php that prompted you to add the quotes?

joshk’s picture

joshk commented

Looks like this was added recently here:

http://drupalcode.org/project/drush.git/commit/8b8cc5a54bfb13554ef488295...

It looks like this change was introduced for better windows support, and not thoroughly tested under other architectures where additional PHP arguments are used.

I'll try and idle in #drush to help explain further.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

I understand your position. It is true that past versions of Drush allowed you to attach options to the php path in the $php variable; however, Drush-5 (and Drush-4) no longer supports this. If you want to pass additional options to php when running Drush, you must use the drush.ini feature, or put your php.ini file someplace Drush will find it (e.g. $HOME/.drush).

greg.1.anderson’s picture

greg.1.anderson commented

c.f. #1195132: there should be some way to specify custom php.ini values when drush is called