[
https://issues.apache.org/jira/browse/DAFFODIL-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17677768#comment-17677768
]
Steve Lawrence commented on DAFFODIL-2771:
------------------------------------------
This is expected behavior. Though, maybe it's not the right behavior?
We ran into issues where the CLI would output different line endings depending
on the OS you ran it on (println is OS aware). And so CLI expect calls would
fail if a test expected "foo<LF>bar", and windows output "foo<CR><LF>bar". To
avoid having to worry about this since few, if any, CLI tests care about
newlines, we added an expect filter that converts all CRLF to LF, with this
line in Util.scala:
eb.withInputFilters(replaceInString("\r\n", "\n"))
We can consider removing this and adjusting any tests that expect a newline to
be OS aware, but it might start to get messy if we have a lot of that, so we
need a clean way to do it.
Another option is maybe we can add a flag to the runCLI function to disable
this filter for the instances where a test really does want to differentiate
between CRLF nd LF and can be smart about Windows vs Linux.
> 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)
