After installing Drush I get this error:

melissa/bin/drush/drush: syntax error at line 9: `ORIGDIR=$' unexpected

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greg.1.anderson’s picture

Status: Active » Postponed (maintainer needs more info)

That's hard to say. Try changing the first line of the drush script to:

#!/usr/bin/env bash

It that doesn't help, we'll need more info on your setup.

Melissamcewen’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

So this server admin informs me that "Our php cli version is too old for the newest version of drush." So if anyone else has this problem, it's probably caused be that.

greg.1.anderson’s picture

Drush will run on php 5.2; your problem is happening before php is executed.

Try running php + drush.php directly:

/path/to/php /path/to/drush/drush.php --php=/path/to/php status

Also, php -version to determine that you have at least php 5.2.

d.walter’s picture

Version: All-versions-3.0 »
Component: Installation » Miscellaneous
Status: Closed (fixed) » Active

I am having exactly the same problem. I can't run Drush because of this. Neither of the solutions suggested here worked for me. I tried 7.x-4.5 as well as 7.x-5.0-rc2 and get the same error code for both.
Can anybody help? Thank you.
[I hope it is OK to reopen this. I am new here, my apologies if I am doing something wrong.]

greg.1.anderson’s picture

Sure, reopening is fine. Drush is failing on the first line of the bash script, which probably means that you are running it with some shell other than bash. Did you try the change suggested in #1? How about #3?

d.walter’s picture

Thank you for the reply. Yes, I followed both suggestions literally: neither solved the problem.

"which probably means that you are running it with some shell other than bash"

I am afraid I have no idea what that means. I followed the manual installation instructions because I could not get the recommended installation process (using pear) to work either. I also had problems creating the symbolic link there. But in the end it seems I could start Drush, only it fails with the error message quoted by the original poster.

Is there anything I can do to find out what the problem is?

Thank you!

greg.1.anderson’s picture

Category: bug » support
Status: Active » Fixed

Drush requires bash (or, on Windows, Powershell, DOS or Msysgit). I'm sorry that I cannot debug your environment or tell you what you are running.

d.walter’s picture

It seems I can actually run Bash (v. 3.2), but even using that Drush still fails with the same error code. I am giving it up. Thank you for taking the time to reply.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

LuCarD’s picture

Status: Closed (fixed) » Active

I am re-opening this ticket... With some additional information and possible fixes.

This happens on system which have non-POSIX-compatible bourne-shells. These systems don't support the $( ) for commands and only support the ` ` option. There are still live systems which are being released with this kind of shell. ( for example SunOS, this might be configuration setting ).

The simple way to solve this is by using ` ` instead of $( ).

Small note: PEAR is also using ` ` in their shell script.

laurentchardin’s picture

+1 on what LuCarD is reporting.

I am currently testing the drush script on Solaris (SunOS 5.10) and having the same issue.
On solaris, i had to switch /bin/sh to /bin/bash to make it work.

greg.1.anderson’s picture

We could fix this with ``, as suggested in #10, but if it would also work for most folks to switch from /bin/sh to /bin/bash, I would prefer to do that. Any opinions on that? bash is available on Linux, BSD, SunOS; maybe it is prevalent enough to depend on.

greg.1.anderson’s picture

greg.1.anderson’s picture

greg.1.anderson’s picture

Title: ORIGDIR=$' unexpected » Make drush script more compatible with non-POSIX shells [ORIGDIR=$' unexpected]
FileSize
2.83 KB

Here is a patch that switches from $() to ``, and also fixes issues identified in the issues linked to in #13 and #14. Works fine on Linux; would be nice to have feedback from Solaris, Mac and Windows users.

laurentchardin’s picture

I will test this patch and give you a feedback on Solaris.
But there is something that does not work for sure on Solaris is:

   # We check for a command line (cli) version of php, and if found use that.
   which php-cli >/dev/null 2>&1
   if [ "$?" = 0 ] ; then
    php=`which php-cli`
   fi

which php-cli will always return 0, even if php-cli does not exists.
A workaround would be to use 'whereis' or 'type' instead of 'which'.

I don't know which one is the most supported. Or have a special case (huh!) for solaris.

greg.1.anderson’s picture

Status: Active » Needs review
FileSize
2.9 KB

Here is a new version that addresses which php-cli per #16.

laurentchardin’s picture

About #17 on Solaris.

First thing i change locally: for solaris guys, they need to be sure to put /usr/xpg4/bin in their PATH before /usr/bin.
A more POSIX compliant shell will be used instead of the default one. And that way, i didn't need to change the shebang to bash anymore.

Next, on the PHPCLI, the trick didn't make it, since Solaris has the pleasant idea to actually display a message:

$which php-cli
no php-cli in /opt/csw/bin /usr/local/bin/ /usr/bin /bin

So the message gets stored in the variable.

I remember reading somewhere that the POSIX way would be to test: php-cli -v and check for return code > 0. (Should be 127 in this case).

This could look like:

  # We check for a command line (cli) version of php, and if found use that.
  php-cli -v > /dev/null 2>&1
  if [ "$?" = 0 ] ; then
    php="`which php-cli`"
  fi

this will fail if anybody use the -e flag on the shebang however.
The trick works for me so far, changed over the #17 patch.

One last thing, Solaris does not support unified patch, and i don't have the GNU version on the server i'm working on (no root access).
Had to modify it by hand, that was fun.

Thank you

greg.1.anderson’s picture

FileSize
2.9 KB

Here is a version that uses php-cli -v. Still working okay on Linux.

greg.1.anderson’s picture

FileSize
3.07 KB

Tested on Windows with msysgit, and found to be working (once a couple minor adjustments were made, attached).

So, now works on Linux, Windows, and (presumably) Solaris. Needs Mac testing. Should be committed after Drush-5.7 is released, so it has some time to live in dev before going into a stable release.

greg.1.anderson’s picture

Category: support » bug

Fixing category; not a support request.

laurentchardin’s picture

Category: bug » support

Greg, i don't see you have integrated 'php-cli -v' check or #19 nor 20. Did you remove it ?

greg.1.anderson’s picture

Status: Needs review » Needs work

Wrong patch in #20. :p

greg.1.anderson’s picture

Status: Needs work » Needs review
FileSize
3.45 KB

Here is the right one.

laurentchardin’s picture

So far so good. script is ok for me on solaris (10) and macosx.

To sum up, for solaris, adding /usr/xpg4/bin in the $PATH before any others is mandatory (so that the posix compliant shell is used).

greg.1.anderson’s picture

Status: Needs review » Fixed

Drush 5.7 has been released, so committed this to master. Please re-open if any problems are discovered.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

LuCarD’s picture

This patch is in the master repository but not in the release on the drupal site or pear ?

greg.1.anderson’s picture

This will be in Drush 5.8.