cli: Clarify error message when someone uses # instead of for pr and issue commands

Describe the feature or problem you’d like to solve

GitHub issues and prs are prefixed with a “#” character. gh issue list and gh pr list commands display them as such:

Issues for ORG/REPO

#1234  [Bug] Red X on dialog box                                 (Bug, GUI, Linux, …)
#2345  [Bug] NullReferenceException encountered during downl...  (Bug, ConsoleUI)

But if you try to view one of these issues using the key as listed:

$ gh issue view #1234
issue required as argument

Proposed solution

If the parameter following a view command starts with a “#” character, attempt to parse the remainder of the string as a number before reporting failure.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 19 (16 by maintainers)

Most upvoted comments

Given how shells interpret # we don’t plan to support this. That said, I’m thinking we can start leaving the # off of the output of list/status output commands to make copy-pasting easier? Curious if folks have thoughts on that.

vilmibm on Feb 14, 2020

It might help if the error message gave you more info about the expected gh issue view 123 usage. When I saw “issue required as argument” I was like “but I GAVE IT TO YOU as an argument!”

We are generally in favor of better error messages. However, if someone writes (or pastes) gh issue view #123, since the #... portion is completely stripped by their shell we cannot know at execution time that there was an argument to start with. Therefore, gh issue view #123 is functionally equivalent to gh issue view, and we cannot improve the error message in this case.

mislav on Feb 19, 2020

In the case of zsh, we could potentially tolerate the #123 input

@mislav I think if you do that, people using zsh will write tutorials or share commands that mysteriously fail when Bash users try them. 😬

markjaquith on Feb 20, 2020

gh issue view #123 is functionally equivalent to gh issue view, and we cannot improve the error message in this case.

@mislav You can still improve the error message without knowing that they typed a hash-prefixed issue number.

Scenario A

User types: gh issue view
gh “sees” gh issue view
gh tells them that an issue argument is expected, as well as the expected format (issue integer or issue URL).

Scenario B

User types gh issue view #123
gh “sees” gh issue view
gh tells them that an issue argument is expected, as well as the expected format (issue integer or issue URL).

I think that the info about the expected format is useful regardless of whether they omitted the argument or their shell stripped the argument.

Also note that the hash is not universally stripped. I’m using iTerm2 and zsh in macOS Catalina, and gh absolutely sees the #123:

~ ❯ echo #123 #123

Scenario C

User types gh issue view #123
gh “sees” gh issue view #123
gh tells them that an issue argument is expected, as well as the expected format (issue integer or issue URL).

It would be a small thing that, instead of vaguely telling people their input was incorrect, guides them towards making their input correct.

markjaquith on Feb 19, 2020

@markjaquith thanks for your input, and I totally agree with how you framed this!

Let’s leave the #123 syntax, and make the error message clearer 👍

ampinsk on Feb 18, 2020

I’m thinking we can start leaving the # off of the output of list/status output commands to make copy-pasting easier? Curious if folks have thoughts on that.

It would make copy-pasting into the CLI easier, but I think it sacrifices some clarity when listing Issues. #123 is how GH displays Issues. That’s very clearly a GitHub Issue. Also, copy-pasting into an Issue or a comment SHOULD contain the #. I don’t think it’s a clear win.

It might help if the error message gave you more info about the expected gh issue view 123 usage. When I saw “issue required as argument” I was like “but I GAVE IT TO YOU as an argument!”

It wasn’t immediately clear that it was the integer only that was expected.

markjaquith on Feb 18, 2020