Incompatibility with set -u

[maneandrea]

Describe the bug

If I want to use set -u for precautionary reasons in my .zshrc I get complaints of the like

zsh: : parameter not set

And the prompt doesn't render

To Reproduce

Steps to reproduce the behavior:

Just do set -u and see the aforementioned message pop up every time the prompt should be rendered.

Desktop

• OS + distribution: Arch Linux 2022-1-19
• Zsh version: 5.8
• Plugin version: 8f798f9

Additional context

This is probably more of a feature request than a bug: I'd like the script to avoid needing unset variables.

[romkatv]

Please post complete instructions how to reproduce.

[maneandrea]

Sorry, I'll be more specific:

1. Set up powerlevel10k using the wizard p10k configure
2. Open a terminal emulator with zsh as shell and powerlevel10k loaded.
3. Type set -u and press enter

Expected:

The option -u is set. Nothing else happens and echo $- outputs a string with a u in it.

What happens

The option -u is set and echo $- outputs a string with a u in it. But

1. The prompt is not rendered
2. I get an error message every time the prompt should have been rendered

[romkatv]

Cannot reproduce. Here's what I've tried.

1. Run this:

   docker run -e TERM -e COLORTERM -e LC_ALL=C.UTF-8 -it --rm alpine sh -uec '
   apk add git zsh nano vim
   git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ~/powerlevel10k
   echo "source ~/powerlevel10k/powerlevel10k.zsh-theme" >>~/.zshrc
   cd ~/powerlevel10k
   exec zsh'

2. In the wizard reply No to the first 4 questions, then always choose the first option.
3. Type set -u.

There is prompt. There are no errors.

[romkatv]

You mentioned that you are using Arch Linux, so I tried to reproduced this in Arch Linux. Still no luck.

1. Run this:

   docker run -e LANG=en_US.utf8 -e TERM -e COLORTERM -it --rm archlinux bash -uec '
   pacman -Syy
   pacman -S --noconfirm archlinux-keyring
   pacman -Su --noconfirm
   pacman -S --noconfirm base-devel git zsh
   useradd -ms /bin/zsh me
   echo "me ALL=(ALL) NOPASSWD:ALL" >>/etc/sudoers
   runuser -l me -c "
     set -ue
     git clone --depth=1 https://aur.archlinux.org/yay.git ~/yay
     cd ~/yay
     makepkg -si --noconfirm
     yay -Sy --noconfirm zsh-theme-powerlevel10k-git
     touch ~/.zshrc"
   cd /home/me
   echo "source /usr/share/zsh-theme-powerlevel10k/powerlevel10k.zsh-theme" >.zshrc
   exec su - me'

2. In the wizard reply No to the first 4 questions, then always choose the first option.
3. Type set -u.

There is prompt. There are no errors.

Closing as not reproducible. Please reopen if you can post specific instructions how to reproduce.

[maneandrea]

Ok, sorry for the trouble. It must be some other issue then. Thanks for checking tho.

[ahummel25]

@maneandrea I also get this error every time whether I run set -u in the terminal or in a shell script. If in a shell script, it causes the script to exit with a non-zero status and closes the terminal. I'm in an iterm2 terminal on an M1 Mac. Did you find any fix?

Issue demo here:

https://user-images.githubusercontent.com/12643871/216185155-66b8914c-7fb4-449b-a2b1-d22caf28c985.mov

[maneandrea]

No, I just avoided using set -u. I think that it is an issue that arises only for some configurations. Namely if you say "No" (x4) and then choose always the first option for all questions in the p10kconfigure wizard, then it works, but for other choices it doesn't.

I didn't have too much motivation to try and narrow it down to the specific thing that broke it. If you have a strong need for set -u maybe together we can reopen this issue and figure it out.

[romkatv]

If you can tell me how to reproduce this problem, I'll likely be able to fix it. I need the exact ~/.zshrc and ~/.p10k.zsh that leads to it. ~/.zshrc should have nothing except powerlevel10k in it (and perhaps set -u in some place).

[romkatv]

@ahummel25 Your video shows errors from zsh-autosuggestions. It's independent from powerlevel10k and I have no control over it.

That said, running set -u is extremely unlikely to be doing what you want. The solution is almost certainly to not run this command in your interactive shell.

[ahummel25]

Yeah I'm tending to agree with you there. Probably more effort than it's worth to find out what's going on here. I think just not using set -u is fine. Thanks for the reply @maneandrea @romkatv.