Skip to content
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

Have cmdrunner use a tty #988

Merged
merged 5 commits into from
Oct 8, 2020
Merged

Conversation

Seanstoppable
Copy link
Collaborator

This lets us get proper coloring
Fixes #577

Looking at the below, it looks like something is not clearing the color correctly (likely another underlying library bug)

Raw command line:
Screen Shot 2020-10-06 at 11 22 16 PM

CmdRunner pre-commit:
Screen Shot 2020-10-06 at 11 20 27 PM

CmdRunner pre-commit, forcing color:
Screen Shot 2020-10-06 at 11 37 08 PM

CmdRunner post-commit:
Screen Shot 2020-10-06 at 11 21 44 PM

err := cmd.Run()
f, err := pty.Start(cmd)
if err != nil {
panic(err)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should panic here. If the pty fails for some reason, we should fall back to the old way to still provide command output.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Major brainfart on my behalf.

@senorprogrammer
Copy link
Collaborator

This looks great. I'll try to get it in today.

@sam-github
Copy link
Collaborator

sam-github commented Oct 7, 2020

Not sure if it matters, but pty is unlikely to work on windows, which doesn't have them. I'm not sure (I don't have windows :-), maybe the pty module builds and gently errors out, instead of just failing to compile? EDIT - hm, maybe it does work on Windows, see creack/pty#67

Doesn't have to be now, but running in a (pseudo)tty should perhaps become optional. Some commands change their behaviour based on whether they are in a tty or not, for example, they might assume that a progress bar should be written if running in a tty because its a user running it interactively, but that might not be wanted if the command is running in wtf and only the output is wanted. Just a thought.

@Seanstoppable
Copy link
Collaborator Author

@sam-github I hadn't thought about that. I added this mostly because if you look at the linked issue people were complaining that commands were not getting colorized be default, and they felt that was unexpected. Perhaps another option is to not even do this and just have additional wording around colorization in the docs.

@senorprogrammer
Copy link
Collaborator

That's a great point, and it does matter. There are people using this on Windows and we should not break things on them needlessly. Make it opt-in via config?

@sam-github
Copy link
Collaborator

I like colours, I think this solves a real problem, I didn't mean to suggest it wasn't useful.

Executables really do change their behaviour based on isatty(), so its great to be able to run them (or not, as needed) in a tty. Whether defaulting to being in a tty or not is right, I don't know. The plus side of in a tty is that the output would look like people see when trying the command in a shell, so it helps debugging, though for that, actually running in a shell would help, too (that's not related to this PR, though).

The downside is it might not be backwards compat, but I don't think wtf cares too much about that. I don't even think you should make it configurable if you don't have the interest, that can happen if someone actually has a problem, and wants to PR that themselves.

@senorprogrammer
Copy link
Collaborator

"The downside is it might not be backwards compat, but I don't think wtf cares too much about that"

We care very much about backwards-compatibility :)

@Seanstoppable
Copy link
Collaborator Author

The things we do for backwards compatability :)
I'll add a config option for it, as well as update the docs to try to make some of this clear
As the original ticket demonstrates, some things do have the option to force color, but presumably all things do not and may just make implicit choices.

@Seanstoppable Seanstoppable force-pushed the cmdrunnertty branch 2 times, most recently from 0576d87 to 9a609a6 Compare October 7, 2020 23:11
This lets us get proper coloring
Fixes wtfutil#577
Don't panic
Add function due to reuse
Catch all errors to appease CI
@senorprogrammer
Copy link
Collaborator

Something strange is going on with this one. It's blocking my local test run and the Travis test run when it gets to the tests in github.com/wtfutil/wtf/view.

It doesn't look like it needs the tview upgrade, I think we should leave out of here (assuming that's the problem), and deal with that issue separately. That way this can get merged.

@Seanstoppable
Copy link
Collaborator Author

Sounds good. I upgraded to see if it would help with coloring a bit, but didn't seem to have an impact.

@senorprogrammer senorprogrammer merged commit 4064d42 into wtfutil:master Oct 8, 2020
@senorprogrammer
Copy link
Collaborator

Nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

cmdrunner should maintain color of output
3 participants