From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24191 invoked by alias); 29 Sep 2015 17:59:25 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36698 Received: (qmail 8896 invoked from network); 29 Sep 2015 17:59:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=v7XFSc9vRU6Dmd5RoPSY2ckQMSMV7+wKvD1ZDypc84o=; b=OLb0/7VFchvCaykOO3pRDG0GVKTIyul5VG/yoicCd0U5KlsatRvmfUCjIItueQlJe0 Cfwvpu2exE0r3h15pzRANmU9vdHq72gKfSbAQncF6rwoOw3BJcGjRzVwivvk5sN/82WN U0OjQsMTfCOODn1gkKkfVxFdK5ie72UIqe+vWMGah61NkcFscDLw50H6Ny1n47JZA38y mmaXkB6mF2HLD821HZBMGxoTX2APglCiDK1N/zayEiOBi8Q84ig/bzNLMUoYy4O4R2jH tTBGGe4f1nTfgVByg9T30BOoC1RcjGpAHAhxa1rQO1Q698VRHYfhMJjchHXYrh3Y9XUf /z/Q== X-Gm-Message-State: ALoCoQlMrAK3H1pxY48C9ysfy3NT27Z3ARYUgjlPd5nsXmqC9LU/1M9/H1QFD9t54H26UbIlGb6C X-Received: by 10.60.60.67 with SMTP id f3mr15505591oer.43.1443549559269; Tue, 29 Sep 2015 10:59:19 -0700 (PDT) From: Bart Schaefer Message-Id: <150929105915.ZM30290@torch.brasslantern.com> Date: Tue, 29 Sep 2015 10:59:15 -0700 In-Reply-To: <5609B684.2010303@apjanke.net> Comments: In reply to Andrew Janke "Re: "compinit -i" not excluding some insecure dirs?" (Sep 28, 5:52pm) References: <56092456.3000006@apjanke.net> <150928141732.ZM15458@torch.brasslantern.com> <5609B684.2010303@apjanke.net> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh hackers list Subject: Re: "compinit -i" not excluding some insecure dirs? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 28, 5:52pm, Andrew Janke wrote: } } But in this case I think it *is* scanning the insecure directory: I had } a _foo only in /insecure, not in /secure, and it still got picked up by } compinit and used for completion. Hmm. compaudit returns true when no insecure directories are found or when it is passed the -u option. compinit sets _comp_secure only when compaudit returns true. compdump writes the files from the fpath directories into the dumpfile only when _comp_secure is set. However, I'm not sure this accomplishes what was intended. And in any case compinit doesn't otherwise change its behavior when passed -i, so yes, that's clearly a bug in the case where the dump file does not already exist.