Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.awk
Subject: Re: Experiences with match() subexpressions?
Date: Thu, 10 Apr 2025 23:39:57 +0200
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <vt9dre$3t3po$1@dont-email.me>
References: <vt7qlq$2ge70$1@dont-email.me> <vt7qs4$2gior$1@dont-email.me>
 <vt88s7$1ghd2$1@news.xmission.com> <vt8bit$2uiq5$1@dont-email.me>
 <vt8j5u$1gmdg$1@news.xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 10 Apr 2025 23:39:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="191bb9520fd9588bd0fbefeff3187da6";
	logging-data="4099896"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188nS225UeGtRjerSxjE1a/"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:0OKVMSucsUk95h9dbvpuYbnx0HA=
In-Reply-To: <vt8j5u$1gmdg$1@news.xmission.com>
X-Enigmail-Draft-Status: N1110
Bytes: 3968

On 10.04.2025 16:04, Kenny McCormack wrote:
> In article <vt8bit$2uiq5$1@dont-email.me>,
> Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>>> I have to admit that I (still) don't really understand how this match third
>>> arg stuff works. 
> ...
>>> I.e., I can never predict what will happen, so I always
>>> just dump out the array and try to reverse-engineer it each time I need to
>>> use it.
> ...
>> Above output stuff appears because in 'arr' there's additional elements
>> about the pattern positions stored.
> 
> Just to clarify, I wasn't looking for a tutorial (man page regurgitation).
> I understand the man page description of match's 3rd arg as well as anyone;

(I didn't mean to offend you. Sorry, if it appeared so. - I just
read you writing "I don't really understand how this [...] works",
and that "it is unpredictable", so I thought some descriptive words
may be useful.)

> I just find it that it doesn't do as much in practice as (I think) it
> should - and that it is unpredictable (by me, anyway) what it will do (you
> have to dump out the array and trial-and-error it to get it to do what you
> want). 

It is pretty understandable to me, and not the least unpredictable.
(That's why I thought it would be okay to write what I had written
to explain it.) I don't understand what you find to be unpredictable.
But never mind.

> It promises more than it delivers. 

Yes, probably. Although, according to what's literally documented,
it doesn't promise too much, IMO. The feature can be very useful,
but not for the case I was looking for. - Actually, it could have
provided the functionality I was seeking, but since GNU Awk relies
on the GNU regexp functions as they are implemented I cannot expect
that any provided features gets extended by Awk. - If GNU Awk would
have an own RE implementation then we could think about using, e.g.,
another array dimension to store the (now only temporary existing,
and generally unavailable) subexpressions.

> [...]
> 
> None of which is criticism of the feature; as you say below, it basically
> does as much as the underlying regexp library allows it to do.
> 
> ...
>> I think I'll do the parsing the straightforward two-step way as I did
>> before the GNU Awk specific functions were available; it's probably
>> also the clearest way to program that functionality.
> 
> Probably so.  BTW, it is not really "GNU Awk specific"; lots of languages
> have this general capability.

Oh, I was just trying to say that for my programming the standard Awk
functions (as opposed to GNU Awk _specific_ functions) are fine here.
(That should not disdain all the useful GNU Awk extensions existing.)

Janis

> [...]