From: Stephane Chazelas <stephane@chazelas.org>
To: Bart Schaefer <schaefer@brasslantern.com>,
zsh workers <zsh-workers@zsh.org>
Subject: typeset -<non-ASCII> (Was: metafication in error messages)
Date: Sun, 25 Feb 2024 08:28:59 +0000 [thread overview]
Message-ID: <20240225082859.t4ersac6tyn3gn6j@chazelas.org> (raw)
In-Reply-To: <20240225072951.sxzdzoydvgqxctdj@chazelas.org>
By the way, while looking at other culprits for missing
metafication in calls to zerr*, I found (in UTF-8 locale):
$ typeset -é
typeset: bad option: -^
~$ zsh -c 'typeset -é' |& sed -n l
zsh:typeset:1: bad option: -^\003$
(gdb)
305 while (*fmt)
(gdb)
306 if (*fmt == '%') {
(gdb)
307 fmt++;
(gdb)
308 switch (*fmt++) {
(gdb)
348 num = va_arg(ap, int);
(gdb)
350 mb_charinit();
(gdb) p num
$2 = -61
(gdb) p (unsigned char) num
$3 = 195 '\303'
(that's 0xc3, the first byte of é, normally rendered as \M-C).
We end up with a ^ because in wcs_nicechar_sel():
wcs_nicechar_sel (c=-61 L'\xffffffc3', widthp=0x0, swidep=0x0, quotable=0) at utils.c:602
602 int ret = 0;
(gdb) n
603 VARARR(char, mbstr, MB_CUR_MAX);
(gdb)
612 newalloc = NICECHAR_MAX;
(gdb)
613 if (bufalloc != newalloc)
(gdb)
619 s = buf;
(gdb)
620 if (!WC_ISPRINT(c) && (c < 0x80 || !isset(PRINTEIGHTBIT))) {
(gdb)
621 if (c == 0x7f) {
(gdb)
629 } else if (c == L'\n') {
(gdb)
632 } else if (c == L'\t') {
(gdb)
635 } else if (c < 0x20) {
(gdb)
636 if (quotable) {
(gdb)
641 *s++ = '^';
It's < 0x20 because negative and we end up with ^<0x3> because
that's -61 + 64.
zerrmsg's %c expects a wchar_t when MULTIBYTE_SUPPORT is
enabled, but here we're passing it the first byte (signed) of
the encoding of the wide character.
Calling it with (unsigned char)*arg is not much better as you
end up with: zsh:typeset:1: bad option: -Ã
As U+00C3 (Ã) happens to be printable. If it weren't -\M-C would
not be much better anyway. And you also get zsh:typeset:1: bad
option: -Ã for typeset -$'\xc3'
Some options could be:
- return a "no non-ASCII/multibyte option supported" error
message when *arg >= 0x80
- extract and decode the full multibyte character before passing
to zerrmsg. which leaves the problem of how to render byte
sequences that can't be decoded.
Maybe there are already functions in the code that do that?
--
Stephane
next prev parent reply other threads:[~2024-02-25 8:29 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
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 ` Stephane Chazelas [this message]
2024-02-25 8:35 ` typeset -<non-ASCII> (Was: metafication in error messages) 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=20240225082859.t4ersac6tyn3gn6j@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).