Launchy.open( uri ) about launchy

[copiousfreetime]

You did almost the correct update, that should be

Launchy.open( path )

not

Launchy.open( uri )

The parameter that was passed to Launchy::Browser.run was 'path' not 'uri'

You may still get an error, because capybara is opening up a file and not a uri. And that is a bug that I will be fixing this week.

[copiousfreetime]

This will go out with the next release of launchy

[lgrains]

After making the changes described above, I'm getting this error:

[540]berklee@bizops:/web/bizops-dev git:dev$ cucumber features/leads/index.feature:21
Using the default profile...
.........sh: xprop: not found
/home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.1.0.rc4/lib/active_support/whiny_nil.rb:48:in method_missing': undefined methodshellsplit' for nil:NilClass (NoMethodError)
from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:41:in shell_commands' from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:104:inblock in wet_run'
from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:103:in fork' from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:103:inwet_run'
from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:61:in run' from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy/application.rb:58:inrun'
from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy/applications/browser.rb:76:in open' from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/launchy-2.0.5/lib/launchy.rb:30:inopen'
from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/capybara-1.0.0/lib/capybara/util/save_and_open_page.rb:26:in open_in_browser' from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/capybara-1.0.0/lib/capybara/util/save_and_open_page.rb:19:insave_and_open_page'
from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/capybara-1.0.0/lib/capybara/session.rb:283:in save_and_open_page' from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/capybara-1.0.0/lib/capybara/dsl.rb:139:insave_and_open_page'
from /mnt/hgfs/bizops/features/step_definitions/web_steps.rb:210:in block in <top (required)>' from /home/berklee/.rvm/gems/ruby-1.9.2-p180/gems/cucumber-1.0.0/lib/cucumber/core_ext/instance_exec.rb:48:ininstance_exec'
. . .

It appears I'm still stuck in getting "Then show me the page" to work with Launchy

[copiousfreetime]

Can you run the following and paste the output here?

LAUNCHY_DEBUG=true cucumber features/leads/index.feature:21

And also:

ruby -rrbconfig -e "puts ::RbConfig::CONFIG['host_os']"

[copiousfreetime]

I haven't heard anything further on this issue. Are you still having a problem? If not I'll close this issue next week.

[mfn]

While testing out https://github.com/gitlabhq/gitlabhq I came across this issue while playing around with it; this problem has nothing to do with gitlabhq, it's just that with latest launch due their Gemlock I can see this:

gitlab@vserv03:~/gitlabhq$ bundle exec launchy http://slashdot.org/
sh: xprop: not found
/home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:41:in `shell_commands': undefined method `shellsplit' for nil:NilClass (NoMethodError)
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:104:in `block in wet_run'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:103:in `fork'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:103:in `wet_run'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/detect/runner.rb:61:in `run'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/application.rb:58:in `run'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/applications/browser.rb:76:in `open'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy.rb:30:in `open'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/cli.rb:72:in `good_run'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/cli.rb:80:in `run'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/bin/launchy:4:in `<top (required)>'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/bin/launchy:19:in `load'
        from /home/gitlab/gitlabhq/vendor/bundle/ruby/1.9.1/bin/launchy:19:in `<main>'

It does not actually exhibit a real problem, it's just during e.g. loading the initial database there's seems to be something done using launchy which spams the screen full. After some searching I figured out it relates to launchy and did this simply test case.

I don't have cucumber installed, but I can give you the ruby output:

gitlab@vserv03:~/gitlabhq$ bundle exec ruby -rrbconfig -e "puts ::RbConfig::CONFIG['host_os']"
linux-gnu

This is a headless server so naturally there is no window manager installed thus no Xcfe and no xprop:

gitlab@vserv03:~/gitlabhq$ grep -r xprop *
vendor/bundle/ruby/1.9.1/gems/launchy-2.0.5/lib/launchy/detect/nix_desktop_environment.rb:        %x[ xprop -root _DT_SAVE_MODE | grep ' = \"xfce\"$' ].strip.size > 0

hth

[copiousfreetime]

the best help would be if you could run:

LAUNCHY_DEBUG=true bundle exec launch http://slashdot.org

It looks to me like on that machine launchy is unable to find a way to launch a browser. The debug will help me figure out what it is.

Also, if you could do a uname -a or similar so I could know what type of machine that is, that would help.

thanks, and we'll figure this out.

[copiousfreetime]

@mfn I somehow missed the bottom of your message.

I would expect Launchy to fail on a machine that had no browsers installed and now window manager. Launchy launches a browser, so i'm not sure what the goal of using launchy on a headless system would be.

I've put this in Issue #42 to deal with separately.