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.
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".
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:
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
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.
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?