Regex Question: Why is terminating | required?

[_jims]

UPDATE: This issue has been resolved. See this post for more information.

---

I have the following test string:

.This sentence has two colons (::) and three slashes (///).

I want to replace the following characters with a dash ( - ):

• A leading space whitespace character,

• a leading dot ( . ),

• all colons ( : ), and

• all slashes ( / ).

With the Search and Replace action, why would a regex pattern of ^[\s.]|:|/| work, whereas the same pattern without the terminating | does not (the slashes are not replaced)?

Here's a test macro.

Download: __Test Regex.kmmacros (4.6 KB)

Macro-Image

---

Macro-Notes

• Macros are always disabled when imported into the Keyboard Maestro Editor.
  • The user must ensure the macro is enabled.
  • The user must also ensure the macro's parent macro-group is enabled.

---

System Information

• macOS 15.3 (24D5055b) PRE-RELEASE SEED SOFTWARE
• Keyboard Maestro v11.0.3

---

[unlocked2412]

@_jims

^[\s.]|:|/|

Is there any reason why you are not escaping the forward slash (/) in your regex expression ?

[_jims]

Hi, @unlocked2412. Thanks for your question.

@unlocked2412

Is there any reason why you are not escaping the forward slash (/)

In this context, I don't think escaping is required. Regardless, I did try it, and there was no change in behavior.

[kevinb]

It doesn't seem to be required within KM, no...

The final | means a zero-length match for the final alternative. How that relates here is not clear to me though.

[_jims]

Hi, @kevinb. Thanks for the comment.

@kevinb

How that relates here is not clear to me though.

Same here. I discovered it by trial and error.

[Airy]

I spent a while trying to understand this. I don't have an answer yet, but I see a small oddity. The "\s" regex string does not just represent a space. It represents a large set of characters, including a space. That may not be a problem for you, but I wanted to mention it.

Apart from that, I have another oddity. When you insert the regex manually instead of using a variable, the result seems to be different and correct:

So I'm leading in the direction that there's a bug when using the %Variable% token inside this action. Cue the defenders of KM who don't like it when someone suggests a bug.

[_jims]

@Airy

I spent a while trying to understand this.

Thanks, @Airy!

@Airy

The "\s" regex string does not just represent a space. It represents a large set of characters, including a space.

I misstated. I should have said any whitespace. Sorry. I've corrected the OP.

@Airy

Apart from that, I have another oddity. When you insert the regex manually instead of using a variable, the result seems to be different and correct:

That's odd; not for me. In both cases I need to include the terminating |.

---

Interestingly, if I use the following pattern, no terminating pipe is needed: ^[\s.]|[:/]

[_jims]

UPDATE:

@unlocked2412, @kevinb, and @Airy:

I appreciate your efforts, and I owe you an apology for wasting your time!

Since @Airy and I had different observations, I suspected there must be something unforeseen at work. So I copied the XML for the Search and Replace action and pasted it into BBEdit.

Look what I found! There is a newline after the %Variable%local_Pattern% and before the </string>.

With the newline removed the action is working as expected.

		<dict>
			<key>Action</key>
			<string>CaseSensitiveRegEx</string>
			<key>ActionUID</key>
			<integer>16720755</integer>
			<key>Destination</key>
			<string>Variable</string>
			<key>DestinationVariable</key>
			<string>local_Text</string>
			<key>MacroActionType</key>
			<string>SearchReplace</string>
			<key>Replace</key>
			<string>-</string>
			<key>Search</key>
			<string>%Variable%local_Pattern%
</string>
			<key>Source</key>
			<string>Text</string>
			<key>Text</key>
			<string>.This sentence has two colons (::) and three slashes (///).</string>
			<key>Which</key>
			<string>All</string>
		</dict>

Again, thanks for your help! This forum includes so many incredibly helpful users!

[Airy]

@_jims

Since @Airy and I had different observations, I suspected there must be something unforeseen at work.

In my computer science career, it took me several decades to realize that unexpected behaviour isn't really a problem, it's an opportunity for understanding (and exploiting.)

@_jims

I misstated. I should have said any whitespace.

Well if you want "any whitespace" rather than "a single whitespace character", then I think you should change "\s" to "\s+".

[Airy]

@_jims

Look what I found! There is a newline after the %Variable%local_Pattern% and before the </string>.

With the newline removed the action is working as expected.

Would you conclude from seeing that, that my claim of it being a bug was correct?

[_jims]

@Airy

Would you conclude from seeing that, that my claim of it being a bug was correct?

No, more like "operator error"! I'm not sure how I entered the newline, but I'm sure I did!

[griffman]

@Airy

Would you conclude from seeing that, that my claim of it being a bug was correct?

It's not a bug, it's a (lack of) a feature:

Feature request: Auto-expand all input fields

This came up in this thread about a regex issue, which wasn't really a regex issue at all, but an input error: The user wanted a regex of \[.*$, but somehow entered that four times, once per line, in the regex field. But in the Keyboard Maestro editor, there's no way to tell that there's a problem: [image] It looks fine. The only way we figured out there was an issue was by having the user upload the macro. I installed the macro, selected all the text (Cmd-A) in the input box, copied it, the…

And it comes up a lot in any fields that don't auto-expand but can (purposefully or accidentally) contain a line break.

I really hope Peter can at least give us an indicator that there's a line break in non-expanding fields.

-rob.

[_jims]

@griffman

I really hope Peter can at least give us an indicator that there's a line break in non-expanding fields.

That would be helpful as it's certainly not obvious when modifying the value in the field.

---

I suspect that it wouldn't be easy to change the focus color (currently blue on my mac), but maybe the text color could be set to red like we see in the Set Variable to Calculation action when something is amiss.

[_jims]

@Airy

Well if you want "any whitespace" rather than "a single whitespace character", then I think you should change "\s" to "\s+".

Wow, I need to go to bed. I should have said: Any single whitespace character.

I knew to use \s, but I did a very poor job describing my objective.

I know better; but I'm tired!

[Airy]

@_jims

No, more like "operator error"! I'm not sure how I entered the newline, but I'm sure I did!

Oh, I get it now. You had somehow entered the CR yourself. I thought you were implying that the KM Editor did that for you.

[kevinb]

@_jims

@unlocked2412, @kevinb, and @Airy:

I appreciate your efforts, and I owe you an apology for wasting your time!

I might have saved you a little time if I had trusted my intuition that the problem had something to do with end-of-line, but I really couldn't see how it could be, and my experiments with $ did not enlighten me, so I didn't mention that line of thought! Well done on having worked this one out!

[peternlewis]

@griffman

I really hope Peter can at least give us an indicator that there's a line break in non-expanding fields.

This is a Mac issue, not a Keyboard Maestro issue.

The field stops you from typing a return, but it does not stop you from pasting a return, nor does it show you that the return is in the field when the field is displayed unedited.

I expect I can add a flag when editing it to show the return is in there, but that would not show when you are not editing the field.