From: Phillip Wood <phillip.wood123@gmail.com>
Date: Tue, 17 Feb 2026 15:11:24 GMT
Subject: Re: [PATCH v4] meson: regenerate config-list.h when Documentation changes
Message-ID: <cfea5749-af95-4a46-8a3d-9022d28edb2c@gmail.com>
In-Reply-To: <CALnO6CBqbJ3s6XO0s_bTagJxT0N8nseyJb1T-H7+B6qqWNKoUg@mail.gmail.com>

On 17/02/2026 13:38, D. Ben Knoble wrote:
> On Tue, Feb 17, 2026 at 4:20 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>> On 16/02/2026 22:28, D. Ben Knoble wrote:
>>> +if test -n "$DEPFILE"
>>> +then
>>> +     for doc in "$SOURCE_DIR"/Documentation/*config.adoc \
>>> +             "$SOURCE_DIR"/Documentation/config/*.adoc
>>> +     do
>>> +             printf "$OUTPUT: %s\n" "$(printf '%s\n' "$doc" | sed 's/[# ]/\\&/g')"\\
>>
>> This forks two processes for every file which is a bit inefficient and
>> will be especially slow on windows.
> 
> Yeah. I couldn't find a way I trusted to behave in the presence of
> strange characters, though…
> 
>> If we quote $OUTPUT first we should
>> be able to use a single sed process for all the files
>>
>>          QUOTED_OUTPUT="$(printf '%s\n' "$OUTPUT"| sed 's|[/\]|\\&|g')"
>>          printf '%s\n' "$SOURCE_DIR"/Documentation/*config.adoc \
>>                  "$SOURCE_DIR"/Documentation/config/*.adoc |
>>          sed -e 's/[# ]/\\&/g' -e "s/^/$QUOTED_OUTPUT: /" >"$DEPFILE"
> 
> …and this version matches a concept I considered. Let me think aloud.
> 
> To quote output, we backslash-escape any "/" and "\"; we are going to
> use it in the replacement side of sed's substitute command with "/"
> delimiters.
> 
> My manual says "&" and "\[0-9]" are also special in the replacement
> string.

Oh, I should have remembered '&' needed escaping as well

  We have no backreferences for the latter, but my sed on macOS
> complains about bad backreferences in cases like
> 
>      echo abc | sed 's/^/foo\1/'
> 
> OTOH, escaping backslashes already covers such backreferences. So I
> think we'd need something closer to
> 
>      sed 's,[&/\],\\&,g'
> 
> ? If you agree with that reasoning, I'll include this in the next
> version. (I'll also try this out a bit first.)

That looks good to me

> PS in patterns with so many "vertical" characters, I find the commas a
> bit easier to read than pipes :)

Yes, that does make it clearer

Thanks

Phillip