Multi-line regex replace issue

[Chris McKulka]

I am creating my first workflow that has a regular expression that operates against a string with multiple lines. To be clear when I say multiple lines I mean there are embedded '\n' characters.

 

The replacement doesn't seem to working correctly. See attached picture with debug output. Instead of emitting a '\n' just the letter 'n' (vs. a newline) is being emitted.

 

I attached the full script that I am trying to replicate but that's just for context. The screenshot captures the issue with a very simple set of input text and a trivial regex.

 

Appreciate your help!

[Chris McKulka]

Version is Alfred v3.6 [903]. Issue is fully reproducible.

[deanishe]

2 hours ago, Chris McKulka said:

Issue is fully reproducible

 

Not sure this isn't the expected behaviour, tbh.

 

As a workaround, you can use a capture group to keep the newline from the input:

 

[Chris McKulka]

Thank you for the quick and thoughtful response. Thank you for the suggestion re. using a capture group. You are correct it does work and maybe my workaround, but it definitely isn't elegant.

 

As far I can Alfred's behavior is incorrect. The perl command below returns the correct result. See pic below.

 perl -pe 's/[0-9]\n/*\n/g'

Chris

[Andrew]

Sorry about the slow reply on this. I've now had a chance to look into what is happening.

 

Alfred is using NSRegularExpression which treats \ in the replacement template string as a literal, and it looks like it's just being stripped in the replacement.

 

See Table 3 here:

https://developer.apple.com/documentation/foundation/nsregularexpression?language=objc

 

If you were to actually put a new line in the replacement (i.e. instead of using \n, use alt+return), then it works as expected.

 

Cheers,

Andrew

[Felciano]

I just got bitten by this. I think it would be helpful to note in the (excellent) documentation, especially as this page sends you to RegExr which treats \ as an escape character in the replace string, vs the NSRegularExpression behavior. This stumped me for a while because I was able to get everything working correctly on RegExr, so a footnote or similar on the docs page would have prevented this. The workaround works well, as does the capture method listed above.

 

Thanks,

 

Ramon