| I have localized the issue to where I had previously been suspicious but for some reason was unable to incriminate it. Now I can … I think, unless this is revealing something else. What I can confirm is that the Variable state is preserved until here. So I think that removes my concern about some kind of interaction with tty.
It gets mangled inside /etc/zshrc_Apple_Terminal which is kicked off by /etc/zshrc. This code section is intended to synchronize with the new feature to have the Terminal.app Title bar auto update. In an effort to come up with a safe URL path, by adding this to a zsh hook, this code is mangling ZDOTDIR.
The code:
```zsh # Zsh support for Terminal. echo 'In zshrc_Apple_Terminal Before Mangling: '$ZDOTDIR # Working Directory # # Tell the terminal about the current working directory at each prompt. # # Terminal uses this to display the directory in the window title bar # and tab bar, and for behaviors including creating a new terminal with # the same working directory and restoring the working directory when # restoring a terminal for Resume. See Terminal > Preferences for # additional information. if [ -z "$INSIDE_EMACS" ]; then echo "I am here: $ZDOTDIR:" update_terminal_cwd() { # Identify the directory using a "file:" scheme URL, including # the host name to disambiguate local vs. remote paths. # Percent-encode the pathname. local url_path='' { # Use LC_CTYPE=C to process text byte-by-byte and # LC_COLLATE=C to compare byte-for-byte. Ensure that # LC_ALL and LANG are not set so they don't interfere. local i ch hexch LC_CTYPE=C LC_COLLATE=C LC_ALL= LANG= for ((i = 1; i <= ${#PWD}; ++i)); do ch="$PWD[i]" if [[ "$ch" =~ [/._~A-Za-z0-9-] ]]; then url_path+="$ch" else printf -v hexch "%02X" "'$ch" url_path+="%$hexch" fi done echo POST UPDATE: $ZDOTDIR } printf '\e]7;%s\a' "file://$HOST$url_path" } # Register the function so it is called at each prompt. autoload -Uz add-zsh-hook add-zsh-hook precmd update_terminal_cwd fi ```
```Last login: Mon Nov 4 07:12:15 on ttys003
In ~/.ZPROFILE: /Users/$USER/App🔮Bundles/Configurations/Zsh/•Z
Confirming Chars in Cat -v: /Users/$USER/App?M-^_M-^T?Bundles/Configurations/Zsh/?M-^@?Z
/Users/$USER/App🔮Bundles/Configurations/Zsh/•Z
/Users/$USER/App🔮Bundles/Configurations/Zsh/•Z
In zshrc_Apple_Terminal Before Mangling: /Users/$USER/App🔮Bundles/Configurations/Zsh/•Z
I am here: /Users/$USER/App🔮Bundles/Configurations/Zsh/•Z:
/Users/$USER/App\M-p\<\M-.Bundles/Configurations/Zsh/•Z/.zshrc:4: bad pattern: /Users/$USER/App\M-p<\M-.Bundles/Configurations/Zsh/•Z
update_terminal_cwd:20: bad pattern: /Users/$USER/App?<?Bundles/Configurations/Zsh/?\M-^@?Z
I’m not familiar enough with Unicode to know if the format spec “%02X” is presumptive. Would anyone posit a more robust solution to getting a URL?
Kind regards,
Will
On Nov 3, 2024, at 22:27, William DeShazer <earl.deshazer@xxxxxxxxx> wrote:
Thanks to both of you for considering this.
Correct me if I am wrong, but in both of your, Mark's and Mikael's, examples, it appears that you are at a prompt, meaning an existing session and then spawn a sub-shell. I concede that will work. The problem is that ZDOTDIR defined that late results in all the dotfiles being created or utilized from $HOME.
I would like it to be defined when a new instance of Terminal.app launches.
I think it is important to point out, when Terminal.app launches it does look for .zshenv in ~/App🔮Bundles/Configurations/Zsh/•Z, but inside of the .zshenv or .zshrc if I echo $ZDOTDIR I get this (although I removed my username):
/Users/<username>/App\M-p\<\M-.Bundles/Configurations/Zsh/•Z/.zshenv:3: bad pattern: /Users/<username>/App\M-p<\M-.Bundles/Configurations/Zsh/•Z
I have never looked this low into the shell initialization before, but somewhere between init and .zshenv ZDOTDIR gets metafied.
Is there anything that I can share that would help you see what’s going on?
Kind regards,
Will DeShazer
On Nov 3, 2024, at 20:13, Mark J. Reed <markjreed@xxxxxxxxx> wrote:
I don't use osx, but the following works fine here: % ZDOTDIR=🔮 zsh -f
% echo $ZDOTDIR 🔮
I am on macOS, and that works fine here, too. As do Unicode things that go beyond putting a string into a parameter value; for instance, you can use non-Latin alphanumerics in variable names:
% ℋ=$HOME % echo $ℋ
/Users/mjreed
You can even export such a var, though for some reason trying to set such a var in the environment of a command (e.g. ℋ=$HOME zsh -f) doesn't work.
On Sun, Nov 3, 2024 at 9:19 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
On Sun, Nov 3, 2024 at 10:49 PM William DeShazer
<earl.deshazer@xxxxxxxxx> wrote:
>
> Greetings,
>
> I have been using non-POSIX compliant unicode characters in my Folder names because of the tremendous amounts of literature that say both macOS and particularly the Terminal.app and Zsh support it. In using the Crystal-ball character in the path of my ZDOTDIR, I found that it got Metafied and no literature explained that behavior for environment variables, save this discussion in 2014 (https://zsh.sourceforge.io/FAQ/zshfaq05.html#l56)
>
> I think that if this is the behavior, it should at least be put on this FAQ, https://zsh.sourceforge.io/FAQ/zshfaq05.html#l56.
>
> It should be clear and in big bold letters.
>
> If that is not the case, then I would appreciate a definitive statement and then some guidance on what might be metafiying my ZDOTDIR. It’s too closely aligned with the practice of Zsh to Metafy not to be obvious to someone.
>
> For reference the crystal ball unicode is \U0001F52E and I made the assignment in a few places:
>
> COMBINING_CHARS, MULTIBYTE were both set and $(locale LC_CTYPE) == UTF-8
>
> First: ~/.zshenv
>
> `export ZDOTDIR=~/App🔮Bundles/Configurations/Zsh/•Z`
>
> and then using launchctl
>
> `lauchctl setenv ZDOTDIR /Users/$USER/App🔮Bundles/Configurations/Zsh/•Z`
>
> When they get to my other dotfiles, it is read as:
>
> /Users/$USER/App\M-p\<\M-.Bundles/Configurations/Zsh/•Z
When your crystal ball is metafied, the sequence is ð\M-^C¿\M-^C´® so
whatever your problem is, it's not related to metafying.
I don't use osx, but the following works fine here:
% ZDOTDIR=🔮 zsh -f
% echo $ZDOTDIR
🔮
Perhaps your problem is with launchctl?
--
Mikael Magnusson
--
Mark J. Reed <markjreed@xxxxxxxxx>
On Nov 3, 2024, at 22:27, William DeShazer <earl.deshazer@xxxxxxxxx> wrote:
Thanks to both of you for considering this.
Correct me if I am wrong, but in both of your, Mark's and Mikael's, examples, it appears that you are at a prompt, meaning an existing session and then spawn a sub-shell. I concede that will work. The problem is that ZDOTDIR defined that late results in all the dotfiles being created or utilized from $HOME.
I would like it to be defined when a new instance of Terminal.app launches.
I think it is important to point out, when Terminal.app launches it does look for .zshenv in ~/App🔮Bundles/Configurations/Zsh/•Z, but inside of the .zshenv or .zshrc if I echo $ZDOTDIR I get this (although I removed my username):
/Users/<username>/App\M-p\<\M-.Bundles/Configurations/Zsh/•Z/.zshenv:3: bad pattern: /Users/<username>/App\M-p<\M-.Bundles/Configurations/Zsh/•Z
I have never looked this low into the shell initialization before, but somewhere between init and .zshenv ZDOTDIR gets metafied.
Is there anything that I can share that would help you see what’s going on?
Kind regards,
Will DeShazer
On Nov 3, 2024, at 20:13, Mark J. Reed <markjreed@xxxxxxxxx> wrote:
I don't use osx, but the following works fine here: % ZDOTDIR=🔮 zsh -f
% echo $ZDOTDIR 🔮
I am on macOS, and that works fine here, too. As do Unicode things that go beyond putting a string into a parameter value; for instance, you can use non-Latin alphanumerics in variable names:
% ℋ=$HOME
You can even export such a var, though for some reason trying to set such a var in the environment of a command (e.g. ℋ=$HOME zsh -f) doesn't work.
On Sun, Nov 3, 2024 at 10:49 PM William DeShazer
<earl.deshazer@xxxxxxxxx> wrote:
>
> Greetings,
>
> I have been using non-POSIX compliant unicode characters in my Folder names because of the tremendous amounts of literature that say both macOS and particularly the Terminal.app and Zsh support it. In using the Crystal-ball character in the path of my ZDOTDIR, I found that it got Metafied and no literature explained that behavior for environment variables, save this discussion in 2014 (https://zsh.sourceforge.io/FAQ/zshfaq05.html#l56)
>
> I think that if this is the behavior, it should at least be put on this FAQ, https://zsh.sourceforge.io/FAQ/zshfaq05.html#l56.
>
> It should be clear and in big bold letters.
>
> If that is not the case, then I would appreciate a definitive statement and then some guidance on what might be metafiying my ZDOTDIR. It’s too closely aligned with the practice of Zsh to Metafy not to be obvious to someone.
>
> For reference the crystal ball unicode is \U0001F52E and I made the assignment in a few places:
>
> COMBINING_CHARS, MULTIBYTE were both set and $(locale LC_CTYPE) == UTF-8
>
> First: ~/.zshenv
>
> `export ZDOTDIR=~/App🔮Bundles/Configurations/Zsh/•Z`
>
> and then using launchctl
>
> `lauchctl setenv ZDOTDIR /Users/$USER/App🔮Bundles/Configurations/Zsh/•Z`
>
> When they get to my other dotfiles, it is read as:
>
> /Users/$USER/App\M-p\<\M-.Bundles/Configurations/Zsh/•Z
When your crystal ball is metafied, the sequence is ð\M-^C¿\M-^C´® so
whatever your problem is, it's not related to metafying.
I don't use osx, but the following works fine here:
% ZDOTDIR=🔮 zsh -f
% echo $ZDOTDIR
🔮
Perhaps your problem is with launchctl?
--
Mikael Magnusson
--
|