Merge in coreos/gexpect? #33
Open
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
This function returns the output of the child, which might be of interest for the caller.
- New function that returns the output of the child, which might be of interest for the caller. Also offers to timeout after a specified time. - Introduces tests for regex related functions.
include output in the error when a timeout occurs
examples: fix import references
The expectRegexOutput uses the regexp.FindReaderSubmatchIndex function
to do the matching. As its docs say, it may read more characters than
it is necessary from the stream. This may be problematic if the regex
we use can match chunks of the stream that come right after
another. This is because the function might match the first chunk and
read into the middle of the second chunk, so the subsequent call to
the function will match the third chunk, not the second. For example:
data: "one two three"
regexp: "\w{3,}"
The first call to the function may return "one" as a match and "one
tw" as an output. We can see that the output has the beginning of the
second word which comes after the matched first word. This part is not
available anymore in the stream, thus the following call to the
function will return "three" as a match (instead of "two") and "o
three" as an output.
To fix it, we put the excess characters coming after the whole match
back into the stream, so the subsequent calls to the function may
start their matching from the place when last whole match ended.
Put excess characters from regexp matching back into the buffer
This merges fixes from the upstream repository.
merge upstream changes
In buffer.ReadRune the utf.FullRune checks given slice if there is enough bytes for multibyte utf8 encoded unicode character, but because chunk is always UTFMax long check is always true, without actually getting remaining bytes to decode rune correctly This fix passes only slice of actual (according the n for buffer and l for file) read bytes to FullRune. Includes unittest for ReadRune with partially filled buffer.b.
fix buffer.ReadRune for multibyte unicode characters
Merge changes from upstream
This commit changes Expect() to not return early errors on final reads (`EOF` but `n != 0`) in order to avoid discarding the last bytes from the source buffer. According to Reader interface next loop iteration will get a (0, EOF) causing this method to return.
expect: do not prematurely return error on last read
Signed-off-by: Sven Dowideit <[email protected]>
Fixes to let me copy&paste examples
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Seems like some useful features.