-
Notifications
You must be signed in to change notification settings - Fork 140
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
Comments
Fixes Slowpoke101#981. In case it doesn't exist, there'll be an exception, and nothing else changes.
Fixes Slowpoke101#981. In case it doesn't exist, there'll be a different exception; nothing else changes.
Fixes #981. In case it doesn't exist, there'll be a different exception; nothing else changes.
In the case where the 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? |
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. |
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 |
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. |
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? |
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. |
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.
The text was updated successfully, but these errors were encountered: