-
Notifications
You must be signed in to change notification settings - Fork 13
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
Disable terminal echo while State Tool is running. #2882
Conversation
97cb81d
to
5dbd4bf
Compare
The exception is for prompts and subshells (which temporarily re-enable echoing).
5dbd4bf
to
7c45563
Compare
|
||
func (v *SubShell) TurnOffEcho() { | ||
if runtime.GOOS == "windows" { | ||
return // not supported |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Windows does not have access to the termios functions needed to disable echo in emulated shells like Git Bash (which is not interactive anyway).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something that's not obvious in this PR is how the echo is re-enabled for prompts... how is that handled?
internal/subshell/bash/bash.go
Outdated
if runtime.GOOS == "windows" { | ||
return // not supported | ||
} | ||
termecho.Off() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't these, and the other TurnOnEcho
functions be calling termecho.On()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, how embarrassing. Thanks for catching this.
// Disable terminal echo while State Tool is running. | ||
// Other than in prompts and subshells (which temporarily re-enable echo), user typing should | ||
// not interfere with output (e.g. runtime progress bars). | ||
sshell.TurnOffEcho() | ||
defer sshell.TurnOnEcho() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this also disable ctrl+c and other similar inputs? I don't believe that's something we want to disallow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, is it possible that if the state tool errors mid-execution, we could leave the user's shell in a state where they cannot echo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You didn't see this, but in my original PR (#2768), I noted that echo is restored after ^C, so no problem there. The defer
does its job.
If there is a hard crash, echo will probably be lost, but this is the case for any terminal program that messes with termios, so the only resolution is for the user to exit this terminal and start up a new one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the defer
will run even on a panic as long as it's on the function call stack so we should be good even in the event of a crash as this defer is placed ahead of the actual command logic.
As mentioned in the PR description, the survey library automatically handles the flipping on/off of terminal echo. I don't know exactly how it does it, but during testing it did. |
The exception is for prompts and subshells (which temporarily re-enable echoing).
Note: the survey package does this automatically, so no changes to the prompt package are required.