Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pattern - error with escaped characters #6

Open
michaelfruth opened this issue Jul 10, 2020 · 1 comment
Open

pattern - error with escaped characters #6

michaelfruth opened this issue Jul 10, 2020 · 1 comment

Comments

@michaelfruth
Copy link

Hello,

There is a problem when using escaped characters in a pattern. E.g.:

{ "type": "string", "anyOf": [ { "pattern": "^a\\-b$" }, { "pattern": "^b\\-c$" } ] }

Comparing this schema with itself (command jsonsubschema a.json a.json) will throw an error. More specifically, the library greenery throws an error. It seems like greenery can not handle escaped characters. When you delete one of the pattern, everything works fine, because the problematic greenery method is not called. The error is also thrown for other escaped characters like "\ " (whitespace), "\." ...

Best Regards
Michael

@andrewhabib
Copy link
Contributor

andrewhabib commented Jul 13, 2020

Mmm... I am not sure this is an inherent problem in greenery.

The problem seems related to the fact that in python string literals, backslash is used to escape special chars, including the backslash itself. In other words, one has to use '\\' to get the literal '\', if the string is not raw.

So if one wants to write the regex 'a\\-b' which matches the string literal 'a\-b' I guess, it should either be specified as raw pattern, i.e., r'a\\-b' or use the pattern 'a\\\-b' where the first backslash is the escape char, and the following double backslash for the literal backslash. Using either of those tricks, makes the check pass successfully.

In general, although greenery is quite useful and powerful, trying to use it for the full spectrum of ECMAScript regular expressions is error prone and it cannot cover all cases by nature.
However, I need to think more whether using raw strings for patterns passed to greenery will permanently solve this problem and related ones, or will it cause other unexpected behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants