Revision history [back]

It's documented that you can use regular expressions in the key value field in IDF (https://bigladdersoftware.com/epx/docs/9-5/input-output-reference/input-for-output.html#outputvariable). This was also mentioned in another question: https://unmethours.com/question/12800/regular-expressions-to-filter-outputvariable/?answer=32792#post-id-32792

But is it possible to disable the use of regex parsing? I'm generating IDF files from other data and if that data happens to contain strings with characters used as regex operators it can end up causing errors. Since in this circumstance I know that they are not intended to be treated as regex strings it would be simplest if I could just instruct EnergyPlus to assume they are plain strings. Doing this either globally in the IDF would be ideal, or even field-by-field could work.

The reference above doesn't mention anything about this in the section I linked to or anywhere else I can find. It does link to https://github.com/google/re2/wiki/Syntax for the regex syntax being used, but I also don't see anything there which would entirely disable treating the string as a regex.

I know I can escape or replace the individual special characters but that has the disadvantage of reducing the readability of the iDF + the overhead of having to do it.

Thanks!

It's documented that you can use regular expressions in the key value field in IDF (https://bigladdersoftware.com/epx/docs/9-5/input-output-reference/input-for-output.html#outputvariable). This was also mentioned in another question: https://unmethours.com/question/12800/regular-expressions-to-filter-outputvariable/?answer=32792#post-id-32792

But is it possible to disable the use of regex parsing? I'm generating IDF files from other data and if that data happens to contain strings with characters used as regex operators it can end up causing errors. Since in this circumstance I know that they are not intended to be treated as regex strings it would be simplest if I could just instruct EnergyPlus to assume they are plain strings. Doing this either globally in the IDF would be ideal, or even field-by-field could work.

The reference above doesn't mention anything about this in the section I linked to or anywhere else I can find. It does link to https://github.com/google/re2/wiki/Syntax for the regex syntax being used, but I also don't see anything there which would entirely disable treating the string as a regex.

I know I can escape or replace the individual special characters but that has the disadvantage of reducing the readability of the iDF + the overhead of having to do it.

Thanks!

It's documented that you can use regular expressions in the key value field in IDF (https://bigladdersoftware.com/epx/docs/9-5/input-output-reference/input-for-output.html#outputvariable). This was also mentioned in another question: https://unmethours.com/question/12800/regular-expressions-to-filter-outputvariable/?answer=32792#post-id-32792

But is it possible to disable the use of regex parsing? I'm generating IDF files from other data and if that data happens to contain strings with characters used as regex operators it can end up causing errors. Since in this circumstance I know that they are not intended to be treated as regex strings it would be simplest if I could just instruct EnergyPlus to assume they are plain strings. Doing this either globally in the IDF would be ideal, or even field-by-field could work.

The reference above doesn't mention anything about this in the section I linked to or anywhere else I can find. It does link to https://github.com/google/re2/wiki/Syntax for the regex syntax being used, but I also don't see anything there which would entirely disable treating the string as a regex.

I know I can escape or replace the individual special characters but that has the disadvantage of reducing the readability of the iDF + the overhead of having to do it.

I tried using the comment syntax (?#text), but the re2 documentation states this is not supported and that seems to be the case - it did not work.

Thanks!