Re: Unicode allowables in Environment variables

X-seq: zsh-workers 53196

From: "Mark J. Reed" <markjreed@xxxxxxxxx>

To: William DeShazer <earl.deshazer@xxxxxxxxx>

Cc: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, zsh-workers@xxxxxxx

Subject: Re: Unicode allowables in Environment variables

Date: Mon, 4 Nov 2024 16:10:54 -0500

Archived-at: <https://zsh.org/workers/53196>

In-reply-to: <77CB1ACE-0320-4FDD-B832-5E8B3C74B636@gmail.com>

List-id: <zsh-workers.zsh.org>

References: <91C10172-A533-487F-8D78-20129CA96689@gmail.com> <CAHYJk3SXo5Z26xMtuWUvsU+QvGzTD7oYUCk3QugppG0u4ce1fw@mail.gmail.com> <CAA=-s3yC_bgFheW74=u34YhL-xT-q294qs_L8BC9tKDtLCB7PQ@mail.gmail.com> <5CF1A197-AB70-4D07-BA0C-618213A2ACA1@gmail.com> <C54A42B1-07B6-4726-A7FB-CAD1E73C812A@gmail.com> <CAH+w=7bunCEwaaQSe+bToon3F1yH+iq_Eb35fNO1D9R+zNBGjQ@mail.gmail.com> <CAA=-s3yQUNacMpy7m7Ea2BBt=GgTJGPzhPyKS1hxfCyEgA3tSQ@mail.gmail.com> <CAH+w=7ZLMw_yntU3mnp0YwAmaa8gRif_=N0_4HkXA517offbYA@mail.gmail.com> <CAA=-s3zT5zzbA1YaWLGhSamkQ_s77pHTqw5N6iVCF+uo=gW1Ow@mail.gmail.com> <CAH+w=7bebJ3zatyodiHmT9i0CJW7BHhfC_iA_4+sc93+4+JVpw@mail.gmail.com> <CAH+w=7ZmVjD-3xSSwewSgfVJvWW=CB+=vodSRxgpSwPojYLeqg@mail.gmail.com> <CAA=-s3xovjsEhqmcOLeJ-5TcpcivCKMHn3NTDCnfWGgyJcKXMQ@mail.gmail.com> <CAH+w=7ai4-2_=tzNratoou=gPgZKV4-c_+nFmWBom8Wd8ZWHRw@mail.gmail.com> <CAA=-s3z_0XHG1dN5125MV=XKi3V0tgQguy36P1G0NBvqTE4C8g@mail.gmail.com> <77CB1ACE-0320-4FDD-B832-5E8B3C74B636@gmail.com>

I'm not sure why unmetafy() is munging it at all, though, as none of the bytes in the UTF-8 encoding of either of our emojiful pathnames is equal to Meta (0x83).

🔮 is 0xf0 0x9f 0x94 0xae, and 🍇 is 0xf0 0x9f 0x8d 0x87. Possibly because it proceeds right on past the nul terminator if the string has no Meta in it. That seems like a bug.

On Mon, Nov 4, 2024 at 3:53 PM William DeShazer <earl.deshazer@xxxxxxxxx> wrote:

Yes. I can confirm that I had to reset it at every stage. That’s not a horrible solution, but I was worried that there might be some things under the hood that would not set correctly if the value wasn't retained between configuration files. I’ll go ahead and try to do a custom development build to see if I can help with the resolution. Im just happy to be validated. I was sure it was my ignorance. I appreciate the support.

Will

On Nov 4, 2024, at 12:31, Mark J. Reed <markjreed@xxxxxxxxx> wrote:

Looks like once it's munged, it doesn't change any more. So the re-munging (getsparam_u() or whatever) must be idempotent.

<image.png>

I also tried adding corrections immediately after the echos. It was fine at the start of /etc/zshenv, corrupted at the start of ~/.zshenv, back to fine at the start of /etc/zshrc, and corrupted again at the start of ~/.zshrc, which makes sense if the problem is sourcehome().

On Mon, Nov 4, 2024 at 3:07 PM Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
On Mon, Nov 4, 2024 at 11:15 AM Mark J. Reed <markjreed@xxxxxxxxx> wrote:
>
> It does seem to get munged a second time. If I put a correcting ZDOTDIR=$(printenv ZDOTDIR) at the top of /etc/zshrc, it's again unechoable by the time I get a prompt.

If you DO NOT correct it in /etc/zshrc, just echo it at every point,
is the pattern different each time? (Try "noglob echo ..." for the raw
string?)

--
Mark J. Reed <markjreed@xxxxxxxxx>

Reverse Date

Date

Thread

Author