-
Notifications
You must be signed in to change notification settings - Fork 14
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
Enhancement for Issue #61: Provide Real-Time Output for External Subcommands #73
Comments
@jeffw16 @yaronkoren @amalpaul54111 would you please take a look at this? |
Yes,I feel like this is the way to go. |
I had tried to solve the particular issue, but main issue I faced was not being able to print live output along with saving it to a variable, which is necessary for taking decisions following it or to print the output after exiting due to an error in case --verbose was not used. |
@amalpaul54111 @jeffw16 I'd like to take a shot at it (if it isn't being actively worked on currently). |
@chl178 I agree with you that we should do this. Did you want to write the code to do this? |
Yeah, I would like to do it. |
@aerowisca Thank you for your understanding to allow the issue author to work on their own proposal. :) |
Yeah, sure thing. Also, @amalpaul54111 as for your concern : That should be easy to accomplish, we can set |
provided real-time output(CanastaWiki#73)
* Update execute.go provided real-time output(#73) * provided real-time output * provided real-time output * provid real-time output * Delete .DS_Store * Delete .DS_Store * Further merge fix * Remove stray tab --------- Co-authored-by: Yaron Koren <[email protected]>
Issue #61 brings attention to the problem of insufficient information when running external subcommands, such as docker-compose. While it may seem that passing the verbose flag to subcommands could resolve this issue, I believe it's not enough. This is because our Run() function currently only prints the output of external commands after they have finished executing.
Thus, even if we pass verbose to the external subcommand, we would only receive the information after it has completed its work.
To address this limitation, I propose that we modify the Run function to provide users with real-time output from external commands. This way, they can have all the information they need to understand what is happening during long-running commands as they happen, instead of having to wait until the command is finished.
The text was updated successfully, but these errors were encountered: