For some reason, zshcompsys thinks that it is up to it do be a sysadmin. By default, `compinit` checks for 'insecure' directories and files. From `man 1 zshcompsys`: For security reasons compinit also checks if the completion system would use files not owned by root or by the current user, or files in directories that are world- or group-writable or that are not owned by root or by The current user. People suffering from the rammifications of this can be found here: http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/ http://stackoverflow.com/questions/13762280/zsh-compinit-insecure-directories http://www.zsh.org/mla/users/2008/msg00566.html https://github.com/Homebrew/homebrew/issues/7801 To sumarize, if you have files with permissions that are 'bad' (ex: 777 on /usr/share/folder/), then zshcompsys enables you to ignore those directories and files. That begs the question, why is it zshcompsys' job to police the system? If you have 777 permissions on a folder in /usr/share/something, that makes the sysadmin DUMB. On the flip side, there are many situations in which it is perfectly legitimate to allow a group to have write permissions to a directory that contains binary files. It shouldn't be up to zshcompsys to point out that you're an idiot. Running compaudit (the 'security' checks) also takes up a significant chunk of time, which can be exacerbated on low-end systems. This commit disables the compaudit, while still enabling the .zcompdump as provided by compinit, as it acts as a cache.pull/1010/head
parent
f2a826e963
commit
7f22881dd1
Loading…
Reference in new issue