Re: bmake's :[range] modifier (was: Cryptic idiom)

["Simon J. Gerraty" <sjg%crufty.net@localhost>]

On Fri, 19 Dec 2025 23:26:52 +0100, Roland Illig writes:
>Am 19.12.2025 um 11:00 schrieb Fr=C3=A9d=C3=A9ric Fauberteau:
>>>> It selects the first word in TOOLS_PLATFORM.${_t_} in the case that it=
>=20
>>>> is
>>>> a sequence of words.
>>> Was that from before bmake learned :[1]?
>
>No, interestingly not. The code in mk/tools/replace.mk is from July
>2005, and the :[...] modifier was added in September 2003 (see "blame"
>from the netbsd-9 branch), which is almost 2 years earlier. But I guess
>at that time, the code in replace.mk was supposed to be
>backwards-compatible with earlier versions of NetBSD.

That is why I find MAKE_VERSION useful (though I wish I'd used
.MAKE.VERSION) lots of features allow an optimized solution and a less
ideal solution for older versions see bmake's mk/sys.vars.mk

>
>> What makes me want to write:
>>=20
>> ```
>> TOOLS_CREATE+=3D    ${_t_}
>> TOOLS_PATH.${_t_}?=3D \
>>    ${TOOLS_PLATFORM.${_t_}:[1]}
>
>That's fine, and when you run pkglint on mk/tools/replace.mk, it
>suggests exactly this replacement.
>
>> TOOLS_ARGS.${_t_}?=3D \
>>    ${TOOLS_PLATFORM.${_t_}:[2..-1]}
>
>Pkglint doesn't suggest anything for this case, and even if it did, it
>might have been fallen for the same trap.
>
>> But it seems to work as expected only if there are several words in=20
>> TOOLS_PLATFORM.${_t_}. In case where TOOLS_PLATFORM.bash would contain=
>=20
>> /bin/bash, both TOOLS_PATH.bash and TOOLS_ARGS.bash are /bin/bash while=
>=20
>> TOOLS_ARGS.bash should be empty.
>>=20
>> To me, it looks like a bug. But I wonder if this isn't the expected=20
>> behavior according to bmake(1):
>>=20
>>> If start is greater than end, the words are output in reverse order.
>
>The sentence before that is even more interesting, it says:
>> For example, `:[2..-1]' selects all words from the second word to the la=
>st word.
>
>This contradicts the single-word case. Interestingly,
>usr.bin/make/unit-tests/varmod-select-words.mk does not test for an
>empty list or a single-element list.

The single word case is tricky.  ${one:L:[2..-1]} should produce an empty 
but it does not (result is "one") by contrast ${one two:L:[2..-1]}
produces "two" as expected.  

>
>Fixing this bug sounds good, but it has its tricky edge cases, as this
>modifier performs both select-words and reverse-list, using a single
>syntax. In my view, the modifier ":[2..-1]" does not intend to reverse

It matches 2nd element to end of list, and as you note ":[2..]"
would perhaps be more obvious.

>the list in some of the cases but not in others. It may be clearer to
>say ":[2..]" instead, like in Python or Go. I'll think about the details
>in the next few days.
>
>Roland