[com***@mule modules]$ drush pm install token

Parse error: syntax error, unexpected T_VARIABLE in /var/www/html/sites/all/modules/drupalforfirebug/drupalforfirebug_preprocess.module on line 30
[com****@mule modules]$

I get errors like this for lots of modules. Before I installed the DFF module, it was only happening in modules I had written myself, in /sites/default/modules, but disabling these fixes it. However, there is nothing wrong with any of these modules and I cannot explain why this is happening.

Suffice to say it breaks Drush quite horribly, as I can't use a lot of the functionality.

Comments

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Postponed (maintainer needs more info)

The error discusses a parse error in DFF in /drupalforfirebug_preprocess.module on line 30. Your first step is to fix the parse error. I don't think this is related to drush.

niklp’s picture

niklp commented

I will double check, but my point was more related to the fact that it happens with *lots* of modules. All of these modules work perfectly normally other than they cause this particular error under drush.

A parsing error of this nature would cause php to fatal under normal circumstances for this particular module's error ... right? But it works perfectly otherwise. Unless there is something I'm missing about parsing errors...

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
commented

Have you checked your watchdog log ... my guess this is filled with errors?

Using drush will show these errors immediate but on your website you have to check watchdog or set the error level with devel module different.

Frando’s picture

Frando commented

Also, check if your CLI's ph is the same version as your webserver's. Maybe you're having PHP 4.x running on the command line, and 5 on the webserver and therefore getting parse errors for php5-only code in modules.

niklp’s picture

niklp commented

That's an awesome point, which I'd never have thought of.

A simple "php -v" on the CLI reveals the following: 

PHP 4.4.8 (cli) (built: Jan 25 2008 23:47:10)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Awesome. How do I make the CLI use php 5 tho...?

Frando’s picture

Frando commented

Depends on your system/distribution, I'd say.
On Debian and relatives there's a package php5-cli IIRC.

Frando’s picture

Frando commented
Category: bug » support
Status: Postponed (maintainer needs more info) » Fixed
niklp’s picture

niklp commented

The answer turned out to be pretty simple, and took me about 4 seconds to test and half a minute to implement...

[*******@****** modules]$ php5 -v
PHP 5.2.5 (cli) (built: Jan 25 2008 23:50:42)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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

niklp’s picture

niklp commented

I should say that I changed the hash bang line in drush.php to point to the other version of php5 - this works, but I get a lot of "headers already sent" errors... :/