zsh does not work with home-manager build

[Jomik]

The implementation of zsh in home-manager assumes that a dotdir is made in home and that the plugins are moved there. I don't really see why this should be done. There shouldn't actually be a reason to link the plugins into $HOME, we should be able to just source them directly from the nix store.

The above results in being unable to test zsh configs using home-manager build, as it wont actually be able to source packages.

[uvNikita]

You have a good point, but this comment describes the reason for such set up: https://github.com/rycee/home-manager/pull/56#issuecomment-328057513. TLDR: adding directories prefixed with /nix/store to fpath results in a slow startup of zsh when compinit is used.

That said, it would be nice to get a proper fix for this issue since as you mentioned, originally it's unnecessary to link plugins into $HOME.

[Jomik]

Oh, that does make a lot of sense then @uvNikita . Why it is happening - not the choice. I feel like this compromises the nix mentality, it is not declarative, as we depend on something outside of our actual setup. We don't even have to do something sketchy for it to happen, I ran into this while trying to test my setup, because I didn't want to switch each time, I was just wanting to execute zsh with the config file that was generated by home-manager. I guess we would have to look into seeing if there is a better way to fix the slowdown, otherwise I feel like it should be an option, whether to use $HOME or not.

[Jomik]

Looking more at this, I am not actually sure why the nix store is insecure according to zsh. Issues seem to be that directories are group writable, and thus zsh marks them as insecure, but the nix store is owned by root and only writable by owner. I am guessing it is because the user running zsh needs to also own all directories that are put in fpath. That does seem hard to fix.

[uvNikita]

Yes, that was my conclusion as well, it seems that zsh checks only permissions of the parent folder and not its owner.

One option would be to check if we can patch zsh to fix this behavior (if it's indeed broken). Or, as you suggested, create a workaround option with a description that warns users that enabling it might impact zsh startup time.

[Jomik]

According to an issue here, https://github.com/robbyrussell/oh-my-zsh/issues/6835#issuecomment-406863745, it should be fine to have the directory owned by root, so /nix/store should be fine.

[uvNikita]

Hmm, maybe it was fixed already? We should double check if it's still an issue since it has been a while.

[Sean1708]

Hmm, maybe it was fixed already?

I can confirm that it's still an issue on multi-user installations, because I ran into it earlier this week. I believe it's because on multi-user installations the store is writeable by the nixbld group

> ls -l /nix
total 1460
drwxrwxr-t 774 root nixbld 1486848 Sep 19 08:06 store
drwxr-xr-x   4 root root      4096 Aug 23 12:37 var

and therefore zsh still complains about it being insecure.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[carlthome]

I'm also getting complaints on a multi-user nix install on a M1 Mac with zsh.

❯ compaudit 
There are insecure directories and files:
/nix/var/nix/profiles/default/share/zsh/site-functions
/nix/var/nix/profiles/default/share/zsh
/nix/var/nix/profiles/default/share/zsh
/nix/var/nix/profiles/default/share/zsh/site-functions/_nix

ls -l /nix
total 0
drwxrwxr-t  24707 root  nixbld  790624 29 Jul 14:48 store
drwxr-xr-x      4 root  nixbld     128  4 Jun 13:00 var

home-manager works but it's an annoyance that every shell starts with a prompt:

Last login: Fri Jul 29 14:53:38 on ttys002
zsh compinit: insecure directories and files, run compaudit for list.
Ignore insecure directories and files and continue [y] or abort compinit [n]? 

Is it possible to get rid of that prompt? Should this issue be reopened?

[piegamesde]

@carlthome this looks like a different issue, so I'd suggest opening a new one

[phamann]

Hey @carlthome, I found this thread while trying to google the same issue. Did you open another issue to discuss? Or even better, did you ever manage to fix the issue?

[carlthome]

Hey @carlthome, I found this thread while trying to google the same issue. Did you open another issue to discuss? Or even better, did you ever manage to fix the issue?

Didn't open another issue. Also, not having this issue anymore but don't remember what made it work during my tinkering, unfortunately. This is what I'm using now: https://github.com/carlthome/dotfiles/tree/main/modules/home-manager