From e9a75f4bc70f4990775899d22fa298039de73ef5 Mon Sep 17 00:00:00 2001 From: Peter Stephenson Date: Mon, 24 Sep 2018 14:34:31 +0100 Subject: 43527, tweaked: describe which output behaviour in FAQ. --- Etc/FAQ.yo | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) (limited to 'Etc') diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo index a3dfc6c13..9f634d14a 100644 --- a/Etc/FAQ.yo +++ b/Etc/FAQ.yo @@ -127,6 +127,7 @@ Chapter 3: How to get various things to work 3.26. Why is my output duplicated with `tt(foo 2>&1 >foo.out | bar)'? 3.27. What are these `^' and `~' pattern characters, anyway? 3.28. How do I edit the input buffer in $EDITOR? +3.29. Why does `which' output for missing commands go to stdout? Chapter 4: The mysteries of completion 4.1. What is completion? @@ -1964,6 +1965,34 @@ label(328) quitting the editor will only return to zsh's command-line editing mode. +sect(Why does `which' output for missing commands go to stdout?) + + The issue is that if you run: + verb( + which non-existent-command + ) + the error message goes, unusually, to standard output rather than + to standard error. Other shells send this message to standard error, + 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. + + chapter(The mysteries of completion) -- cgit v1.2.3 From 3da60d210292698c00279d95150a79550e7e6370 Mon Sep 17 00:00:00 2001 From: Peter Stephenson Date: Wed, 26 Sep 2018 15:04:37 +0100 Subject: 53542 (tweaked): further output about "which" output --- ChangeLog | 4 ++++ Etc/FAQ.yo | 32 +++++++++++++++++--------------- 2 files changed, 21 insertions(+), 15 deletions(-) (limited to 'Etc') diff --git a/ChangeLog b/ChangeLog index e7ebc8aeb..9c6f4bbfd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2018-09-26 Peter Stephenson + + * 43542 (tweaked): Etc/FAQ.yo: further update about which output. + 2018-09-25 Daniel Shahaf * 43528: Doc/Zsh/builtins.yo: zshbuiltins(1): Document 'which''s diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo index 9f634d14a..da7cbe758 100644 --- a/Etc/FAQ.yo +++ b/Etc/FAQ.yo @@ -1976,21 +1976,23 @@ 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 later versions of csh, + the C shell, as well as tcsh, an adaptation of the C Shell with better + editing, and is also available as a separate script sometimes still + found in certain distributions. 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) -- cgit v1.2.3 From 0290757ed4ed7d99b5bab5d92933dd6026af9fff Mon Sep 17 00:00:00 2001 From: Peter Stephenson Date: Wed, 3 Oct 2018 13:53:12 +0100 Subject: unposted: minor FAQ typos --- ChangeLog | 2 ++ Etc/FAQ.yo | 4 ++-- 2 files changed, 4 insertions(+), 2 deletions(-) (limited to 'Etc') diff --git a/ChangeLog b/ChangeLog index c8b647c37..ece6efdad 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,7 @@ 2018-10-03 Peter Stephenson + * unposted: Etc/FAQ.yo: minor typos. + * 43589: Src/jobs.c: Show subjob status instead of superjob any time it still has processes. diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo index da7cbe758..6986a6ba4 100644 --- a/Etc/FAQ.yo +++ b/Etc/FAQ.yo @@ -1983,8 +1983,8 @@ sect(Why does `which' output for missing commands go to stdout?) found in certain distributions. 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.) + to change this in emulation modes; however, so far this possibility + has been seen as 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 -- cgit v1.2.3 From 9dbde9e9c7d22ee0d301e4a2fecf97906d1ddce9 Mon Sep 17 00:00:00 2001 From: Peter Stephenson Date: Wed, 19 Dec 2018 19:33:36 +0000 Subject: unposted: updates for 5.6.2-test-2 --- ChangeLog | 5 +++++ Config/version.mk | 4 ++-- Etc/FAQ.yo | 2 +- README | 21 +++++++++------------ 4 files changed, 17 insertions(+), 15 deletions(-) (limited to 'Etc') diff --git a/ChangeLog b/ChangeLog index 4f3c3e0eb..3cebb5b09 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2018-12-19 Peter Stephenson + + * unposted: Config/version.mk, Etc/FAQ.yo, README: update for + 5.6.2-test-2. + 2018-12-19 Peter Stephenson * unposted c.f. 43913: Functions/Zle/edit-command-line: emulate diff --git a/Config/version.mk b/Config/version.mk index 03f6cbf8f..099b9bb58 100644 --- a/Config/version.mk +++ b/Config/version.mk @@ -27,5 +27,5 @@ # This must also serve as a shell script, so do not add spaces around the # `=' signs. -VERSION=5.6.2-dev-1 -VERSION_DATE='October 11, 2018' +VERSION=5.6.2-test-2 +VERSION_DATE='December 19, 2018' diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo index 6986a6ba4..6c46cc09d 100644 --- a/Etc/FAQ.yo +++ b/Etc/FAQ.yo @@ -307,7 +307,7 @@ sect(On what machines will it run?) sect(What's the latest version?) - Zsh 5.6.2 is the latest production version. For details of all the + Zsh 5.7 is the latest production version. For details of all the changes, see the NEWS file in the source distribution. A beta of the next version is sometimes available. Development of zsh is diff --git a/README b/README index 1583002a7..aaaee5014 100644 --- a/README +++ b/README @@ -5,9 +5,7 @@ THE Z SHELL (ZSH) Version ------- -This is version 5.6.2 of the shell. This is a bugfix release, following -5.6 which was a security and feature release and 5.6.1 which was a bugfix -release. +This is version 5.7 of the shell. Note in particular the changes highlighted under "Incompatibilities since 5.6.2" below. See NEWS for more information. @@ -34,19 +32,18 @@ details, see the documentation. Incompatibilities since 5.6.2 ----------------------------- -1) vcs_info git: The gen-unapplied-string hook receives the patches in order (next -to be applied first). This is consistent with the hg backend and with one of -two contradictory claims in the documentation (the other one has been corrected). -In zsh through 5.6.2, the patches were passed in reverse order, next to be -applied being last in the array. +1) vcs_info git: The gen-unapplied-string hook receives the patches in +order (next to be applied first). This is consistent with the hg +backend and with one of two contradictory claims in the documentation +(the other one has been corrected). In zsh through 5.6.2, the patches +were passed in reverse order, next to be applied being last in the +array. The gen-applied-string hook is unaffected; it still receives the patches in reverse order, from last applied to first applied. -2) - -Incompatibilities since 5.5.1 ------------------------------ +Incompatibilities between 5.5.1 and 5.6.2 +------------------------------------------ The completion helper _remote_files, typically used after a hostname with scp-style completion, now uses remote-files instead of files as a -- cgit v1.2.3