-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unsetopt CASE_GLOB
breaks performance
#2057
Comments
I can confirm that the performance is an issue and that setting:
leads to significant improvement indeed. Anyway I started to have performance issues only like for last 2 years (and kept pushing looking into them for about that long). I was always using case insensitive autocomplete but it never lead to performance issues before. Based on that I think it's likely also performance regression though I can't say anything to how it happened. |
Some further explanation why this breaks performance. If you glob a path like With case-insensitive globbing, zsh will enter root directory, go through the list of all files inside of it and search for directories matching glob The drop in performance depends on the size of all the directories along the path For a concrete example, let's take this particular line, where I encountered the problem the first time: https://github.com/zsh-users/zsh/blob/28410bd5bc71fda6343b13c2b6abad06bd2eaaee/Functions/Prompts/promptinit#L23. The drop in performance is probably negligible if there's only hundreds or so of files. But on nix |
@JustWhateverIOnlyWantBetterCodeView Thanks for additional clarification. This is what I understood from your comment in home-manager (linked above as well). This behaviour makes a lot of sense of course. Since if you're on FS with case-sensitive file names, the only (sane) way to do the case-insensitivity on top is to do the listing of all content. It's also clear that number of directories zsh has to enter to collect this has a great (at least o(n)) impact on this so globbing That's being said I think what might have changed is the amount of globing that is being done when profile gets loaded. For instance in my case the primary source of slowness is prompt |
I think that:
|
I already posted this to nix-community/home-manager#2255 (comment) but for greater visibility this is the work around I endup with for now. file: .zshrc: # Triger `vcs_info 'prompt'` before loading Prezto.
# We want the first call to this happen before prezto will
# `unsetopt CASE_GLOB` which will have negative effect on the performance.
# Calling this before case sensitive globing makes initial start much faster.
# see: https://github.com/nix-community/home-manager/issues/2255
autoload -Uz vcs_info
vcs_info 'prompt'
# Source Prezto.
if [[ -s "${ZDOTDIR:-$HOME}/.zprezto/init.zsh" ]]; then
source "${ZDOTDIR:-$HOME}/.zprezto/init.zsh"
fi |
By default "completion" module does
unsetopt CASE_GLOB
. This completely breaks performance, see my comment on this issue: nix-community/home-manager#2255 (comment).This option is also harmful and could result in privilege escalation.
Assume I add path
/a/b
to fpath and some module/script sources scripts from this fpath. If unprivileged user has write access to/a
, but not to/a/b
, and a sticky bit is set on directory/a
, then it could create directory/a/B
, and any glob that uses fpath, would also match paths in attacker-controlled directory/a/B
. Though this scenario is a bit theoretical as such setup of privileges seems unlikely on any real system.The text was updated successfully, but these errors were encountered: