From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3295 invoked by alias); 27 Sep 2016 12:15:37 -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: 39463 Received: (qmail 21252 invoked from network); 27 Sep 2016 12:15:37 -0000 X-Qmail-Scanner-Diagnostics: from kahlil.inlv.org by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(37.59.109.123):SA:0(-3.0/5.0):. Processed in 0.540721 secs); 27 Sep 2016 12:15:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: martijn@inlv.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at inlv.org does not designate permitted sender hosts) Subject: Re: Is "command" working right, yet? To: Zsh hackers list References: <160202163744.ZM2066@torch.brasslantern.com> <56B761B8.6000507@inlv.org> <160925201328.ZM24563@torch.brasslantern.com> <20160927110820.7661e8ad@pwslap01u.europe.root.pri> From: Martijn Dekker Message-ID: <564b0585-4286-a6c6-d64e-b190af5ace57@inlv.org> Date: Tue, 27 Sep 2016 13:15:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160927110820.7661e8ad@pwslap01u.europe.root.pri> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Op 27-09-16 om 11:08 schreef Peter Stephenson: > On Sun, 25 Sep 2016 20:13:28 -0700 > Bart Schaefer wrote: >> A complication is that "command -v" is defined in terms of bin_whence(), >> and "whence" has a -p option that means something different. > > That also means path search. Nope. 'command -p' means: ignore the PATH environment variable and do the search as normal, but (if it's a path search) use the system default path as output by the 'getconf PATH' command. That means the -p option has no effect for builtins. POSIX provides this as one way to make shell scripts a bit more robust; 'command -p grep' guarantees you get either the system's external 'grep' or a builtin version provided by the shell, and not some other 'grep' that the user (or someone who hacked them) may have installed in some location that comes before the real 'grep' in $PATH and that may, for all anyone knows, delete all their files. Reference: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html#tag_20_22_04 This is why it's important that '-p' should combine properly with '-v' and '-V'. The command 'command -pv grep', provided there is no builtin for it, should output the location of the system default 'grep' as opposed to whatever 'grep' may take precedence over it in $PATH. By the way, 'command -p' *nearly* works properly (i.e. as described above) in zsh, apart from combining with other options. See line 664 and on in exec.c, line 2030 and on in configure.ac, and line 77 in config.h.in. The problem is configure.ac only tries non-standard 'getconf' commands (i.e. 'getconf _CS_PATH' and 'getconf CS_PATH'); the command to use on BSD/OSX is 'getconf PATH', which works on Linux as well. I don't know if the other two should be kept, but 'getconf PATH' should at least be added. diff --git a/configure.ac b/configure.ac index 0e0bd53..e0eb320 100644 --- a/configure.ac +++ b/configure.ac @@ -2035,6 +2035,8 @@ AC_CACHE_VAL(zsh_cv_cs_path, zsh_cv_cs_path=`getconf _CS_PATH` elif getconf CS_PATH >/dev/null 2>&1; then zsh_cv_cs_path=`getconf CS_PATH` +elif getconf PATH >/dev/null 2>&1; then + zsh_cv_cs_path=`getconf PATH` else zsh_cv_cs_path="/bin:/usr/bin" fi]) Thanks, - M.