I just want to point out RTFM answers are unhelpful.
Sometimes the manual is unclear or not understandable by the poster in which case a explanation followed by a suggestion to look at the manual would be more approate.

There is also a list of built-in variable. And together they make a lot of sense.

Now prove here that neither of the built-in functions and neither of the built-in variables can serve your purpose. I.e. show here that you have read, comprehended and analyzed the text and that the text has no relationship to what you are trying to achieve.

Of course, for your purpose you do not need all the built-in functions and all the built-in variables, but but you do need some of them.

So, show your process of analysis and selection/discarding. I.e. write here "I think that function/variable FOO is not good for my purpose because ...". Or the opposite.

And you were given the exact clue: first describe how you would do it with your eyes and fingers. That's the very basic approach for a whole lot of typical tasks in programming.

If/when you describe how you would it with your eyes and fingers, the equivalent functions and variables doing the job are much easier to find.

No, first and foremost you didn't even think there is more than one way to do it. It is possible to do with and without regular expressions. Both 'awk' and Perl allow to do it with and without regular expressions.

One of the very first things I learned in this life was that doing something without the ability to debug it is doing it for grief, not for fun.

In my case it wasn't even in programming, it was in electronics. Imagine a long (2 .. 3m), but very thin (50 mm => 2 inches) in diameter apparatus in special "oven" where it's heated to 125C or higher.

It had to be - the apparatus was for oil well logging, the temperatures are high in oil wells.

So, the apparatus fails with temperature, and I don't know why. And when temperature goes back down, it functions again normally.

To debug it I needed to guess which signals to make accessible, but doing so meant soldering to the nodes long wires (the same 2 .. 3m), and circuits in general do not like long wires.

...

So, don't even think of doing anything unless you have a clear plan of debugging. Starting PHP on a WEB server without even thinking where the error messages go (and they go to the server log) is a complete and utter nonsense.

Actually, the very first question you have to ask yourself is not "how am I going to do it ?", but rather "how am I going to debug it".

Much later in my life I took part in design of a pretty well known chip. Chip signals can often be observed using a tool similar to oscilloscope. So, there was a problem with the chip - its die was attached to the plastic by the signal side. The company had a $$$$$$$ tool to drill the silicon at precise coordinates to precise depth in order to just be able to observe the signals. And the company thought about it before the chip came into physical existence, while the chip was being developed.

At all, writing code assuming no mistakes will be made is complete and utter nonsense. There is a whole bunch of posts in this forum from people who have problems which are easily seen through compiler warnings which are disabled. So the people scratch their heads at runtime instead of seeing the problems at compile time.

...

So, whenever you have problems of your very special kind, it's because you prefer doing things your special way.

I perfectly well understand the concept of not understanding. In fact, when I read new for me documentation I often do not understand too.

But I have learned to slow down in such cases and to clearly formulate what I do not understand. I.e. I'm asking myself: "What is the very first thing I do not understand ?". It really helps - then I focus on that thing and typically find an answer.

Sometimes using this approach I actually prove that the document I'm reading is wrong - the item in question is defined after it's used or in a separate document. I saw a number of such problems in PCI Express documentation, for example.

And, as I wrote many times, I am doing analysis. I.e. typically the text contains enough details to make a decision to either further study it or to discard it as irrelevant for the answer I'm trying to find.

So, MTK358, I most often here see that you don't even start performing the needed analysis.

Sergei (and everyone);

Please--no more on this. We frown on closing threads but, in this case, let's put this behind this and make a fresh start.