browser icon indicating copy to clipboard operation
browser copied to clipboard

Override browser?

Open brandonbloom opened this issue 4 years ago • 4 comments

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.

brandonbloom avatar Sep 29 '21 15:09 brandonbloom

See https://github.com/pkg/browser/pull/14#issuecomment-741864029 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.

mislav avatar Aug 03 '22 12:08 mislav

See https://github.com/pkg/browser/pull/14#issuecomment-741864029 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.

nhooyr avatar Oct 13 '22 05:10 nhooyr

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.

nhooyr avatar Oct 13 '22 06:10 nhooyr

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)

dangercrow avatar Jul 28 '23 08:07 dangercrow