When bin/pyang is called on a file path which includes directories and those directories contain the @ character, the re_filename regexp cannot deal with it. In particular, the "revision-date" grouping is detected as being the text between the first @ in the path and the (.yang|.yin) suffix(es).
E.g.
$ pyang project@2022-04-07/project@2022-04-07.yang
project@2022-04-07/project@2022-04-07.yang:1: error: filename "project@2022-04-07/project@2022-04-07.yang" suggests invalid revision "2022-04-07/project@2022-04-07", should match "YYYY-MM-DD"
The regexp doesn't account for the fact that a file path may include directories that have nothing to do with the YANG file's name, therefore screws the parsing.
The only other place (I found) where re_filename is used is unaffected by this issue because the regexp is being executed on the output of os.listdir() which lists only files.
Since neither / nor \ are valid characters in a module name (per the YANG RFC(s)) dealing with the edge case of having either of those chars in the filename itself isn't needed.
When
bin/pyang
is called on a file path which includes directories and those directories contain the@
character, there_filename
regexp cannot deal with it. In particular, the "revision-date" grouping is detected as being the text between the first@
in the path and the (.yang|.yin) suffix(es).E.g.
The regexp doesn't account for the fact that a file path may include directories that have nothing to do with the YANG file's name, therefore screws the parsing.
The only other place (I found) where
re_filename
is used is unaffected by this issue because the regexp is being executed on the output ofos.listdir()
which lists only files.Since neither
/
nor\
are valid characters in a module name (per the YANG RFC(s)) dealing with the edge case of having either of those chars in the filename itself isn't needed.