Open Baughn opened 8 years ago
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?
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.