-
-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Return standard output in popen_write
#8541
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using `popen_write`, the expectation is to return the standard output of the child process. This expectation is evident in how `safe_popen_write` is written: ``` def self.safe_popen_write(*args, **options, &block) output = popen_write(*args, **options, &block) return output if $CHILD_STATUS.success? raise ErrorDuringExecution.new(args, status: $CHILD_STATUS, output: [[:stdout, output]]) end ``` However, no code has been written to actually *obtain* that output from the child process. The side effects of that are described in issue #8244. [1] [1]: #8244 The newly-added tests reveal that `popen_write` only returns the number 4 instead of the expected standard output. For example, given a file `foo` with the content `Foo\n`, one test calls `popen_write` with `cat foo -` and an input of `Bar`. The expected output would be `Foo\nBar\n` but the actual output is the number 4 (which is what Ruby’s `IO#write` method returns).
MikeMcQuaid
reviewed
Aug 31, 2020
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.
Nice work @claui!
Fix tests and fulfill intended semantics by having `popen_write` transparently capture standard output.
MikeMcQuaid
reviewed
Sep 1, 2020
MikeMcQuaid
approved these changes
Sep 2, 2020
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.
No blocking comments, thanks @claui.
MikeMcQuaid
approved these changes
Sep 2, 2020
Thanks @claui! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
brew style
with your changes locally?brew tests
with your changes locally?Expected behaviour
We expect the
popen_write
method to return the standard output of the child process.This expectation is evident in how
safe_popen_write
is written:Actual behaviour
Contrary to what the above code suggests, no code has been written to actually obtain any output from the child process. Newly-written tests show that
popen_write
only returns a number ("4") instead of the expected standard output.For example, given a file
foo
with the contentFoo\n
, one of the tests callspopen_write
withcat foo -
and an input ofBar
. The expected output would beFoo\nBar\n
but the actual output is the number 4 (which is what Ruby’sIO#write
method returns).Fix
By having
popen_write
transparently capture standard output, we restore the intended semantics.The practical purpose of this PR is that when an embedded formula patch fails, it now displays the actual output of the
patch
binary (instead of the length of the patch).Fixes #8244.