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

cmd/internal/browser: Open() shouldn’t rely on Commands() #33148

Open
flying-sheep opened this issue Jul 17, 2019 · 0 comments
Open

cmd/internal/browser: Open() shouldn’t rely on Commands() #33148

flying-sheep opened this issue Jul 17, 2019 · 0 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@flying-sheep
Copy link

Commands() is used as the only backend for Open(), but there’s OS-specific ways to open things in a browser instead. Sadly on Linux, it is complex:

  1. Consult $BROWSER for a “:”-delimited list of executables.
  2. If it’s unset or none of the executables can be found:
    1. xdg-settings get default-web-browser will return the .desktop file name, e.g. firefox.desktop
    2. Find that file in one of ${XDG_DATA_HOME-$HOME/.local/share}:${XDG_DATA_DIRS-/usr/local/share/:/usr/share/} (subdirectory applications)
    3. Parse the Exec line in that file and replace %s, %u and whatever with the file name/url/… to get a command line
  3. Execute the command line you built from $BROWSER or the .desktop file
  4. If all the above failed, fall back to xdg-open

As said, this is harder than it should be, but it’s the only way to do it correctly AFAIK. xdg-open does all this, but there’s no way to tell it “open the path/URL I give you with a browser”. If you e.g. want to open a SVG with a browser, you need to go the above route.

@FiloSottile FiloSottile changed the title cmd/internal/browser Open() shouldn’t rely on Commands() cmd/internal/browser: Open() shouldn’t rely on Commands() Jul 17, 2019
@FiloSottile FiloSottile added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 17, 2019
@FiloSottile FiloSottile added this to the Unplanned milestone Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

2 participants