Mike Beckerle created DAFFODIL-2771:
---------------------------------------
Summary: 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
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)
