Repository navigation
gh search prs messing query with flags and raising "unknown shorthand flag: 'l' in -label:some-label" #10467
Description
Activity
- changed the title
[-]gh search prs raising "unknown shorthand flag: 'l' in -label:ready to merge"[/-][+]gh search prs messing query with flags and raising "unknown shorthand flag: 'l' in -label:some-label"[/+]on Feb 19, 2025 Thanks for raising this concern, @rrebollo 🙇
Have you tried using the
--delimiter to signal the shell shouldn't treat arguments as flags?At first glance, this seems like a standard shell execution confusion with arguments versus flags. Situations like this require clearer signaling of where flags end and arguments begin.
The
gh search prsdocs has an example that shows this in more detail:# search pull requests without label "bug" $ gh search prs -- -label:bugFor your command, it would look something like this:
gh search prs --sort=created --order=asc -- org:OCA -label:approved state:open
Could you confirm ☝ works?
Reacted by Rolando Pérez RebolloThanks to you all for this great tool @andyfeller. You are completely right. Using the query structure you proposed works as intended but ... I had simplified the original query in order to isolate what I thought was the main issue. So even with your suggestion was not straight for me getting what I wanted. I think examples should consider more complex use cases and people like me won't waste your time.
I was trying to get the open PRs to repositories belonging to an organization from several specific authors without some labels. I got finally working with something like this:gh search prs --sort=created --order=asc -- org:$ORG state:open -label:$LABEL1 -label:$LABEL2 and author:$AUTHOR1 author:$AUTHOR2The
andwas really important.Reacted by Andy Feller...and people like me won't waste your time.
Please allow me to say I and my fellow maintainers appreciate genuine engagement with our community and that it always presents us with opportunities. ❤
I think examples should consider more complex use cases...
Is there a particular degree of complexity that is essential to capture in
ghhelp usage statements versus guiding users to the GitHub Docs on searching?There is a bit of a challenge here because of the endless combinations someone could be interested in and that all of it is managed within the GitHub APIs which are out of band to GitHub CLI. This is why our help docs point to the GitHub Docs, where Issues and PRs teams work with our Docs team to capture that information there. Otherwise, it is potentially stale or incorrect much less being a feature only supported in specific distributions.
Is there a particular degree of complexity that is essential to capture in
ghhelp usage statements versus guiding users to the GitHub Docs on searching?If you ask me: too many steps to get the whole picture. gh help, Github Search Help (it's also split: github.com/search, issues and prs, generic syntax (not, parenthesis, negation..., then by every single isolated criteria ...) In real life normally you should combine multiple features so, do you get my point?
Reacted by Andy FellerIf you ask me: too many steps to get the whole picture. gh help, Github Search Help (it's also split: github.com/search, issues and prs, generic syntax (not, parenthesis, negation..., then by every single isolated criteria ...) In real life normally you should combine multiple features so, do you get my point?
I completely understand, @rrebollo 👍 Thinking about this issue, there are 2 things I'd like us to follow up on:
-
@andyfeller : create follow up issue to see if we can improve the documentation of
gh searchcommands to highlight the use of--in the--helpusage -
@rrebollo : I'd like you to consider what additional examples of notable search scenarios we should include in
gh searchcommands and open an issue with your suggestionsYou have a fair point that I'd captured in your own words without me assuming the extent of complexity you think is reasonable. Bonus points if you can cite search queries against public GitHub repositories that we can collective look at.
Reacted by Rolando Pérez Rebollo and Melissa Xie-
created #10480
Describe the bug
gh help states
queries built with GitHub search syntax are supportedbut it looks like gh is messing query with flags and raisingunknown shorthand flag: 'l' in -label:some-labelAffected version
2.67.0
Steps to reproduce the behavior
gh search prs org:OCA -label:approved state:open --sort=created --order=asc`unknown shorthand flag: 'l' in -label:approved
Expected vs actual behavior
I was hopping default output for search results
Findings
I don't get any logs when setting GH_DEBUG. gh help states
gh search prs [<query>] [flags]as general structure for calls so gh is misleadingly recognizing-labelas flag instead as query.