-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh pr list
doesn't write output anywhere if stdout or stderr is piped
#9152
Comments
Hey @gibfahn, this took me a moment to track down so I can understand why you would be confused. This isn't a case of the output disappearing as you suspected but actually it's a behavioural difference in the CLI such that we don't treat the second case as an error. In the first case, where we know that there is interactivity, the CLI bails out saying "we really want to you to choose a default repo for us to target" (see: I'd have to check whether there are other issues around the decision above and I'm happy to go searching for them if you still have a problem but I'm going to close this for now since the specific issue is addressed. Cheers. |
Ahh okay, I guess trying to simplify the output didn't fully repro, how about this one? ❯ GH_REPO=gibfahn/brew GH_HOST=github.com gh pr list --state=open --limit=1
no open pull requests in gibfahn/brew
❯ GH_REPO=gibfahn/brew GH_HOST=github.com gh pr list --state=open --limit=1 | cat
❯ I expect to still see the log message when something goes wrong. For context I'm seeing this in a script where I'm saving the output to a shell variable to work around #575 . When the command doesn't return any results, it's useful to be able to see what went wrong.
❯ GH_DEBUG=1 GH_REPO=gibfahn/brew GH_HOST=github.com gh pr list '--state=open' '--limit=1' | cat
* Request at 2024-05-31 15:21:01.749336 +0100 BST m=+0.144867168
* Request to https://api.github.com/graphql
* Request took 427.841208ms
❯ |
Thank you for the clarification. I'll have to think about this and a comment from a previous maintainer a bit more. Consider a workflow "find me all the open PRs and assign me as a reviewer". From a When hooked up to a terminal, we try to provide a helpful message. I could see us printing something to
This was just to highlight the repo that was being targeted, to ensure that it was the one you expected given my explanation of |
The reasoning behind each of these decisions does make sense (thank you for sharing it!), but overall it leads to quite a confusing debugging experience, where my script fails because there was no output, so I try to change the command, and then it starts printing errors, and I change it again, and now it prints different errors, and none of them are the actual thing I need to debug (which ends up being that the upstream for the current branch is configured wrong, so there was no output). This gets more complex when you start using the At the risk of adding more complexity, I would happily take an option here that made |
I came across this issue while searching for a similar problem with no errors involved. I'm just trying to get the output from
But trying to pipe it anywhere ( In my case, I think the issue is something with the
|
That's incredibly strange! Are you saying the following command produces no output for you, and without
|
I just tried Woah, but a different repo does work! This is very strange. |
That's uhhh interesting. Can you see if there's anything interesting with |
I'm not quite sure what I'm looking for, but the GraphQL query in the
and the final data is empty:
whereas the no-cat version has multiple queries, starting with
and then the PullRequest query, which returns data in that case. All of the requests are returning HTTP 200. I can upload the output from the command if that would help, but redirecting it to a file means I can only get the "cat" version. I guess I could install a terminal with better scrolling and paste the other output if needed. |
Are the query and variables exactly the same? From your first log:
The full output would be useful. You may be able to force it to output by setting |
Is there anything I should redact from the output before uploading? The token looks like it's already blocked out, and the only other thing I see that is possibly sensitive is the |
Nothing sensitive unless there's anything that you want to redact from your own data (repo names, issues, authors, and that kind of thing). |
Awesome, thanks! These are all public repos and the PRs are all from Dependabot (which is why I'm hoping to automate this a bit). Here's the full
and no cat:
|
Well, these are indeed searching different repos:
vs
I'm thinking that there's a redirect going on here that is causing some confusion. Would it be fair to say that your |
Ahhh, that makes sense. I did rename this repo a while back. |
It seems like the search infra doesn't account for redirects while indexing. Would you mind creating an issue on this repo quickly summarising what we've found here (I would but it's pretty late here already!). I'm not sure what our options are here but I'd like to think about it next week. Sorry for all the noise @gibfahn ! 😬 |
Will do, thanks for the help! And yes, sorry for the noise. I thought this would be more relevant at first! |
Hoping to ground this somewhere in design artifacts, I think the only 2 I could really find are:
So it is a small comfort at least this much is documented though not necessarily the reasoning why. That said, I don't think screen output is a hard contract as structured data would be the less brittle route. |
Bringing the discussion back to the original report, @gibfahn you could do this: GH_FORCE_TTY=true NO_COLOR=1 gh pr list 2>&1 1>/dev/null | cat EDITS:
|
@andyfeller This is a good discussion, thanks for the resources! It seems those guidelines are related to machine-readability of output when there is no TTY, which I think in general it is good practice to print to
Additionally, when discussing where color should be disabled, one of the points is:
That implies it's good practice to print to A good example would be checking the logs when using However, I also agree that breaking changes are bad and I'm not sure if this is worth one. It could be worth considering the
|
This adds number of comments and reactions in listing of `gh search issues` and `gh search prs` results.
Describe the bug
When you pipe the stdout or stderr of
gh
somewhere, it no longer writes useful output to the stderr.Steps to reproduce the behavior
Using latest brew gh version:
Expected vs actual behavior
I expect to see the error on the stderr even when I save the output on the stdout.
The text was updated successfully, but these errors were encountered: