In normal usage from the command line drush outputs http headers.

The attached patch stops this behavior and allows an override if the headers are desired.

Examples:

  command> drush status version
  Drush version   :  3.3

  command> WITH_HEADERS=true drush status version
  X-Powered-By: PHP/5.2.14
  Content-type: text/html

  Drush version   :  3.3

This should support the three cases of command line usage, cron usage, and web site usage.

The cron usage case eliminates the possibility of using the [ -t ] test for terminal connectedness.

Assumption is that command line and cron usage are the two primary use cases for drush. The WITH_HEADERS variable is not checked for value so it could be set to 1, true, xxx, false, anything and headers would be produced. The assumption is that headers are rarely if ever desired.

Note: Recommendations to add the '-q' option to the '/usr/bin/env php' interpreter line in drush.php do not work on all OS platforms.

CommentFileSizeAuthor
drush-suppress-http-headers.patch1.5 KBetxaleku
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greg.1.anderson’s picture

Status: Needs review » Postponed (maintainer needs more info)

This needs more of an explanation. Drush is not designed to be called from a web browser, although if I understand correctly, there is already a module (drush ui) that does so.

In any event, I don't see php outputting headers when I set WITH_HEADERS to true, and I don't see -q in man php, so I think I'm missing something here.

etxaleku’s picture

Status: Postponed (maintainer needs more info) » Needs review

Observed that drush seems to output what looks a little like HTTP headers each time it's run.

command prompt> drush status drush_version
X-Powered-By: PHP/5.2.14
Content-type: text/html

 Drush version   :  3.3

Specifically it's the "X-Powered-By" and "Content-type" output that is at issue. I wasn't sure why these "headers" were being generated and the patch was an attempt to suppress them.

I initially found a clue in #193736: Settings issue in post #4 where stevenQ said,

reikiman, you can try to suppress headers by one of following ways:
- try
php -q drush.php watchdog show

- modify drush.php and make its first row containing
#!/usr/bin/env php -q

and run command as, lets say -
./drush.php watchdog show

PS isnt it reasonable to add '-q' option to drush.php in the repository?

I tried add the '-q' option to drush.php but found that some operating systems parse the interpreter line differently and encounter the error: file not found 'php -q' instead of running php with the -q option. I considered creating a shell alias of
alias drush='php -q drush.php' but felt that the better solution would be to update the 'drush' wrapper. I added the 'WITH_HEADERS" variable in case there was a situation where the headers were useful that I wasn't aware of.

My research of the '-q' option to php consisted of

command prompt> php -h
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
       php <file> [args...]
  -a               Run interactively
  -C               Do not chdir to the script's directory
  -c <path>|<file> Look for php.ini file in this directory
  -n               No php.ini file will be used
  -d foo[=bar]     Define INI entry foo with value 'bar'
  -e               Generate extended information for debugger/profiler
  -f <file>        Parse <file>.  Implies `-q'
  -h               This help
  -i               PHP information
  -l               Syntax check only (lint)
  -m               Show compiled in modules
  -q               Quiet-mode.  Suppress HTTP Header output.
  -s               Display colour syntax highlighted source.
  -v               Version number
  -w               Display source with stripped comments and whitespace.
  -z <file>        Load Zend extension <file>.

I started to wonder if the php I was using was unusual in some way, especially after noticing the Zend extension stuff, and took a look at http://www.php.net/manual/en/features.commandline.options.php. There wasn't any mention of '-q' until you scroll down a bit and they mention '-q' or '--no-header' option which they describe as "Quiet-mode. Suppress HTTP header output (CGI only)".

I still wonder if various php environments are behaving differently as I think more people would complain about these headers and you mentioned you don't see them in your environment.

Bottom line, I believe drush needs "Quiet-mode. Suppress HTTP header output." as a default - even if it isn't producing headers in some/most environments given its focus on command line usage.

moshe weitzman’s picture

Seems like this happens if you use CGI PHP instead of CLI. I don't completely know how that happens. See http://bytes.com/topic/php/answers/3525-command-line-php-suppressing-hea....

I'm inclined to just let folks handle this locally by adding -q in their bash alias

etxaleku’s picture

I've researched the situation a bit more and the observation of CGI vs CLI versions of PHP probably explains why more people don't complain about this issue. My hosting provider, for whatever reason, does not provide the CLI version of PHP.

You could add the patch supplied or add instructions to the installation process for drush.

My viewpoint is that the installation of drush is already a bit quirky and should undergo a "simplification of installation" process in the future just as drupal is currently undergoing in version 7. The use of shell aliases adds another layer of complexity - especially when you consider the use of drush in cron situations. I recommend the more traditional use of softlinks and management of the PATH variable instead as it tends to produce fewer "surprises".

For situations without root access (shared hosting case):

command> ls -l $HOME/bin

   21 Jul  8 18:14 drush -> ../.drush/drush/drush
   19 Jun  7 14:25 php -> /usr/local/bin/php5

For situations with root access something like:

command> ls -l /usr/local/bin

   21 Jul  8 18:14 drush -> /path/to/.drush/drush/drush
   19 Jun  7 14:25 php -> /path/to/bin/php5

And then add $HOME/bin or /usr/local/bin, as appropriate, to the PATH variable.

Wow - after looking at #662926: --php path argument required on Dreamhost I can see that the issue is more complicated than I thought. It looks to me like there needs to be a GNU autoconf-like process provided with drush that is run during drush installation that works out the details and generates a suitable drush wrapper for that particular installation.

For example, if drush were distributed as a self-extracting shell program (http://megastep.org/makeself) then the installation process could be a simple download and run, answering a few questions maybe, and done. The autoconf wrapper generator would automatically be run and everything would be taken care of in a manner somewhat similar to InstallShield-type installations. I'll volunteer if there's sufficient interest in the approach and no one available to do it.

moshe weitzman’s picture

At first blush, that makeself seems like complicating our system more than the shell script we already use. We have not had any other reports that I can recall about folks using CGI instead of CLI. A big change is not needed yet.

etxaleku’s picture

Status: Needs review » Closed (works as designed)

I don't think you understood makeself and/or autoconf. I agree, the system is already complicated and it doesn't sound like there's interest in changing it so let's close this one.