0

We have a special server that runs php5.x and relies on drush 5.x. PHP 7.0 is installed, but the sites on the server all run PHP5, because PHP7 breaks them.

We have previously had drush 5 on it, but it didn't work anymore for some reason. So what I did was download drush 5, and and made an alias like so:

alias drush5="/usr/bin/php5 /home/user/drush/drush5/drush"

Running drush5 does result in listing the commands, so I have done something right. But whenever I run drush5 up module_name, instead of actually running the update php script, it prints its code out. Example below.

Instead of returning with an error or actually running the script, it just prints out the code. What do I do in this case? I cannot find anything on this on neither google nor duckduckgo.

server:/var/www/site/webroot# drush5 up module_name
# $Id$
#
# This script is a simple wrapper that will run Drush with the most appropriate
# php executable it can find.
#
# Solaris users: Add /usr/xpg4/bin to the head of your PATH
#

# Get the absolute path of this executable
SELF_DIRNAME="`dirname -- "$0"`"
SELF_PATH="`cd -P -- "$SELF_DIRNAME" && pwd -P`/`basename -- "$0"`"

# Decide if we are running a Unix shell on Windows
if [ `which uname` ]; then
  case "`uname -a`" in
    CYGWIN*)
      CYGWIN=1 ;;
    MINGW*)
      MINGW=1 ;;
  esac
fi

# Resolve symlinks - this is the equivalent of "readlink -f", but also works with non-standard OS X readlink.
while [ -h "$SELF_PATH" ]; do
    # 1) cd to directory of the symlink
    # 2) cd to the directory of where the symlink points
    # 3) Get the pwd
    # 4) Append the basename
    DIR="`dirname -- "$SELF_PATH"`"
    SYM="`readlink $SELF_PATH`"
    SYM_DIRNAME="`dirname -- "$SYM"`"
    SELF_PATH="`cd "$DIR" && cd "$SYM_DIRNAME" && pwd`/`basename -- "$SYM"`"
done

# Build the path to drush.php.
SCRIPT_PATH="`dirname "$SELF_PATH"`/drush.php"
if [ -n "$CYGWIN" ] ; then
  SCRIPT_PATH="`cygpath -w -a -- "$SCRIPT_PATH"`"
fi

# If not exported, try to determine and export the number of columns.
# We do not want to run `tput cols` if $TERM is empty or "dumb", because
# if we do, tput will output an undesirable error message to stderr.  If
# we redirect stderr in any way, e.g. `tput cols 2>/dev/null`, then the
# error message is suppressed, but tput cols becomes confused about the
# terminal and prints out the default value (80).
if [ -z $COLUMNS ] && [ -n "$TERM" ] && [ "$TERM" != dumb ] && [ -n "`which tput`" ] ; then
  # Note to cygwin/mingw/msys users: install the ncurses package to get tput command.
  # Note to mingw/msys users: there is no precompiled ncurses package.
  if COLUMNS="`tput cols`"; then
    export COLUMNS
  fi
fi

if [ -n "$DRUSH_PHP" ] ; then
  # Use the DRUSH_PHP environment variable if it is available.
  php="$DRUSH_PHP"
else
  # On MSYSGIT, we need to use "php", not the full path to php
  if [ -n "$MINGW" ] ; then
    php="php"
  else
    # Default to using the php that we find on the PATH.
    # We check for a command line (cli) version of php, and if found use that.
    # Note that we need the full path to php here for Dreamhost, which behaves oddly.  See http://drupal.org/node/662926
    php="`which php-cli 2>/dev/null`"

    if [ ! -x "$php" ]; then
      php="`which php 2>/dev/null`"
    fi

    if [ ! -x "$php" ]; then
      echo "ERROR: can't find php."; exit 1
    fi
  fi
fi

# Check to see if the user has provided a php.ini file or drush.ini file in any conf dir
# Last found wins, so search in reverse priority order
for conf_dir in "`dirname "$SELF_PATH"`" /etc/drush "$HOME/.drush" ; do
  if [ ! -d "$conf_dir" ] ; then
    continue
  fi
  # Handle paths that don't start with a drive letter on MinGW shell. Equivalent to cygpath on Cygwin.
  if [ -n "$MINGW" ] ; then
    conf_dir=`sh -c "cd "$conf_dir"; pwd -W"`
  fi
  if [ -f "$conf_dir/php.ini" ] ; then
    drush_php_ini="$conf_dir/php.ini"
  fi
  if [ -f "$conf_dir/drush.ini" ] ; then
    drush_php_override="$conf_dir/drush.ini"
  fi
done
# If the PHP_INI environment variable is specified, then tell
# php to use the php.ini file that it specifies.
if [ -n "$PHP_INI" ] ; then
  drush_php_ini="$PHP_INI"
fi
# If the DRUSH_INI environment variable is specified, then
# extract all ini variable assignments from it and convert
# them into php '-d' options. These will override similarly-named
# options in the php.ini file
if [ -n "$DRUSH_INI" ] ; then
  drush_php_override="$DRUSH_INI"
fi

# Add in the php file location and/or the php override variables as appropriate
if [ -n "$drush_php_ini" ] ; then
  php_options="--php-ini $drush_php_ini"
fi
if [ -n "$drush_php_override" ] ; then
  php_options=`grep '^[a-z_A-Z0-9.]\+ *=' $drush_php_override | sed -e 's|\([^ =]*\) *= *\(.*\)|\1="\2"|' -e 's| ||g' -e 's|^|-d |' | tr '\n\r' '  '`
fi
# If the PHP_OPTIONS environment variable is specified, then
# its contents will be passed to php on the command line as
# additional options to use.
if [ -n "$PHP_OPTIONS" ] ; then
  php_options="$php_options $PHP_OPTIONS"
fi

# Always disable magic_quotes_gpc and friends
php_options="$php_options -d magic_quotes_gpc=Off -d magic_quotes_runtime=Off -d magic_quotes_sybase=Off"

# 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 in the php options.
# Important note: Any options added here must be removed  when Drush processes
# a #! (shebang) script.  @see drush_adjust_args_if_shebang_script()
exec "$php" $php_options "$SCRIPT_PATH" --php="$php" --php-options="$php_options" "$@"

| improve this question | | | | |
  • 2
    With what version of Drupal? Sounds a little bit like you are running your site in an undesirable setup. No one should recommend you any workaround except: Fix the issues that break your site on PHP7. And update Drush to a supported and recommended version. See the compatibility chart. – leymannx Dec 9 '19 at 10:14
  • 1
    It's a drupal 7.67. It is an undesirable setup, that I am aware of. The problem lies on the fact that customer does not wish to pay to update their modules to support newer versions of php, so we're stuck with this, unfortunately. – OH MY DEAR PUFFINS Dec 9 '19 at 12:25
1

I found a solution to this.

NOTE: This way is NOT recommended. Get your modules updated to support at least PHP 7.3!

  1. wget https://github.com/drush-ops/drush/archive/5.10.0.tar.gz or if you'd rather want a zip file: wget https://github.com/drush-ops/drush/archive/5.10.0.zip.
  2. Uncompress downloaded file: tar -zxvf 5.10.0.tar.gz or with zip unzip 5.10.0.zip
  3. Move to a drush folder, in case you have multiple versions: mv 5.10.0 /path/to/drushes/drush5
  4. Make a symlink into your path and name it "drush5" ln -s /path/to/drushes/drush5/drush /usr/local/bin/drush5
  5. Move to your document root cd /path/to/docroot/
  6. And run drush5 there: drush5 up module_name

In my case, PHP CLI ran PHP 7.0 which appeared to work for drush5, but apparently not for the sites. I find this very peculiar, but as mentioned in one of the comments, the setup is undesirable.

This should be a temporary solution if this is strictly needed. Make sure to keep your drupal sites and modules up to date with newer PHP version (At the time of writing, at least PHP7.3); not only will this make your site better, but it will make developers and operators happy, because of ease of maintenance.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.