From: Stephane Chazelas <stephane@chazelas.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh workers <zsh-workers@zsh.org>
Subject: Re: Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var})
Date: Fri, 23 Feb 2024 19:27:17 +0000 [thread overview]
Message-ID: <20240223192717.tczrbc63fei7d4m2@chazelas.org> (raw)
In-Reply-To: <CAH+w=7YcXGPDNFaGA_onRnRmWPhrZ3ems5x_9amEaH8y2miWSA@mail.gmail.com>
2024-02-22 14:31:12 -0800, Bart Schaefer:
[...]
> Opinions?
There are two separate things here:
1. whether user-supplied text in messages should be output raw or
with the non-printable characters given some common visible
representation (like \n for newline, ^C for 0x03, \M-^C for
0x83, ^@ for NUL, ^[ for ESC, \uffff for the encoding of
U+FFFF...) by going through nicezputs().
2. Whether internally in the code the data should be passed
"metafied" or not to zerr* functions.
For 1, IMO, when the error message is generated by zsh, it
should go through nicezputs(). zsh should decide of the
formatting, have it pass escape sequences as-is would make it
hard to understand and diagnose the error.
For instance,
$ printf 'uname\r\n' | zsh
zsh: command not found: unane^M
is more useful than
zsh: command not found: uname
Where CR when sent to a terminal moves the cursor to the left
column so we don't see the problem is caused by that extra bogus
character.
The only cases where it should be passed raw is when the error
message is constructed by the user, where the user is expected
to be able to decide the formatting.
Like in:
syserror -p $'\e[1;31mERROR\e[m: '
echo ${1?$'multiline\nerror\nmessage'} ${DISPLAY:?$'\e[1;31mNo graphics'}
(syserror likely doesn't use zerrmsg anyway).
For 2, it looks like zerrmsg expects its input metafied and as
you say, that input in most cases is likely to be metafied
already. Not metafied would mean either we couldn't pass text
containing NUL, or we'd need to pass it as ptr+len.
So what makes most sense to me:
%s remains passed metafied and is output nicezputs'ed
%l same, truncated to the given number of bytes (though
truncating to a number of characters or at least not cutting
in the middle of character) would be nicer, but maybe
overkill.
%S also passed metafied, but no nicezputs.
Now, my previous message was showing there were quite a few
issue with the metafication and possibly with the nicezputs'ing
and/or multibyte handling.
> $ printf '%d\n' $'1+|a\x83 c'
> zsh: bad math expression: operand expected at `|a^@c'
Should have been:
zsh: bad math expression: operand expected at `|aM-^C c'
The text was not passed metafied to zerrmsg with 0x83 0x20 then
incorrectly unmetafied to NUL, then rendered by nicezputs as ^@.
[...]
> $ printf '%d\n' '1+|ÃÃÃÃÃÃ'
> zsh: bad math expression: operand expected at `|\M-C\M-c\M-c\M-c\M-c\M-c\M-^C...'
I picked à because it's a letter from the latin script, so you
can even use it in variable names:
$ zsh -c '(( ÃÃÃÃÃÃ ++ )); typeset -p ÃÃÃÃÃÃ'
typeset -i ÃÃÃÃÃÃ=1
But its UTF-8 encoding happens to contain the 0x83 byte used in
metafication.
$ printf %s à | od -An -vtx1
c3 83
$ printf %s à | cat -v
M-CM-^C
Again above, we see the effect of a missing metafication.
The error should have been:
zsh: bad math expression: operand expected at `|ÃÃÃÃÃÃ'
Like in:
~$ printf '%d\n' '1+|AAAAAA'
zsh: bad math expression: operand expected at `|AAAAAA'
> 0
> $ ((1+|ÃÃÃÃÃÃ))
> zsh: bad math expression: operand expected at `|ÃÃÃÃ\M-C...'
In that case, metafication OK, but character cut in the middle.
2024-02-22 16:49:20 -0800, Bart Schaefer:
> The changes for that are minimal. With them, Stephane's math-garbles
> handle the ellipsis more cleanly:
>
> % printf '%d\n' '1+|ÃÃÃÃÃÃ'
> zsh: bad math expression: operand expected at `|\M-C\M-c\...'
> 0
> % ((1+|ÃÃÃÃÃÃ))
> zsh: bad math expression: operand expected at `|Ã?Ã?Ã?...'
It seems rather worse to me.
--
Stephane
next prev parent reply other threads:[~2024-02-23 19:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 8:02 $var not expanded in ${x?$var} Stephane Chazelas
2023-01-16 8:35 ` Daniel Shahaf
2023-01-16 17:15 ` Peter Stephenson
2024-02-20 7:05 ` Stephane Chazelas
2024-02-20 17:45 ` Bart Schaefer
2024-02-20 19:39 ` Stephane Chazelas
2024-02-21 4:44 ` Bart Schaefer
2024-02-21 19:45 ` Stephane Chazelas
2024-02-21 19:52 ` Bart Schaefer
2024-02-21 20:21 ` Stephane Chazelas
2024-02-22 0:46 ` [PATCH] unmetafy " Bart Schaefer
2024-02-22 7:23 ` Stephane Chazelas
2024-02-22 7:55 ` Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var}) Stephane Chazelas
2024-02-22 17:02 ` Bart Schaefer
2024-02-22 22:31 ` Bart Schaefer
2024-02-23 0:49 ` Bart Schaefer
2024-02-23 19:27 ` Stephane Chazelas [this message]
2024-02-23 22:32 ` Bart Schaefer
2024-02-23 23:38 ` Bart Schaefer
2024-02-24 9:47 ` Stephane Chazelas
2024-02-24 10:36 ` Stephane Chazelas
2024-02-25 4:35 ` [PATCH] 'bad interpreter' error garbled Bart Schaefer
2024-02-25 5:26 ` Bart Schaefer
2024-02-25 2:17 ` Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var}) Bart Schaefer
2024-02-25 6:05 ` Bart Schaefer
2024-02-25 7:29 ` Stephane Chazelas
2024-02-25 8:28 ` typeset -<non-ASCII> (Was: metafication in error messages) Stephane Chazelas
2024-02-25 8:35 ` Stephane Chazelas
2024-02-25 21:02 ` Bart Schaefer
2024-02-23 0:33 ` Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var}) Bart Schaefer
2024-02-25 5:06 ` [PATCH] count multibyte and metafied characters correctly for math ops errors Bart Schaefer
2024-02-22 8:34 ` [PATCH] unmetafy Re: $var not expanded in ${x?$var} Roman Perepelitsa
2024-02-22 17:07 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240223192717.tczrbc63fei7d4m2@chazelas.org \
--to=stephane@chazelas.org \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).