Re: Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var})

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Thu, Feb 22, 2024 at 9:07 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> However, per commentary in the other thread, I'm going to recommend
> against using this patch in the first place.  We need to rethink this
> whole approach.

On Thu, Feb 22, 2024 at 9:02 AM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> Actually the string is NOT really expected to be metafied

... in fact, %l allocates space for it to be metafied during output.

> ... usually it's a plain string hardwired in the calling code

Curiously, the only existing uses of %l are for strings that came from
user input (arithmetic or a history reference) so they're almost
certainly already metafied.

So ... one possible approach is to declare that %l is the way to
produce "raw" output, and have it perform the unmetafy() + fwrite().
However, it's not clear to me that's preferred in Stephane's examples
like this one:

> > $ printf '%d\n' $'1+|a\x83 c'
> > zsh: bad math expression: operand expected at `|a^@c'

Do we really want to "see" a raw \x83 there?  No one would
intentionally use a math syntax error e.g. to produce terminal control
sequences.

> the caller actually should have the responsibility for unmetafy.

Another possibility therefore is to to have %l do raw output but NOT
unmetafy(), so the caller would need to either unmetafy() and pass a
length, or nicedup() the string when that was the desired output
(which handles the unmetafy() internally, and nul-terminates).

The final option would be to leave %l alone and add %S with a length
argument ... but I don't see that as much better than the foregoing,
given the very limited use of %l so far.

Opinions?