I thought that was what you meant, and I wonder why it doesn't display anything for me. I was running Ice and thought that was the reason, but your macro also doesn't display anything if I quit Ice.
I checked the KM log and this is what I get when I your macro runs:
Execute macro “Clipboard Analyzer v2” from trigger System Clipboard Changed
Action 16002068 failed: Task failed with status 1
You diagnosed the problem to some degree. Your copy of my macro is failing before it reaches the first statement in the macro.
A similar problem occurred in this thread. You may want to read it.
However if you want to run my macro with a hotkey trigger, or a periodic trigger, or just pressing the Run button in the KM Editor, you should at least see my macro running then. You can still run my macro using some other means.
You can find the "problem" action by using the KM Editor's "Search" box and the action: qualifier -- so, in this case:
action:16002068
You are probably right. So I withdraw my suggestion. When he responds, we may give more advice.
As always, I learn something from you every day.
This is amazing, I didn't know!
Not entirely unsurprising, the error occurs here:
Did the Clipboard Analyzer macro work for you, @_jims or for you, @Nige_S ? Knowing this will help diagnose if the problem is with his environment, or with the macro.
I haven't tried it. But going solely by the image and error posted...
egrep returns a 1 result code when there is no match found, even while the -c option is returning the value 0. KM treats a shell script action's final result code of anything but 0 as an error.
My guess is that you need to turn off "Failure Aborts Action" and "Notify on Failure" in the action's options if setting LocalTally to 0 is a valid outcome.
The egrep command is in a Try/Fail action, and if it fails, it goes to the Fail clause and returns a value of 0. That's how I fully account for that situation. And it works fine for me.
Well, if nothing else comes of this you've now a way of handling similar cases without the "Try/Catch" action 
I'm stumped, then. If the action is erroring inside a "Try/Catch", there can't be a report in the log. If there's a report in the log the action can't be in a "Try/Catch".
We seem to be in a Try-Catch-22 situation...
After reading and studying your comments, I may possibly have found the problem. The error message in the log file that he sees is not a message that reflects the stoppage of the macro. In a TRY block, errors go into the log file even though the macro continues to work. Technically, you were wrong when you said "If the action is erroring inside a "Try/Catch", there can't be a report in the log." Indeed, errors will show up in the log file when inside a TRY block and the macro still continues normally.
So I'm staring at this macro, wondering why it works for me and not for him. I have a theory. You see, the group that the macro is in contains critical attributes that are required for this macro to work. My theory is that he moved my macro out of the group it was in and placed it in another macro group without telling us. If he did that, then he would get precisely the results that he is now getting. It's just a theory, but it would explain perfectly his results. Let's see what he says about this theory. The group must contain these attributes. Even if he didn't move the macro, he should validate that his group contains the following:
Hi, @Airy. I did a quick check and it seems to work for me:
Might it be that the Clipboard macro group was not enabled?
Not just technically wrong -- totally wrong! I must have set up something weirdly in the quick test I did. But it did let me crowbar in a "Catch 22" reference, so I hope that makes up for it
Ah -- so the macro is running, the error reported is an artefact of expected behaviour, it's just that the "display settings" aren't right at the Group level? Sounds promising.
Which does make me wonder if this is the right way to handle single grep (and variants) commands. grep is unusual in its use of result codes -- perhaps we need to handle it differently so that KM doesn't see an error when there was none. Something as simple as
theResult=$(egrep -c "^($KMVAR_LocalWords)$")
echo $theResult
...should do it. If nothing else it will cut down out some unwanted lines in the error log!
He said he was getting an error in the log so your theory doesn't sound possible to me.
Sounds great. I will take that approach going forward. But it's not this user's problem, so we have to wait for him to reply to my theory.
Okay, sorry, I missed that. 
Now that I've gone back and done a little more testing, I concur with @Nige_S's assessment. Moreover, it appears that there are cases when LocalWords is not set in the preceding Search using Regular Expression.
I don't want to pollute this thread, but by PM I'll send you a version of the macro that includes an inserted group that might help you diagnose the issue.
@Airy, looks like I can't send you a PM. Please let me know if you'd like me to upload (here) the revised version of your macro.
Yes, I don't read personal messages, so I turned that feature off. I'm not sure why I would object to a revised macro. Feel free to do whatever you want. Do you want to take ownership of this macro? I wouldn't mind. I'm pretty easy going when it comes to anything I upload.
Yes, Nige's theory about LocalWords being empty is a theory, but he admitted his theory was "totally wrong." The fact that it can be empty is something I already accounted for in my macro, by placing it into a TRY block. As you showed in your screenshot, the macro works for you, so that can't be Stefan's problem then, right?
No, @Airy, that wasn't my intention. I just added a group action that displays the accessed variables. I was thinking that it might help you debug. I use this group often.
For what it's worth, here you go...
Download: Clipboard Analyzer v2 - @_jims 2024-07-02.kmmacros (589 KB)
Okay, but there's nothing wrong with my macro, so there's nothing to debug yet. The original poster still hasn't replied to my questions.
