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
Retaining color of STDOUT #33
Comments
Thanks for using the gem! Sure thing, I will take a look, it seems like a bug as there shouldn't be any mingling of the output going on and all the coloring should be preserved. |
It may well be the case that the subprocess that I call will strip away any ansi codes from the output stream. If you find a fix then by all means please submit PR, I will happily review and merge. |
I'm afraid I don't have the time at the moment but if I come across a solution in the future I will let you know. |
@thisismydesign Please see referenced test and example that demonstrate that the ansi codes are preserved for both the actual output and captured output. |
@piotrmurach Thanks for looking into this. Unfortunately this does not cover / solve my use case. The root cause is probably explained in the already linked StackOverflow answer:
I think it would be worthwhile to reopen this issue / add some clarification to the readme so that others stumbling upon this have a reference or can maybe think about providing a solution. |
@thisismydesign Sorry I got too excited closing tickets 😄 I have no problem keeping this open until a suitable solution is found or we add a note to readme to warn people of this use case. |
@thisismydesign Turns out that this is possible by running command in pseudo terminal. I've added |
Thanks a lot! Sure thing, will get back to you. |
Works great, thanks! |
I'm still undecided whether the |
I think leaving it false by default probably makes sense (although I agree, hard to say, but you gotta pick something!), but the README should probably include a section explaining the setting and it's consequences. |
I think the line feed changes are ok as devs can expect it but it's definitely a breaking change. I'm worried about other side effects too, e.g. came across this yesterday when reading about the I'd not make it default before more testing and feedback. Introducing a breaking change of course complicates things further. If you plan some cool new features for the gem it would suck to place them after a major version bump. Otherwise it might be harmless and actually beneficial to make it default sometime in the future. Deprecation warnings beforehand and providing a feature that normalizes line feeds would definitely help with adaptation. Performance-wise I imagine this adds some overhead but it's not a multiplier for the whole command execution in which case I think it'd be ok to have it on by default. It's not a black and white decision. Hope this was somewhat helpful and I didn't confuse you even more. :) |
Thank you both for your thoughts! @jrochkind I have added the PTY(pseudo terminal) section to docs. Would appreciate any comments? @thisismydesign I'm using After reading C source for pty.c I have discovered that you can actually put the pty slave device into raw mode. What that means is that there will be no mingling of the output. I think I will make the |
@piotrmurach Cool, hope you will include the raw mode by default for the Definitely agree that it should not break on Windows but to be fair you could easily determine which system the gem is running on. If for nothing else it'd be useful to fail meaningfully when the user tries to use the Will try to incorporate your gem into mine over the weekend, that should give us some more feedback. |
From my experience this is the hardest thing to accomplish and detecting operating system usually produces the least reliable way to handle cross platform support in Ruby. This is predominantly due to different bash-like emulators such as As far as colors on Windows, I have VM setup for windows xp where I test Ruby libs in powershell and the windows console provides support for basic ANSI color strings. Thank you trying the gem out, this is super helpful! |
@thisismydesign been knocked down by flu fore more than a week now and hence failed to finish this. I've provided a fallback to normal behaviour if pty doesn't exist on whatever the system a command is run. This is definitely a more graceful way to handle this situation. Also, I get to display warning to say what happened - I didn't think it deserved a full blown error message. Making pty raw requires including new dependency on The more I think about this library primary use case which is logging output, it becomes apparent to me that having |
@piotrmurach No worries. I also haven't gotten as far yet as I hoped with incorporating your gem. You made good points and in light of them I also agree that it makes more sense to keep Is there a way to set the raw mode from the outside so those willing to live with the additional dependency can keep the same functionality? |
@thisismydesign I was wrong! The |
@thisismydesign I've release |
@piotrmurach Thanks a lot! I'm currently facing an issue with hanging commands. I have a very strong suspicion that the hanging is caused by paging. Consider the following command: When executed in a smaller terminal: And finally when pressing a couple enters:
This also made me think about some more broad questions. Might not at all be at scope for this gem but wondering whether it's possible / would make sense to:
|
Oh and by the way the |
Got it meanwhile... https://stackoverflow.com/questions/2183900/how-do-i-prevent-git-diff-from-using-a-pager It may warrant a warning in the README that using a pseudo terminal can have side effects. |
@thisismydesign The side effects and the fact that running command in terminal mode is not the intention behind majority of uses cases motivated me to set
I will update the docs further to explain this better! As far as exposing the streams directly, there is already an issue discussing the possible api which you may wish to check out. I'm not sure I understand the
Currently the output is streamed as the command continues to execute. It's in separate thread and keeps reading until the output is exhausted. That was original point of this library to help provide streaming output. |
@piotrmurach Thanks for the doc update!
You're right, my mistake I used the wrong printer. :) |
@thisismydesign No problem! If you have any ideas etc... just open new issue so that we don't carry on this monster of a thread 😅 |
Hi there,
First of all, great gem!
I was happy when I read colorful output, however it seems that it only applies to your gem's output and not the original command's.
Do you have any plans to make it possible to retain the color of the original output, or do you know whether that's even possible? According to my limited understanding you should somehow pretend to be a tty.
The text was updated successfully, but these errors were encountered: