zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh Workers <zsh-workers@zsh.org>
Subject: Re: BUG: Shell builtin `which` prints non-existent commands to stdout
Date: Tue, 25 Sep 2018 10:10:22 +0100	[thread overview]
Message-ID: <20180925091023eucas1p24cd3759171336e31251ecc3d09e63a55~XmYvgU4Ac0409004090eucas1p2Y@eucas1p2.samsung.com> (raw)
In-Reply-To: <20180924223253.j46bxsughzy6grbf@chaz.gmail.com>

On Mon, 24 Sep 2018 23:32:53 +0100
Stephane Chazelas <stephane.chazelas@gmail.com> wrote:
> About "other shells" above, AFAIK, tcsh is the only other shell
> that has a "which" builtin and it does also send "command not
> found" to stdout. So zsh behaves like every other shells in that
> regard.

Thanks, I've updated the text.

pws

diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo
index 9f634d1..81d7628 100644
--- a/Etc/FAQ.yo
+++ b/Etc/FAQ.yo
@@ -1976,21 +1976,22 @@ sect(Why does `which' output for missing commands go to stdout?)
   as they would if the command was about to be executed but could not be
   found.
 
-  The original reason for this is that this behaviour is inherited
-  from the C shell (csh), where `tt(which)' itself originated.  So
-  it has been in zsh a very long time, and it is now a feature.
-  (It would be possible to change this in emulation modes; however.
-  so far this possibility has been seen has more of an additional
-  confusion than a help.)
-
-  If you want some further rationalisation, which may be what the C
-  shell designers had in mind, you might note that `tt(which)' is
-  designed as a way of outputting information about a command.  So
-  `this command can be found in ...' and `this command can't be found'
-  are both bits of information here, unlike the case where the command
-  is to be executed.  So although it differs from other Bourne-style
-  shells it is in fact self-consistent.  Note that the exit status does
-  reflect the fact the command can't be found.
+  The original reason for this is that this behaviour is inherited from
+  previous versions of `tt(which)', a builtin in tcsh (an adaptation of
+  the C Shell with better editing) and also a separate script.  Other
+  shells had equivalent commands, `tt(whence)' and `tt(type), that zsh
+  has also adopted.  So in fact this has always been a feature of
+  `tt(which)'.  (It would be possible to change this in emulation modes;
+  however.  so far this possibility has been seen has more of an
+  additional confusion than a help.)
+
+  If you want some further rationalisation, you might note that
+  `tt(which)' is designed as a way of outputting information about a
+  command.  So `this command can be found in ...' and `this command
+  can't be found' are both bits of information here, unlike the case
+  where the command is to be executed.  So although it differs from
+  other Bourne-style shells it is in fact self-consistent.  Note that
+  the exit status does reflect the fact the command can't be found.
 
 
 chapter(The mysteries of completion)

  reply	other threads:[~2018-09-25  9:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180924080113epcas4p4f8f89aa03a2cebc5030fd45dca0f6e84@epcas4p4.samsung.com>
2018-09-24  8:00 ` Klaus Alexander Seistrup
2018-09-24 10:22   ` Peter Stephenson
2018-09-24 12:29     ` Klaus Alexander Seistrup
2018-09-24 12:51       ` Peter Stephenson
2018-09-24 13:22         ` [PATCH] zshbuiltins(1): Document 'which''s "not found is not an error" behaviour Daniel Shahaf
2018-09-24 22:18         ` BUG: Shell builtin `which` prints non-existent commands to stdout Stephane Chazelas
2018-09-25  7:56           ` Stephane Chazelas
2018-09-24 22:32         ` Stephane Chazelas
2018-09-25  9:10           ` Peter Stephenson [this message]
     [not found]   ` <20180924112218.7bac7f2c@camnpupstephen.cam.scsc.local>
2018-09-24 10:25     ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='20180925091023eucas1p24cd3759171336e31251ecc3d09e63a55~XmYvgU4Ac0409004090eucas1p2Y@eucas1p2.samsung.com' \
    --to=p.stephenson@samsung.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).