Skip to content

Utilize 'gh browse' as a cross-platform solution to open a URL in the browser  #7620

Description

@LangLangBart

Describe the feature or problem you’d like to solve

Ability to open a specific GitHub URL with gh browse in the default browser, regardless of the operating system.

Possible use case in a bash extensions, e.g. when opening a specific workflow, a comment on an issue, or a pr review by selecting it with fzf.

Additional context

  • current workarounds
#!/usr/bin/env bash
set -euo pipefail

url="https://github.com/cli/cli/pull/4663#pullrequestreview-794795478"

# 1st: case
  case "$(uname -s)" in
    Darwin) open "$url"     ;;
    Linux)  xdg-open "$url" ;;
    *) 		start "$url" ;;
  esac

# 2nd: python
python -m webbrowser "$url"

Activity

  1. added
    discussFeature changes that require discussion primarily among the GitHub CLI team
    and removed on Jun 25, 2023
  2. samcoe commented on Jun 25, 2023

    @samcoe
    Contributor

    @LangLangBart Thanks for writing in.

    I am on leaning towards not wanting to support this type of feature. I feel like this is a bit of an overstep on the purpose of this command, it wasn't designed to be a generic way to open a URL in a web browser. I also think that the browse command has too much "magic" that it tries to do that has led to numerous issues and confusion on its behavior from users in the past. Lastly, I don't know if it is worth the engineering overhead to implement this feature when it would only replace 5 lines of bash or 1 line of python.

    I added the discuss label so that other members of our team can weigh in as well.

  3. spenserblack commented on Jun 26, 2023

    @spenserblack
    Contributor

    IMO if you're writing an extension with this type of behavior, you probably don't want to write it in Bash but in Go, and utilize the browser package from go-gh. Since gh uses that package, you should be pretty confident that you'll have very similar behavior between your extension and gh itself.

  4. LangLangBart commented on Jun 27, 2023

    @LangLangBart
    Author

    I am on leaning towards not wanting to support this type of feature.

    Ok. The Python workaround works very well, and many have it installed normally.

  5. vilmibm commented on Jul 17, 2023

    @vilmibm
    Contributor

    we have decided against this in our planning meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussFeature changes that require discussion primarily among the GitHub CLI teamenhancementa request to improve CLI

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions