Override browser?

[Brandon Bloom]

On many linux systems, the BROWSER environment variable allows users to specify their default browser, much like the EDITOR or PAGER environment variables.

Would you be open to a PR that adds support for a browser parameter and/or environment variable? I'm happy to contribute Windows and MacOS support for these.

[Mislav Marohnić]

See #14 (comment) for why this is infeasible, since there is not a BROWSER spec and different tools implement reading this environment variable differently in regard to argument passing, quoting, and shell expansion.

[Quinn Rivenwell]

See #14 (comment) for why this is infeasible, since there is not a BROWSER spec and different tools implement reading this environment variable differently in regard to argument passing, quoting, and shell expansion.

I think infeasible is strong. A common sense implementation here could be well worth it. It's not clear to me why one would need a priority list of browsers or even %s substitution. At that point, it's best if such a user just writes their own script to call a browser as they see fit and then set that in $BROWSER. As well, I don't think there's any precedent for these features in the standard POSIX variables like EDITOR, PAGER, MAILER.

Thus I propose we interpret $BROWSER as a shell command and run it via sh with the URL/path as the first argument.

For example if BROWSER="run this command --this-is-a-flag then the execution on the URL https://github.com/pkg/browser/issues/41 would look like this in shell:

sh -c 'run this command --this-is-a-flag "$1"' -- 'https://github.com/pkg/browser/issues/41'

The other nice thing about $BROWSER is that if a user wishes to disable automatic launching of their browser, then they can set BROWSER=true. I've often found myself trying to debug the side effect of running some tool. In such situations, I do not like to lose focus from my terminal to my browser. Having to close the new tab and switching back again and again is frustrating.

[Quinn Rivenwell]

Here's what I'm using:

func OpenURL(ctx context.Context, url string) error {
	browserEnv := os.Getenv("BROWSER")
	if browserEnv != "" {
		browserSh := fmt.Sprintf("%s '$1'", browserEnv)
		cmd := exec.CommandContext(ctx, "sh", "-c", browserSh, "--", url)
		out, err := cmd.CombinedOutput()
		if err != nil {
			return fmt.Errorf("failed to run %v (out: %q): %w", cmd.Args, out, err)
		}
		return nil
	}
	return browser.OpenURL(url)
}

It implements the above proposal.

[dangercrow]

See #14 (comment) for why this is infeasible

@mislav I think infeasible is too strong here.

There's clearly appetite for this, and technical solutions have been proposed that seem like a sensible first approximation to a 'low(est?) common denominator' (e.g. directly above).

I'd think there are a few approaches here that could resolve the desire for this feature (in my personal decreasing preference order):

• Implement the above simple BROWSER var, with documentation that the spec is unfixed
• Implement a distinct var for this specific project, with a defined spec (I would suggest the simple one above). This could also be used in combination with the above, with appropriate docs
• Document the workaround of overriding xdg-open in ones local PATH (e.g. creating a script in the local dir)