2.4 pre-installer does not source nix after reboot in zsh

[SimonTheLeg]

Describe the bug

After an installation using the 2.4pre installer on my new laptop, everything works fine at first, but after a reboot nix is not sourced correctly.

Using zsh -o SOURCE_TRACE, I think I found the culprit:

On my old laptop

❯ zsh -o SOURCE_TRACE
+/etc/zshenv:1> <sourcetrace>
+/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh:1> <sourcetrace>

But on the new one /etc/zshenv does not exist

simonbein@Simons-MBP-2 ~ % ls /etc/zshenv
ls: /etc/zshenv: No such file or directory

We can see this in the zsh -o SOURCE_TRACE as well

simonbein@Simons-MBP-2 dotfiles % zsh -o SOURCE_TRACE
+/Users/simonbein/.zshenv:1> <sourcetrace>
+/etc/zshrc:1> <sourcetrace>

So my current assumption is that the old installer did edit /etc/zshenv, but a newer one does not. I have to admit though I have ran quite a lot of different nix installers on the old macbook, so I have no idea which one of the older versions did that.

Steps To Reproduce

1. Install using the 2.4pre-installer

curl -L https://releases.nixos.org/nix/nix-2.4pre-rc1/install | sh

2. Reboot the system
3. Try any command sourced by nix or even nix itself

nix
zsh: command not found: nix

Workaround I use for now
Currently I simply created the /etc/zshenv manually with the following content:

# Nix
if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
  . '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
fi
# End Nix

Expected behavior

Nix is correctly sourced when starting a new zsh

nix-env --version output

Now this of course returns command not found ;)
But:

/nix/var/nix/profiles/default/bin/nix-env --version
nix-env (Nix) 2.4pre-rc1

Additional context

• macOS 11.6
• brand new laptop

[abathur]

I think zshenv was only used in installers built from master, and was reverted in #5179

[SimonTheLeg]

I see. Hmm after reading the linked PR maybe there is a different issue. I just checked my /etc/zshrc and it does not contain the nix content either.

For completeness my /etc/zshrc after fresh install:

# System-wide profile for interactive zsh(1) shells.

# Setup user specific overrides for this in ~/.zshrc. See zshbuiltins(1)
# and zshoptions(1) for more details.

# Correctly display UTF-8 with combining characters.
if [[ "$(locale LC_CTYPE)" == "UTF-8" ]]; then
    setopt COMBINING_CHARS
fi

# Disable the log builtin, so we don't conflict with /usr/bin/log
disable log

# Save command history
HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history
HISTSIZE=2000
SAVEHIST=1000

# Beep on error
setopt BEEP

# Use keycodes (generated via zkbd) if present, otherwise fallback on
# values from terminfo
if [[ -r ${ZDOTDIR:-$HOME}/.zkbd/${TERM}-${VENDOR} ]] ; then
    source ${ZDOTDIR:-$HOME}/.zkbd/${TERM}-${VENDOR}
else
    typeset -g -A key

    [[ -n "$terminfo[kf1]" ]] && key[F1]=$terminfo[kf1]
    [[ -n "$terminfo[kf2]" ]] && key[F2]=$terminfo[kf2]
    [[ -n "$terminfo[kf3]" ]] && key[F3]=$terminfo[kf3]
    [[ -n "$terminfo[kf4]" ]] && key[F4]=$terminfo[kf4]
    [[ -n "$terminfo[kf5]" ]] && key[F5]=$terminfo[kf5]
    [[ -n "$terminfo[kf6]" ]] && key[F6]=$terminfo[kf6]
    [[ -n "$terminfo[kf7]" ]] && key[F7]=$terminfo[kf7]
    [[ -n "$terminfo[kf8]" ]] && key[F8]=$terminfo[kf8]
    [[ -n "$terminfo[kf9]" ]] && key[F9]=$terminfo[kf9]
    [[ -n "$terminfo[kf10]" ]] && key[F10]=$terminfo[kf10]
    [[ -n "$terminfo[kf11]" ]] && key[F11]=$terminfo[kf11]
    [[ -n "$terminfo[kf12]" ]] && key[F12]=$terminfo[kf12]
    [[ -n "$terminfo[kf13]" ]] && key[F13]=$terminfo[kf13]
    [[ -n "$terminfo[kf14]" ]] && key[F14]=$terminfo[kf14]
    [[ -n "$terminfo[kf15]" ]] && key[F15]=$terminfo[kf15]
    [[ -n "$terminfo[kf16]" ]] && key[F16]=$terminfo[kf16]
    [[ -n "$terminfo[kf17]" ]] && key[F17]=$terminfo[kf17]
    [[ -n "$terminfo[kf18]" ]] && key[F18]=$terminfo[kf18]
    [[ -n "$terminfo[kf19]" ]] && key[F19]=$terminfo[kf19]
    [[ -n "$terminfo[kf20]" ]] && key[F20]=$terminfo[kf20]
    [[ -n "$terminfo[kbs]" ]] && key[Backspace]=$terminfo[kbs]
    [[ -n "$terminfo[kich1]" ]] && key[Insert]=$terminfo[kich1]
    [[ -n "$terminfo[kdch1]" ]] && key[Delete]=$terminfo[kdch1]
    [[ -n "$terminfo[khome]" ]] && key[Home]=$terminfo[khome]
    [[ -n "$terminfo[kend]" ]] && key[End]=$terminfo[kend]
    [[ -n "$terminfo[kpp]" ]] && key[PageUp]=$terminfo[kpp]
    [[ -n "$terminfo[knp]" ]] && key[PageDown]=$terminfo[knp]
    [[ -n "$terminfo[kcuu1]" ]] && key[Up]=$terminfo[kcuu1]
    [[ -n "$terminfo[kcub1]" ]] && key[Left]=$terminfo[kcub1]
    [[ -n "$terminfo[kcud1]" ]] && key[Down]=$terminfo[kcud1]
    [[ -n "$terminfo[kcuf1]" ]] && key[Right]=$terminfo[kcuf1]
fi

# Default key bindings
[[ -n ${key[Delete]} ]] && bindkey "${key[Delete]}" delete-char
[[ -n ${key[Home]} ]] && bindkey "${key[Home]}" beginning-of-line
[[ -n ${key[End]} ]] && bindkey "${key[End]}" end-of-line
[[ -n ${key[Up]} ]] && bindkey "${key[Up]}" up-line-or-search
[[ -n ${key[Down]} ]] && bindkey "${key[Down]}" down-line-or-search

# Default prompt
PS1="%n@%m %1~ %# "

# Useful support for interacting with Terminal.app or other terminal programs
[ -r "/etc/zshrc_$TERM_PROGRAM" ] && . "/etc/zshrc_$TERM_PROGRAM"

[jsoo1]

@abathur This is a problem when the machine is a substituter or remote builder, or indeed, you just want to execute a nix command remotely via ssh. I ran into this problem when on another host I ran nix store ping --store ssh://user@example. The problem with the example host is that /etc/zshrc is not sourced for non-login shells. This breaks all kinds of commands like nix-copy-closure nix store ping and more. Even ssh user@example nix-env -q doesn't work because of the sourcing location. I'm afraid nix might need to be a bit more sophisticated in where it is sourcing the profile.

[jsoo1]

I am not sure if this is 100% a darwin problem, but I am reading the discussion in #4169 and getting sad, again

[abathur]

I'm afraid nix might need to be a bit more sophisticated in where it is sourcing the profile.

I agree (though I imagine it's easier said than done). I've been fishing around for anyone who can figure out the basics of a proper installer test suite--and flushing out shell profile problems and regressions is, in my opinion, one of the most-important reasons to have it.

As an observer, I think there's a lot of variety in the wild, and it doesn't seem like many (any?) people have a strong high-altitude cross-platform understanding. It's common enough for someone to touch the ~profile code because something isn't working for them without realizing their setup isn't normative/universal and break other users in the process.

The problem with the example host is that /etc/zshrc is not sourced for non-login shells. ... Even ssh user@example nix-env -q doesn't work because of the sourcing location.

I suppose the effect is the same, but after reading man zsh on Catalina I think this is actually because the remote shell isn't interactive. Here's the section:

STARTUP/SHUTDOWN FILES

Commands are first read from /etc/zshenv; this cannot be overridden. Subsequent behaviour is modified by the RCS and GLOBAL_RCS options; the former affects all startup files, while the second only affects global startup files (those shown here with an path starting with a /). If one of the options is unset at any point, any subsequent startup file(s) of the corresponding type will not be read. It is also possible for a file in $ZDOTDIR to re-enable GLOBAL_RCS. Both RCS and GLOBAL_RCS are set by default.

Commands are then read from $ZDOTDIR/.zshenv. If the shell is a login shell, commands are read from /etc/zprofile and then $ZDOTDIR/.zprofile. Then, if the shell is interactive, commands are read from /etc/zshrc and then $ZDOTDIR/.zshrc. Finally, if the shell is a login shell, /etc/zlogin and $ZDOTDIR/.zlogin are read.

[jsoo1]

I agree (though I imagine it's easier said than done). I've been fishing around for anyone who can figure out the basics of a proper installer test suite--and flushing out shell profile problems and regressions is, in my opinion, one of the most-important reasons to have it.

A test matrix for installers would be a massive help, wouldn't it?

As an observer, I think there's a lot of variety in the wild, and it doesn't seem like many (any?) people have a strong high-altitude cross-platform understanding. It's common enough for someone to touch the ~profile code because something isn't working for them without realizing their setup isn't normative/universal and break other users in the process.

Even more reason to setup a test matrix.

I suppose the effect is the same, but after reading man zsh on Catalina I think this is actually because the remote shell isn't interactive.

Yes, you're right. I tried both /etc/zprofile and /etc/zshenv which may be why I mentioned login instead of interactive shell.

[stale]

I marked this as stale due to inactivity. → More info