ly ERROR: Invalid character 0xd

[PramodKAvvaru]

Hi,

I am seeing the parsing errors during listen at netopeer2-cli if there are a different line ending format in the yang file.
Although the yang file needs a fix, is there a way to ignore the mismatch in line endings at the netopeer2-cli?
I am using a windows based yang file to load on a Unix machine running Netconf server.

Error message
ly ERROR: Invalid character 0xd. (Line number 167.)

yang file snippet:
when "(../../transport-session-type = 'ALIASMAC-INTERFACE') or
\n(../../transport-session-type = 'ETH-INTERFACE') or
\n(../../transport-session-type = 'SHARED-CELL-ETH-INTERFACE')";

Many thanks,
Pramod

[michalvasko]

I have failed to reproduce the problem, both line endings should be supported on any platform. Could you provide the YANG file? What libyang version are you using?

[PramodKAvvaru]

Hi @michalvasko, thanks for your prompt reply. Here attached the yang file which was used on the Netconf server.
o-ran-processing-element.yang.zip

[michalvasko]

Alright, that is a really specific way of encoding the newlines, should now be supported.

[PramodKAvvaru]

Hi @michalvasko, thanks for the quick fix. The fix is corrupting the schema received by the Netconf client.
The original schema section:

        choice up-markings {
          description
            "U-Plane markings";
          case ethernet {
            when "(../../transport-session-type = 'ALIASMAC-INTERFACE') or
\n(../../transport-session-type = 'ETH-INTERFACE') or
\n(../../transport-session-type = 'SHARED-CELL-ETH-INTERFACE')";
            leaf up-cos-name {

Schema received by the Netconf client:

        choice up-markings {
          description
            "U-Plane markings";
          case ethernet {
\n(../../transport-session-type = 'SHARED-CELL-ETH-INTERFACE')";RFACE') or
            leaf up-cos-name {

Hence, I believe this commit needs to be reverted. Also, the original issue was with schema and so there is no fix required.
Sorry for wasting your time.

[michalvasko]

Right, the print was mingled by that \r so it should not be stored at all. But the module is valid so it needs to be handled somehow, should work as correctly as possible now.

[PramodKAvvaru]

Thanks for the fixes, @michalvasko.