I recently realized that my default browser wasn't opening when I ran drush qd (core-quick-drupal). In the past it would open my default browser no problem. I am running OS X 10.8.2.

When I ran drush -v qd, I noticed the following error:

No graphical display appears to be available, not starting browser.

I am not sure if this is a drush issue or an issue with my machine at this point.

CommentFileSizeAuthor
#3 drush-open-browser-fix-1896132-3.patch1.32 KBshrop
#1 drush-open-browser-fix-1896132-1.patch814 bytesshrop

Comments

shrop’s picture

shrop commented
Status: Active » Needs review
StatusFileSize
new drush-open-browser-fix-1896132-1.patch814 bytes

I think I found the issue. drush_start_browser() in includes/exec.inc is checking for the DISPLAY environment variable as of this commit. I checked with some developer friends and a few different Macs for the DISPLAY environment variable. It appears to OS X 10.8.2 does not have that variable set at all out of the box. Some Macs do have DISPLAY set if the user has installed XQuartz or other 3rd party tools which may use DISPLAY.

As a result, I think that OS X systems should be excluded from throwing the "No graphical display appears to be available, not starting browser. " error similarly to the Windows check on line 402 of includes/exec.inc:

if (!drush_get_context('DRUSH_SIMULATE') && !getenv('DISPLAY') && !drush_is_windows()) {

The fix that is working for me:

if (!drush_get_context('DRUSH_SIMULATE') && !getenv('DISPLAY') && !drush_is_windows() && PHP_OS != "Darwin")

I have included a patch which excludes OS X systems from throwing the error by using the PHP_OS constant. This patch works for my system. Please review. Thanks!

greg.1.anderson’s picture

greg.1.anderson commented
Status: Needs review » Needs work

Seems reasonable to me -- although I wonder what this does in an environment where you really do not have a display (e.g. ssh to your Mac)? It would be good to test this scenario, and see if it can be detected if it does not fail gracefully. It would also be good to wrap the test for Darwin in a drush_is_macintosh() function.

shrop’s picture

shrop commented
Status: Needs work » Needs review
StatusFileSize
new drush-open-browser-fix-1896132-3.patch1.32 KB

Greg,

Thank for the quick reply! Your bring up a great point on what happens when there isn't a display (ex: remote ssh'ing into a Mac). I did some additional testing. If I ssh into my Mac from my phone while I am still logged into my Mac, the browser actually opens. I think that is ok. Next I logged out of my Mac, but left it running. I then ssh'd into it from my phone again and drush qd completed without issue. While it did attempt to open a browser, it did not error and still started the php-cgi server no problem.

I have attached an updated patch which contains a drush_is_osx() function with an updated check in the drush_start_browser() function.

Let me know if you need any other changes.

Thanks!

greg.1.anderson’s picture

greg.1.anderson commented
Version: 7.x-5.x-dev » 8.x-6.x-dev

It all looks good to me. Oh, patches should be against 8.x-6.x, although the patch above did apply there for me. I'm happy to blindly commit, but I'll leave this open for a couple of days in case someone with a Mac wants to test or comment.

shrop’s picture

shrop commented

Sounds good to me. Thanks for the info on working against 8.x-6.x. That makes sense.

greg.1.anderson’s picture

greg.1.anderson commented

It would be best to detect the 'no display' situation if there is any way to do that. I didn't pull anything up after a minimal amount of googling.

shrop’s picture

shrop commented

I cannot find a reliable way to detect if the machine has a display attached or not with OS X 10.8. It appears that when OS X 10.7 was around, it was there, but Apple removed some components related to this in 10.8. If a user installs XQuartz, which replaces the missing components, DISPLAY is set. We can't guarantee that drush users will install XQuartz.

Here are some related discussions going on that are in this space that discusses some of the above:
http://stackoverflow.com/questions/12152257/ssh-x-on-mac-gives-error-in-...
http://root.cern.ch/phpBB3/viewtopic.php?t=15021&

My recommendation is that we drop checking for display for OS X until Apple corrects this behavior. I still would like to have other Mac users weigh-in with additional info an thoughts.

shrop’s picture

shrop commented

On a related, but possibly unrelated note, My install of drush 5.8 appears to call to open the browser twice. The first time it calls for http://localhost/... and that isn't right. I will investigate that more and open another issue more than likely.

http://localhost/usr/local/Cellar/drush/5.8/libexec/user/reset/1/1358954767/fV-W31txLCBypE-dAsFfsG3CSXWCnyBVMd1YkAjcBSI/login
Login URL: 
HTTP server listening on 127.0.0.1, port 8888 (see http://127.0.0.1:8888/), serving site default, logged in as admin...
tommyk’s picture

tommyk commented

I can report like #8 that two browser windows are opened, one right after the other. The first tries to go to localhost and the second goes (correctly) to http://127.0.0.1:8888/. At least it is opening the browser.

I'm using 8.x-6.x with the patch from #3 (manually applied).

greg.1.anderson’s picture

greg.1.anderson commented

Could someone also please test that this works correctly with drush uli?

moshe weitzman’s picture

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

If someone could do that test, it would be great. This is nearly ready.

chrowe’s picture

chrowe commented

In general getting core-quick-drupal running on a mac seems a bit hard.

I am running:

  1. OS X 10.8.3
  2. PHP 5.4.14 (cli) (installed using: brew tap josegonzalez/homebrew-php AND brew install php54 --with-cgi)
  3. XQartz 2.7.4 (fixes the 'No graphical display' issue)
  4. drush version 5.9 (installed using: brew install drush)
  5. I also had to get sendmail running before the qd command would run without errors

I think if there was documentation about the XQartz requirement than I would be fine with it the way it is.

I am also getting the multiple windows opening. In some cases just the bad http://localhost/usr/local/Cellar... will open. Maybe just the first time I run drush qd after loggin in to my mac? not sure. This seems like a different issue to me though. Might be an issue with drush installed via brew?

I may try to install everything again on a fresh mac using pear for drush. If I do, I can try testing the patch.

@greg.1.anderson how would you define "works correctly with drush uli" If I run drush uli now I get a http://default/... url. If I copy and paste the relative path it works. Should it load a browser?

greg.1.anderson’s picture

greg.1.anderson commented

If you set --uri on the command line or in your site alias file, then drush uli should emit the correct hostname for your site, and will also open a web browser on the site.

I don't know about using this on Mac, though.

moonray’s picture

moonray commented

I've tested the patch in #3 on Mac OS X 10.8.3 (Mountain Lion).
drush uli opens the (default) browser window correctly and logs me in. It only opens 1 browser window for me.

I am using a site alias, though, drush @local.vuweb uli and my site is not using localhost as the hostname or a custom port.
I also tested using drush -l http://drupal7 uli

Perhaps the double browser issue in #8 and #9 is related to the custom port?

greg.1.anderson’s picture

greg.1.anderson commented
Status: Postponed (maintainer needs more info) » Needs review

Do we want to put this in, or do we want anything else here? (Independent verification, more isolation of the two-window problem, etc.?)

owen barton’s picture

owen barton commented

We are checking for the DISPLAY environment variable - if this is not set to something we won't open a browser. I am pretty sure we have tested the browser opening on OS X, so I am not quite sure where the problem is.

Could you try running "export | grep DISPLAY" and posting the output?

You could also try running:

echo '<?php var_dump(getenv("DISPLAY"));' | php

which might highlight if it is a PHP specific problem.

Edit: missed some of the earlier comments. I wonder if DISPLAY may only be available when xwindows/dev-tools is installed or something like that?

In any case, I think browsers should only open for local graphical users, not on remote machines (it seems it would be easy to open many tabs on a server and crash it, for instance!).

moonray’s picture

moonray commented

export | grep DISPLAY leaves me with no output. I've already checked my system for the DISPLAY variable, and it doesn't exist.
Again, I'm running Mac OS X 10.8.3.

The PHP equivalent:

echo '<?php var_dump(getenv("DISPLAY"));' | php
bool(false)

I have Xcode installed, but didn't install xwindows.

As far as opening windows... if I run drush uli on a remote server, using an alias from my local machine, I'd like that to open a browser window. If I'm SSH'ed into a remote server and am running the command, it should not open a browser window. Not sure how you'd distinguish between the 2 use cases, though.

greg.1.anderson’s picture

greg.1.anderson commented

There is a flag that can be set in the command record that tells drush to run drush @remote uli on the local machine instead of the remote machine. The local implementation of uli could then check to see if the alias was remote, and if so, use drush_invoke_process to run uli remotely. It would then be easy enough to open a browser window to the url returned from backend invoke.

See the implementation of the ssh command for details. Patches welcome, but it should probably be a separate issue.

moshe weitzman’s picture

moshe weitzman commented

I've copied #18 to a new issue since it is definitely worth doing, and is pretty easy. I might even give it a shot. See #2013743: More turbo: `drush uli --browser` should work even when used on remote hosts

moshe weitzman’s picture

moshe weitzman commented

I'm running OSX 10.8.2 and also get nothing for export | grep DISPLAY. I don't recall if we ever had this working on OSX. It isn't mentioned at #1200738: Command to get started with Drupal with zero configuration

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Needs work

I was about to commit #3, but I notice that it prints out a warning "default does not appear to be a resolvable hostname or IP, not starting browser." if you don't supply a --uri. Should this message be moved to a notice and thus suppressed unless user is in verbose mode? The message is a bit scary but it is informative. Maybe it should include info about how to fix the problem?

owen barton’s picture

owen barton commented

How about we append "You may need to use the --uri option in your command or site alias to indicate the correct URL of this site"? This way we could leave it as a warning - which makes the browser function more discoverable (otherwise users may go on without ever learning it exists).

I also noticed that --no-browser doesn't work as expected (you can just do --browser= instead, but that isn't our normal pattern).

greg.1.anderson’s picture

greg.1.anderson commented

Created related issue, #2014715: Drush should support --no-FOO in the general case

moshe weitzman’s picture

moshe weitzman commented
Assigned: Unassigned » moshe weitzman

That works for me. I will commit this as suggested.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs work » Fixed

Committed to 5.x and 6.x

shrop’s picture

shrop commented

Thanks for all of the help on this one. I do appreciate it.

Status: Fixed » Closed (fixed)

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