[
https://issues.apache.org/jira/browse/DAFFODIL-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17677752#comment-17677752
]
Mike Beckerle commented on DAFFODIL-2771:
-----------------------------------------
Test is in https://github.com/apache/daffodil/pull/912
> Expect library - not working with CRLF data
> -------------------------------------------
>
> Key: DAFFODIL-2771
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2771
> Project: Daffodil
> Issue Type: Bug
> Components: Infrastructure
> Affects Versions: 3.4.0
> Reporter: Mike Beckerle
> Priority: Trivial
>
> Finding odd behavior from the CLI expect library.
> I can work around it, but I wasted many hours in frustration with this.
> I created a CLI test using the expect library.
> It is an unparser test.
> It is fed a trivial element like
> {code:java}
> <a>abc\uE00D\ndef\uE00D\nghi</a>{code}
> It is supposed to convert those E00D chars back into regular CRs (aka '\r'),
> which is the new functionality I have been adding.
> First issue.
> cli.expect calls expect.expect(contains(str)), and if I put a breakpoint
> inside the contains call, that code looks like this:
> {code:java}
> public Result matches(String input, boolean isEof) {
> int pos = input.indexOf(string); // BREAKPOINT HERE
> return pos != -1
> ? success(input, input.substring(0, pos), string)
> : failure(input, false);
> }{code}
> Strangely, this gets called before any unparsing happens.
> This first time, which seems spurious, the input string is empty, so this
> obviously fails. But that seems to just get ignored.
> If I just continue past this spurious breakpoint, then the test runs.
> The Daffodil unparse works here. I can debug and watch it write out the 13
> bytes successfully to the java output stream at line 689 of
> DataOutputStreamimplMixin.scala.
> Second issue:
> But the test then uses the expect library to test this output, which has been
> sent to ordinary stdout of the unparse and via piped streams back to expect.
> Here's the expect again, which is getting called a second time.
> {code:java}
> cli.expect("abc\r\ndef\r\nghi"){code}
> That second time, at the same breakpoint, the input is:
> {code:java}
> "abc\ndef\nghi"{code}
> that is, 11 characters. Not 13, and the CRs are not there.
> This stuff is all java 'streams" not readers/writers, so should not know nor
> care about textual issues like lines/line-endings. Yet the data is clearly
> being modified.
> I have saved the test that causes this problem.
> test_CLI_XMLConversionControlPreserveCRUnparseToStream
> I worked around this by writing the output to temp files, then reading the
> data back to compare it. This works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
