Drush error on verbose flag “: in (line of ).”

Please confirm on HEAD drush before reporting issues.

Doesn't look like 3.3; looks like HEAD, post-#917650: Improve the state of drush error reporting during startup. Maybe some php.ini settings are preventing the file and line from being reported? Maybe I'm wrong, though. Do as Moshe said, confirm in HEAD, check your php.ini settings. See README.txt in HEAD.

Can you post a complete trace with --debug?

Hello,

I posted this first in the forums, http://drupal.org/node/998062. Somebody said here's probably a bettter place for it.

I just installed Drupal 6.

The site works really well. I can do eveything in my Drupal site I need to using the normal Web GUI.

Now I'm installing & configuring the modules I want.

I installed the Drush application to help with all that. It looks like a lot of people are using it.

I read the module site's suggestion to use the HEAD version. So I installed the drush-HEAD branch with CVS.

When I try to do anything with it I just get an error, ": in (line of )." like discussed in here. I don't just get it with that verbose flag but always.

I figured out to use the debug flag to get this output:

drush pm-list -d
Bootstrap to phase 0. [0.02 sec, 1.38 MB]                            [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drush() [0.03 sec, 1.5 MB]  [bootstrap]
Bootstrap to phase 6. [0.06 sec, 3.01 MB]                                                                [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.06 sec, 3.01 MB]                               [bootstrap]
Loading drushrc "/home/dale/www/drushrc.php" into "drupal" scope. [0.06 sec, 3.01   [bootstrap]
MB]
Initialized Drupal 6.19 root directory at /home/dale/www [0.07 sec, 3.59 MB]           [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.07 sec, 3.6 MB]                                [bootstrap]
Initialized Drupal site dalegt.local at sites/DaleZenSite [0.07 sec, 3.6 MB]                         [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.08 sec, 3.6 MB]                       [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.09 sec, 3.63 MB]                           [bootstrap]
Successfully connected to the Drupal database. [0.09 sec, 3.63 MB]                                       [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.09 sec, 4.11 MB]                               [bootstrap]
:  in  (line  of ). [0.46 sec, 22.38 MB]                                                                 [error]
Bootstrap to phase 5. [0.51 sec, 22.49 MB]                                                               [bootstrap]
Bootstrap to phase 6. [0.51 sec, 22.56 MB]                                                               [bootstrap]
Found command: pm-list (commandfile=pm) [0.51 sec, 22.56 MB]                                             [bootstrap]
Initializing drush commandfile: user [0.51 sec, 22.56 MB]                                                [bootstrap]
Command dispatch complete [0.51 sec, 22.56 MB]                                                              [notice]
 Timer  Cum (sec)  Count  Avg (msec)
 page   0.429      1      428.7

Peak memory usage was 22.97 MB [0.51 sec, 22.56 MB]                                                         [memory]

but I don't know what else to do with it.

Since I'm new at this I guess I probably made a mistake in configuring something. I don't know if it's Drupal or Drush or something else.

If anybody could help out I'd appreciate it.

Thanks a bunch.

Dale

Where did you install Drush? From this "Loading drushrc "/home/dale/www/drushrc.php" into "drupal" scope. [0.06 sec, 3.01 [bootstrap] MB]" it appears to be in your Drupal install.

Try installing into /home/dale/bin/ and adding this to your .profile:

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi

Successfully connected to the Drupal database. [0.09 sec, 3.63 MB]                                       [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.09 sec, 4.11 MB]                               [bootstrap]
:  in  (line  of ). [0.46 sec, 22.38 MB]                                                                 [error]

Due to the grow in memory usage it seems the error happen while bootstrapping drupal to full, and is reported by drush afterwards.
The only suggestion I have is to comment out ob_start() and ob_end_clean() in this function: http://api.drush.ws/api/drush/includes--environment.inc/function/_drush_...

...and see if it print some more indicative error.

Moreover. I was unable to reproduce a similar problem allegedly caused by a password with special chars (#) in #994894: fatal ": in (line of )." error with all commands after upgrade to 4.0-rc3. Is that your case?

Hello,

> #10
> Posted by bitradiator on December 14, 2010 at 11:18pm new
>
> Where did you install Drush? From this "Loading drushrc "/home/dale/www/drushrc.php" into "drupal"
> scope. [0.06 sec, 3.01 [bootstrap] MB]" it appears to be in your Drupal install.
>
> Try installing into /home/dale/bin/ and adding this to your .profile:

Drush is installed in /home/dale/drush

And I have a symlink

ls -al `which drush`
lrwxrwxrwx 1 root root 25 2010-11-08 11:45 /usr/local/bin/drush -> /home/dale/drush/drush

And in case it matters my shell is TCSH not BASH, where

echo $PATH
/root/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/scripts:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/bin/X11:/usr/games

> #11
> Posted by jonhattan on December 15, 2010 at 1:50am new
>
> Due to the grow in memory usage it seems the error happen while bootstrapping drupal to full,
> and is reported by drush afterwards.

In case it matters

php -i | grep memory_limit
memory_limit => 128M => 128M

> The only suggestion I have is to comment out ob_start() and ob_end_clean() in this function:
> http://api.drush.ws/api/drush/includes--environment.inc/function/_drush_...

vi drush/includes/environment.inc

/**
* Attempt to load the full Drupal system.
*/
function _drush_bootstrap_drupal_full() {
- ob_start();
+ // ob_start();
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
- ob_end_clean();
+ // ob_end_clean();

> ...and see if it print some more indicative error.

It doesn't really look like it to me.

Bootstrap to phase 0. [0.03 sec, 1.38 MB]                            [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drush() [0.03 sec, 1.5 MB]  [bootstrap]
Bootstrap to phase 6. [0.06 sec, 3.01 MB]                                                                [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.06 sec, 3.01 MB]                               [bootstrap]
Loading drushrc "/home/dale/www/drushrc.php" into "drupal" scope. [0.06 sec, 3.02   [bootstrap]
MB]
Initialized Drupal 6.19 root directory at /home/dale/www [0.08 sec, 3.6 MB]            [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.08 sec, 3.6 MB]                                [bootstrap]
Initialized Drupal site dalegt.local at sites/DaleZenSite [0.08 sec, 3.6 MB]                         [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.08 sec, 3.6 MB]                       [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.09 sec, 3.63 MB]                           [bootstrap]
Successfully connected to the Drupal database. [0.09 sec, 3.63 MB]                                       [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.1 sec, 4.11 MB]                                [bootstrap]
:  in  (line  of ). [0.39 sec, 22.38 MB]                                                                 [error]
Bootstrap to phase 5. [0.45 sec, 22.49 MB]                                                               [bootstrap]
Bootstrap to phase 6. [0.46 sec, 22.56 MB]                                                               [bootstrap]
Found command: pm-list (commandfile=pm) [0.46 sec, 22.56 MB]                                             [bootstrap]
Initializing drush commandfile: user [0.46 sec, 22.56 MB]                                                [bootstrap]
Command dispatch complete [0.46 sec, 22.56 MB]                                                              [notice]
 Timer  Cum (sec)  Count  Avg (msec)
 page   0.375      1      375.12

Peak memory usage was 22.97 MB [0.46 sec, 22.56 MB]                                                         [memory]

> #12
> Posted by jonhattan on December 15, 2010 at 3:03am new
>
> Moreover. I was unable to reproduce a similar problem allegedly caused by a
> password with special chars (#) in #994894: fatal ": in (line of )." error
> with all commands after upgrade to 4.0-rc3. Is that your case?

Here is what I have for my db_url string. The password is exact. It's just a test system for now.

$db_url = 'mysqli://DaleAdmin:12_ab_34_CD_5a_6f@localhost/dalezensite';

Reading around that bug and some others I did install drush-6.x-3.3.tar.gz and it works ok with none of that ": (line of}" error. So that seems like it's new or unique to drush-HEAD.

Oh, and I also saw with version 3.3 that if I move the MySQL socket location in my /etc/my.cnf , to /home/dale/var/run/mysql/mysql.sock for example, it's fine for Drupal and other stuff. But Drush complains about not being able to find the /var/run/mysql/mysql.sock socket. But if I make a symlink

ls -al /var/run/mysql
lrwxrwxrwx 1 mysql mysql 16 2010-12-11 14:58 /var/run/mysql -> /home/dale/var/run/mysql

Then drush v3.3 works OK again.

Dale

I tried the different Drush versions available on this. Here are the results.

(1) DRUSH == drush-HEAD (cvs)

drush status
	Initialized Drupal 6.20 root directory at /home/dale/www                               [notice]
	Initialized Drupal site dalezensite.loc at sites/DaleZenSite                                            [notice]
	:  in  (line  of ).                                                                                      [error]
	Command dispatch complete                                                                                   [notice]

(2) DRUSH == drush-6.x-4.0-rc3

drush status
	Initialized Drupal 6.20 root directory at /home/dale/www                               [notice]
	Initialized Drupal site dalezensite.loc at sites/DaleZenSite                                            [notice]
	:  in  (line  of ).                                                                                      [error]
	Command dispatch complete                                                                                   [notice]

(3) DRUSH == drush-All-versions-3.x-dev

drush status
	Drupal version         :  6.20
	Site URI               :  http://dalezensite.loc
	Database driver        :  mysqli
	Database hostname      :  localhost
	Database username      :  DaleAdmin
	Database name          :  dalezensite
	Database password      :  12_ab_34_CD_5a_6f
	Database               :  Connected
	Drupal bootstrap       :  Successful
	Drupal user            :  Anonymous
	Default theme          :  dale_zen_subtheme
	Administration theme   :  rubik
	PHP configuration      :  /etc/php5/cli/php.ini
	Drush version          :  3.4-dev
	Drush configuration    :  /home/dale/www/drushrc.php
	Drupal root            :  /home/dale/www
	Site path              :  sites/DaleZenSite
	File directory path    :  sites/DaleZenSite/files

(4) DRUSH == drush-6.x-3.3

drush status
	Drupal version         :  6.20
	Site URI               :  http://dalezensite.loc
	Database driver        :  mysqli
	Database hostname      :  localhost
	Database username      :  DaleAdmin
	Database name          :  dalezensite
	Database password      :  12_ab_34_CD_5a_6f
	Database               :  Connected
	Drupal bootstrap       :  Successful
	Drupal user            :  Anonymous
	Default theme          :  dale_zen_subtheme
	Administration theme   :  rubik
	PHP configuration      :  /etc/php5/cli/php.ini
	Drush version          :  3.3
	Drush configuration    :  /home/dale/www/drushrc.php
	Drupal root            :  /home/dale/www
	Site path              :  sites/DaleZenSite
	File directory path    :  sites/DaleZenSite/files

Nothing changed between these cases except the drush version.

I repeated it all again on another Drupal installation, and have the same results as I did above.

Maybe that helps?

Dale

Hi,

I provided what you'd asked for in both of your last messages.

Is there some additional info that I can provide?

Just hoping to get a working, up-to-date drush sytem. Or is the best advice to just forget about the newer versions and stick with the working 3.3?

Thanks!

Dale

drush-4 stable will be released shortly; sometime after that, the drush-3 line will be unsupported.

There isn't enough information here to determine what the problem is. You'll have to do some more investigation on your own if you want to keep up with drush advances.

So I guess I have to abandon Vers3 soon enough.

What kind of info can I get for you? I'm not a developer that knows the code and how to debug it.

What more can I give you other than the debug output I pasted above from "drush pm-list -d"? Just let me know.

I don't really understand how it can be my Configuration that's the problem, Since it works OK for some versions of Drush and not for others.

And I guess its not just a problem for me because other people are seeing the same errors, right?

FWIW, setting $conf['error_level'] = 0 got rid of this error message in my case. (Drush 4.2 and Pressflow 6.)

For me on v3.3, the issue is pinpointed at line 753 of includes/environment.inc

When error reporting is on and set to show E_WARNING, the
drupal_set_header('Content-Type: text/html; charset=utf-8');
line of _drupal_bootstrap_full() generates a PHP warning, which is caught by drupal_set_message(),
then by _drush_log_drupal_messages().

Suppressing PHP warnings for that line only will eliminate this problem.

IMO, this is a cleaner solution than disabling error reporting for the site in general, because on dev installations people may want the PHP warnings in general. At least, I do.

Attaching a patch. Line numbers correlate to v3.3.

I posted the last comment before upgrading. The issue appears to be gone in v4.4.

And wouldn't you know it: v4.4 doesn't want to work for me in general. So I'm back to v3.3.

just wanted to state, the issue is not gone - its driving me crazy for days now.

Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [bootstrap]
[29.23 sec, 9.23 MB]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [29.24 [bootstrap]
sec, 9.26 MB]
Successfully connected to the Drupal database. [29.24 sec, 9.26 MB] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [29.24 sec, [bootstrap]
9.53 MB]
: in (line of ). [30.3 sec, 47.59 MB] [error]
: in (line of ). [30.3 sec, 47.59 MB] [error]
Changed paths from sites/test.kw.de to sites/test.kw.de [30.46 sec, [notice]
47.61 MB]
Found install profile [30.48 sec, 47.63 MB] [notice]
Found install profile [30.48 sec, 47.65 MB]

using current head...
Its def. and drush issues, as the drupal instance works fine after that.

I tried to trace down the issue, and actually it is something pretty hard to find yet. It is 100% related to the full drupal bootstrap. Interestingly, it happens to work just a second before, when i run updatedb ( which does a drupal boostrap also ).

That those issues apear after the bootstrap is quiet normal, as

/**
* Attempt to load the full Drupal system.
*/
function _drush_bootstrap_drupal_full() {
ob_start();
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
ob_end_clean();

// Unset drupal error handler and restore drush's one.
if (drush_drupal_major_version() == 6) {
restore_error_handler();
}

// If needed, prod module_implements() to recognize our system_watchdog() implementation.
$dogs = module_implements('watchdog');
if (!in_array('system', $dogs)) {
// Note that this resets module_implements cache.
module_implements('watchdog', FALSE, TRUE);
}

_drush_log_drupal_messages();
}

so drush _drush_log_drupal_messages(); takes out those errors out of the drupal boot ( so the drupal installation ), those errors seem to be "empty" or somewhat.

confirming that path #19 solves the issue!

#19 is okay, and could probably be committed if re-rolled against master and tested. I am a little concerned that hiding warnings here is just masking a more serious issue in Drupal core; if we hid all warnings, might we miss seeing future problems? Maybe they would not be problems if we hid them, though.

For the problem above, please see http://drupal.org/node/1174496, and see if maybe this is the same issue you are having. I always patch Drupal core with http://drupal.org/node/1174496#comment-4629384; perhaps this is the same thing you are seeing. It would be interesting to know if it was the same problem or something different.

I'm not too interested in hiding all warning during the major bootstrapping of drupal. We need to find the problem in Drupal and fix there if possible. I suspect that this is not a Drush issue.

#25 / #24: the drupal installation works flawlessly. And iam not just telling you that. In addition, when using drupal for the updaedb / bootstrap process, it works flawlessly. When drupal works without issue ( watchdog) on updatedb and later the bootstrap. So drush shall do this.

I would say, thats a drush issue, but hey, what else.

It would be interesting to know if the patch mentioned in #23 makes this go away for you.

the drupal installation works flawlessly. And iam not just telling you that.

I don't know that I am entirely convinced. It is possible that the same defect is happening under Drupal as Drush (php warning), and the symptoms of that are simply less obvious under Drupal, or perhaps you do not have warnings enabled in your webserver's php.ini, which would also mask the warning.

I'm kind of with moshe on not wanting to hide all warnings all the time during the Drupal bootstrap, because in other instances, we might miss something serious. For this particular issue, the symptom (warning) is more serious than the defect (mostly innocuous, but still definitely a Drupal problem); therefore, it might be worthwhile to have a drush option ($options['i-want-to-remain-oblivious'] = TRUE;) to hide problems from people who just want to get their work done.

Greg i have debugged this to the bones, those errors are empty and i have not a slighly clue how to get deeper. I would neet to place a debug_backtrace into drupal_set_message to actually see what geenrates those errors. That is _very_ unusual or never seen in Drupal when you use a non-cli boostrap. Those errors never apear when bootstrap the drupal instance the normal way, those erros are not related to one installation, but at least 4/4 i tried ( different code bases, but similar).

As those errors never apear in drupal and the drupal installations are working fine, i expect this to be an issue on the drush side.

Hiding away issues - absolutely not my approach either. But - there are not issues most probably, those are false-positives. But yes, the cleaner solution is to find were it all comes from.

But marking that as an support-issue is, in my eyes wrong. That or that way - its def. a bug.

I am not disagreeing or agreeing with you, but did you try the patch in #23?

@greg: well, i tried the #23 patch before, what did not solve my issue. Yet, its currently not applied, but it is already in our drupal-core pach list and will be rolled out when platform building works :) But as i said, tried it - did not help me.

Okay. I'd be fine with a solution per #27, but final resolution of this issue will be up to moshe.

just verified, #23 does not fix it, #19 does

I have witnessed this bug under Aegir 1.5 on CentOS 6.0 with PHP 5.3.2 and Drupal 6.22.

I can also confirm that #1174496: WSOD: drupal_error_handler() assumes filter_xss() is defined is not sufficient to fix this bug.

I rerolled the patch for Drush 5, but couldn't test there. I'll submit a Drush 4 patch later.

... and the attached patch works for Drush 4.

Now, I agree this is less than idea, but it's a worthy workaround. Without this I can't install Drupal 6 with Aegir's provision-install if --verbose is enabled.

of course, the above suffixes should be D5 and D4, not D7 and D6. sorry for the confusion.

I am still ambivalent about unconditionally hiding bootstrap warnings. I suppose I could cave on this issue if moshe has changed his mind about #25, but I think I would be happier if this behavior was controlled by a Drush global option per #27. Alternate names fine.

actually, i agree. digging deeper into this, i found there was a bug in *pressflow's* use of t() in _drupal_log_error() (which is a D7 function!!!) that triggered this. for those stuck with the problem, replace the t() with a tr() in the drupal_set_message().

big wtf.

@37: D6 does not have a tr method, so this is rather a D7 fix?

i meant strtr(). And this fix is for Pressflow, maybe also D7.