Can't create PRs from screen sessions

[mgabeler-lee-6rs]

Describe the bug

gh pr create --draft exits with EOF on the "where should we push" prompt when run on Linux with TERM=screen or screen.xterm-256color, but not with xterm-256color

gh --version: gh version 2.2.0 (2021-10-25)

Steps to reproduce the behavior

1. Install screen
2. Start a session from gnome-terminal so the terminal inside the screen has TERM=screen.xterm-256color
3. Create a local branch in a repo and commit something, but don't push it
4. Run gh pr create --draft

Expected vs actual behavior

Expected: Should allow me to answer the "Where should we push ..." prompt normally

Actual: Prints the prompt, then immediately prints an EOF error and exits.

Sometimes gets worse: occasionally spews garbage into my terminal input stream -- as if it sent some "please send me back the X info" to the terminal, and then exited before it go the reply, and so the terminal ends up sending that to my shell. The "garbage" in this case is a mix of alpha-numerics and colons/semicolons I think (don't have one handy however, will update if/when I get one)

Logs

~/src/repo$ gh pr create --draft
? Where should we push the 'censored' branch?  [Use arrows to move, type to filter]
> org/repo
  Create a fork of org/repo
  Skip pushing the branch
  Cancel
EOF

[mislav]

Hi, thanks for reporting! I cannot reproduce. I have gh 2.2 and screen on Ubuntu and even though TERM is screen.xterm-256color, everything works fine with select menus. I don't see how the value of TERM could be breaking gh anyway: we don't pay attention to its value apart from scanning whether "256color" appears in it. Do you think something else on your system could be breaking your terminal?

[mgabeler-lee-6rs]

I could reproduce it in the one screen session (even if I reattached it to a new terminal), and that session hadn't done anything "weird" AFAIK that might've put it in a bad state. But since then I too haven't been able to make it happen again.

If I can't make this happen again today, I'll chalk this up to a transient issue and close this out.

[mgabeler-lee-6rs]

Still can't repro. Terminal must've gotten into a bad state in a way I didn't notice.

[corani]

I have one open tmux pane with this issue. Is there anything I could do to help find the cause for this (before I close that pane)?

[mislav]

@corani Yes, can you tell us your TERM value, gh version, and can you try gh issue create -R cli/cli and see if you can interact with the Choose a template prompt? (You do not actually have to submit a new issue.)

Even if we don't manage to find the root cause for this, I think that's okay because it doesn't seem to be widespread and it only seems to be affecting terminals stuck in some weird state. I think there is a high chance we might never directly address this from GitHub CLI, but any data points are useful for posterity. Thank you!

[corani]

Output:

$ echo $TERM
screen-256color

$ gh --version
gh version 2.2.0 (2021-10-25)
https://github.com/cli/cli/releases/tag/v2.2.0

$ gh issue create -R cli/cli

Creating issue in cli/cli

? Title EOF
^[[65;235R^[[65;9R

Note:

• $TERM is the same for other working panes
• It's not the terminal emulator itself, it behaves the same in kitty, alacritty and even putty
• reset to try to restore the terminal doesn't help
• It's not the git workdir, the same folder works fine in other panes
• Setting $TERM doesn't help (e.g. setting it to dumb)

[mislav]

Thanks for the info! I can't spot what's wrong with this terminal session, but it's curious that Survey gets an EOF when reading from os.Stdin. Is it possible that the stdin stream of this terminal is "closed" somehow?

In a bash shell, can you make a bash prompt and answer a value to it?

read -p "Input: "

[corani]

Yep, that works fine:

$ read -p "Input: " && echo "${REPLY}"
Input: test
test

[leap0x7b]

I can reproduce the issue but now it also occurs with other $TERM values including xterm-256color

wiki on  main
❯ echo $TERM
xterm-256color

wiki on  main
❯ gh pr create

Creating pull request for leapofazzam123:main into main in osdev-wiki/wiki

? Title (use pmarsceill/just-the-docs as the theme) EOF

wiki on  main
❯ [47;88R[47;53R^C

wiki on  main
❯ TERM=screen gh pr create

Creating pull request for leapofazzam123:main into main in osdev-wiki/wiki

? Title (use pmarsceill/just-the-docs as the theme) EOF
^[[47;88R^[[47;53R⏎                                                                     
wiki on  main
❯ [47;88R[47;53R^C

wiki on  main
❯ TERM=dumb gh pr create

Creating pull request for leapofazzam123:main into main in osdev-wiki/wiki

? Title (use pmarsceill/just-the-docs as the theme) EOF

wiki on  main
❯ [47;88R[47;53R^C

wiki on  main
❯ TERM=sinxyebdgwibwysus gh pr create
warning: Could not set up terminal.
warning: TERM environment variable set to 'sinxyebdgwibwysus'.
warning: Check that this terminal type is supported on this system.
warning: Using fallback terminal type 'ansi'.
warning: Could not set up terminal.
warning: TERM environment variable set to 'sinxyebdgwibwysus'.
warning: Check that this terminal type is supported on this system.
warning: Using fallback terminal type 'ansi'.

Creating pull request for leapofazzam123:main into main in osdev-wiki/wiki

? Title (use pmarsceill/just-the-docs as the theme) EOF
^[[47;88R^[[47;53R⏎                                                                     
wiki on  main
❯ [47;88R[47;53R^C

wiki on  main
❯

[leap0x7b]

Looks like it also happens with other commands that has interactive prompts

wiki on  main
❯ gh issue create

Creating issue in osdev-wiki/wiki

? Title EOF

wiki on  main took 4s
❯ [47;88R[47;9R^C

wiki on  main took 4s
❯ gh release create 1.0.0
? Title (optional) could not prompt: EOF
^[[47;88R^[[47;20R⏎                                                                     
wiki on  main
❯ [47;88R[47;20R^C

wiki on  main
❯ gh repo create
? What would you like to do?  [Use arrows to move, type to filter]
> Create a new repository on GitHub from scratch
  Push an existing local repository to GitHub
EOF

wiki on  main
❯

[leap0x7b]

I recently got this issue when I want to create a repository. Restarting the terminal fixes this problem.

[mgabeler-lee-6rs]

I've hit this again ... except in a different app (one of my own creation) which uses the same github.com/AlecAivazis/survey/v2 library for user input ... so I'm gonna guess this bug is really something wrong in that library

Edit: I can repeatably reproduce this now, with this sequence:

1. I have a systemd user unit that sets up a screen session, and re-launches it if it exits
2. When I attach this locally via gnome-terminal, it's OK
3. Where I can reproduce this repeatably is if I exit the running screen session, so that a new one is created, and then attach to it from a remote machine (running the same version of gnome-terminal), via mosh, i.e. by running mosh myuser@myothermachine -- screen -UxRR

[mislav]

@mgabeler-lee-6rs Thank you for sharing! Those steps are indeed a doozy, and based on how obscure this is I don't think we can prioritize fixing this right now. However, you should feel free to also report this to the Survey repository, since the problem is actually there.

What Survey basically does is scans os.Stdin for keyboard input, and I can't guess where an EOF could come from from within the Survey library, so I'm guessing it actually comes from stdin. Since you can reproduce, would you be able to make a simple Go program that reads, for example, a line of input from stdin and see whether that fails as well?

Do any other tools work that take stdin? E.g.

cat
<type something>
<press Ctrl-D>

[mgabeler-lee-6rs]

After a deeeeep dive, I figured out the problem in the survey library. Issue is here, will be submitting a PR to fix it in that library shortly: AlecAivazis/survey#408

Edit: PR with fix: AlecAivazis/survey#409

[mgabeler-lee-6rs]

Upstream has tagged a release with the fix for this: https://github.com/AlecAivazis/survey/releases/tag/v2.3.3

[mislav]

@mgabeler-lee-6rs Thank you for the update and for the upstream fix! I've merged the Survey upgrade to trunk #5337 and will now close this since the fix will ship in the next release.