Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xdg-open may not be in /usr/bin #981

Open
Baughn opened this issue Jun 7, 2016 · 6 comments
Open

xdg-open may not be in /usr/bin #981

Baughn opened this issue Jun 7, 2016 · 6 comments

Comments

@Baughn
Copy link
Contributor

Baughn commented Jun 7, 2016

In fact, it may not be in a fixed location at all, but https://github.com/Slowpoke101/FTBLaunch/blob/master/src/main/java/net/ftb/util/OSUtils.java#L528 currently assumes /usr/bin.

Running on NixOS, the only halfway stable location for xdg-open is in /run/current-system/sw/bin -- but you shouldn't rely on that, either. The best fix would be to try running it with ProcessBuilder, then only error out if it fails. That'll check the PATH.

Baughn added a commit to Baughn/FTBLaunch that referenced this issue Jul 1, 2016
Fixes Slowpoke101#981. In case it doesn't exist, there'll be an exception, and
nothing else changes.
Baughn added a commit to Baughn/FTBLaunch that referenced this issue Jul 1, 2016
Fixes Slowpoke101#981. In case it doesn't exist, there'll be a different exception;
nothing else changes.
progwml6 pushed a commit that referenced this issue Jul 2, 2016
Fixes #981. In case it doesn't exist, there'll be a different exception;
nothing else changes.
@LunNova
Copy link
Contributor

LunNova commented Jul 8, 2016

In the case where the xdg-open isn't available but Desktop.getDesktop().open would have worked, this change will now cause an exception.

Wouldn't it be better to change the logic to determine if xdg-open is available in a more foolproof way instead of removing the check entirely?

@Baughn
Copy link
Contributor Author

Baughn commented Jul 8, 2016

That's a good point. Probably the most robust way would be to try each method in turn, swallowing exceptions if they fail; the most robust way to see if xdg-open works is really just to try it.

@progwml6 progwml6 reopened this Jul 8, 2016
@progwml6
Copy link
Collaborator

progwml6 commented Aug 5, 2016

if Desktop.getDesktop() is usable the xdg-open section shouldn't be called and this simply calls xdg-open to see if it works.

I would rather fix the checks yes however i'm not sure if i see any downfall to this approach other than the possibility of errors in the console log if xdg-open doesn't exist at all

if anyone has specific use cases or a better idea of how to handle the path checks please let me know

@LunNova
Copy link
Contributor

LunNova commented Aug 5, 2016

Almost. If Desktop.browse is supported it does that. If not available on unix it tries xdg-open. If xdg-open wasn't present it then fails.

Desktop.open should be called if browse isn't supported and xdg-open isn't available.

@progwml6
Copy link
Collaborator

progwml6 commented Aug 6, 2016

I'm not familiar with what the returns are when xdg-open doesn't exist, and don't have a machine to test this myself at the moment ... would it enough to call Desktop.open if an exception is thrown when xdg-open is called?

@Baughn
Copy link
Contributor Author

Baughn commented Aug 6, 2016

xdg-open might exist, but not work, in which case it'll exit with a nonzero return code. You'll also need to check for that.

I'd see if I write a patch for this, but... metered connection right now. Maybe in a week or two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants