gh search repos cannot handle multiple query terms and results in Invalid search query.

[TWiStErRob]

Describe the bug

A clear and concise description of what the bug is. Include version by typing gh --version.

Steps to reproduce the behavior

1. Type this gh search repos "user:TWiStErRob -is:fork -is:archive"
2. View the output

Expected behavior

Lists my "active" (i.e. non-fork, non-archive) repositories.

Actual behavior

Invalid search query "user:\"TWiStErRob -is:fork -is:archive\"".
The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.

Additional context

I also tried gh search repos -- "user:TWiStErRob -is:fork -is:archive" which gives the same.

gh search repos -- user:TWiStErRob -is:fork -is:archive does list the repositories, but it includes archived ones.

Swapping the search query terms results in similar error:
gh search repos -- "-is:fork -is:archive user:TWiStErRob"

Invalid search query "-is:\"fork -is:archive user:TWiStErRob\"".
None of the search qualifiers apply to this search type.

I'm aware of gh search repos --owner=TWiStErRob --include-forks=false --archived=false, but I want the "query" to be "user input" to a script. So I can't use gh cli arguments in there, only raw repository query.

[williammartin]

Hmm, I think I see what's going on here and I think it's kinda unintuitive at first glance. Your single arg "user:TWiStErRob -is:fork -is:archive" is being treated as a single keyword searchuser: .... I can see this in the error response, the HTTP query string with GH_DEBUG=api on, and in the code itself. The search repos command expects terms to be space separated.

This means you can do things like gh search repos "user:TWiStErRob" "fork:only" to list only your forks (by default forks and archives are not included if I recall correctly).

And as you want to do negation with - I think that you will need to provide these after -- to ensure they act as positional arguments e.g.:

 gh search repos -- "user:TWiStErRob" "-is:fork" "-is:archive"

That it works this way is pretty unclear from the help IMO. Can you double check that works for you before we get any further?

[TWiStErRob]

The separated ones after -- just ignore the rest of the filters (note the yellow "archived" tags):

[TWiStErRob]

Oh, wait, it actually seems to work somewhat, but is:archive is not a thing, it's archived:false... but gh doesn't tell me that.

[williammartin]

it's archived:false... but gh doesn't tell me that.

Yeh I looked back through the issues as I was investigating. Originally when a PR went in for this the CLI did some kind of enumeration of the known values but it was rejected because it means that every time something new is supported on the UI and API, we would need to add it and people would need to upgrade their CLIs, so it's a bit limiting in forward compatibility.

That said, I wonder if there are a set of common mistakes that get made that we could reject.

[TWiStErRob]

The server side doesn't validate the query? Oh, I guess is:archive is a valid query as the name/code etc. could contain it.

---

So the OP is valid, right?

gh search repos -- "archived:false user:TWiStErRob -is:private"

should just work, rather than having to rewrite (parse and reserialize) the query into:

gh search repos -- "archived:false" "user:TWiStErRob" "-is:private"

---

Also -is:private seems to be ignored too... but that's a backend issue, because on the website I'm also seeing (Private) repos in the search results...

[williammartin]

The server side doesn't validate the query?

I think it does some but there's been a divergence between the frontend/api and the engine that powers search. Like, the docs say is:fork should work but it sure seems like it doesn't. Something tickles my memory that is: not working is a known issue since the search engine changed. However I'd have to go searching and don't have time now. I believe fork:true fork:only and friends are the correct way to do this now.

So the OP is valid, right?

From my point of view I think it should be valid because it's obviously more intuitive than splitting them up when thinking about how the Web UI works. However I'd need to think carefully if changing the parsing logic for the positional args might be a breaking change.

At the very least we should update the help with examples showing how to do more advanced querying in the meantime.