I have local variable which is created by previous step, with many lines but last is not terminated by new line character.
When I use For Each Item in collection, the last line is not processed. Is it standard behaviour or maybe the length of last line should be checked and line included in processing?
(Nevermind, I was wrong!)
-rob.
I have never had that problem. For example, the variable LocalZ in this code does not contain a new line, and it still reads all three numbers aloud:
Can you please upload a macro that demonstrates the problem? I'm not able to replicate your issue no matter what I try. In my example above, there is no hidden newline after the character "3".
I suspect something else is going on. Whether the last line ends in a new line character or not it should be included in the Lines In collection. If the input text ends in a new line character, then the last line would be the one before that.
For example, this case (which does not have a line ending character after the “3”)
Logs three lines.
2025-07-17 15:38:00 Log: 1
2025-07-17 15:38:00 Log: 2
2025-07-17 15:38:00 Log: 3
Show is always better than tell,
and hard to spot the misunderstanding without seeing the macro.
( or the briefest example that reproduces whatever is puzzling you )
I even tried experimenting with CRs instead of LFs, but I couldn't replicate the issue.
I recall finding one macOS command (the name of which escapes me) which processes text but whose output does NOT include a newline after the last line of output. Maybe he found that command. When that happened to me, I think that I piped the output into "grep ." which ensured that there is a newline after the last line of text. But he didn't say how he generated his data.
Sorry for this mess - of course KM works correctly.
The problem was in different place - the regular expression which was the last part of loop (before display action) had space (invisible for me) and this step was invalid for last entry in list of lines, what finally looked like not processing the last line.
Maybe this case is occasion to improve KM? I don't know is it possible in programming of UI of MacOS, but if the regex in dialog could have different (grey?) background in place where spaces are includes, it could help to recognise such cases?
I'm glad you diagnosed the problem. If you show your code, I may be able to give advice.
While highlighting spaces with a different background (like grey) in the regex dialog could help spot certain characters, there are still many others that are either invisible or nearly impossible to distinguish visually. That’s why I rely heavily on external regex tools (such as regex101.com ) for thorough debugging.
I've put the macro in Macro Library. If you find to correct ar make better, I will be happy to learn.
I'm afraid I'm not going to install brew and some brew package to help you diagnose a small issue with a For Each loop.
If you are having a problem with a For Each action not executing the last line, you should isolate the issue by writing a new macro with the smallest possible amount of code that produces the same failure and share that small piece of code. Get rid of all the stuff that's irrelevant to your problem, which is most of your macro.
Sorry about sounding negative.
Thanks
I think that problem is solved. The macro works, that is why I’ve put it in Macro Library.
I’ve know this technique of isolation, it works in many other environments. I’ve put the question on forum because it looked like not working for the last line. Because problem with treatment of last line without new line character exists in other situations, I thought that it is exactly that case.
Once more thank you for your readiness to help.
Many text editors (I use BBEdit) have the option to show spaces and other "invisible" characters, and regex101.com not only shows them but includes them in the "Explanation". A quick copy and paste will give you a useful sanity check.
Perhaps worth noting that the (?m) in your
(?m)(. )(\d{2})( .*)
...is unnecessary, since your pattern contains neither start (^) nor end ($) anchors. The pattern still matches one line at a time because, by default, . does not include any of the line-break characters.
Yes thanks
I have above 28 years Unix experience and that ICU regex are sometimes hard to use for me 
(sed, awk and vi regex, mostly works in line mode and that is how my brain works also). The concept of multiline changes depends of product/solution. The regex syntax from ICU (and Perl) seems to me sometimes overloaded.