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-directorieshttp://www.zsh.org/mla/users/2008/msg00566.htmlhttps://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.
