This is version 5.8 of the shell. This is a security and feature release. There are a few visible improvements since 5.7, as well as many bugfixes. All zsh installations are encouraged to upgrade as soon as possible.
Note in particular the changes highlighted under "Incompatibilities since 5.7.1" below. See NEWS for more information.
The instructions for compiling zsh are in the file INSTALL. You should also check the file MACHINES in the top directory to see if there are any special instructions for your particular architecture.
Note in particular the zsh/newuser module that guides new users through setting basic shell options without the administrator's intervention. This is turned on by default. See the section AUTOMATIC NEW USER CONFIGURATION in INSTALL for configuration information.
Zsh is a shell with lots of features. For a list of some of these, see the file FEATURES, and for the latest changes see NEWS. For more details, see the documentation.
Build-time change: The default value of the --enable-gdbm configure argument has changed from "yes" to "no". Thus, the zsh/db/gdbm module will not be built unless --enable-gdbm is passed explicitly.
vcs_info quilt: The value of the 'quiltcommand' style used to be taken for the name of an external command. Now it may also be a shell function. Normal command word precedece rules apply, so if you have a function and a command with the same name, the function will be used.
The "function" reserved word, used to define functions, gained a new -T option. That affects syntaxes such as:
"function -T { ... }". It used to define a function named "-T". It now defines and executes an anonymous function with single-level tracing enabled --- same as "function f { ... }; functions -T f; f", but without naming the function.
"function -T foo { ... }". It used to define two functions, named "-T" and "foo" (see the MULTI_FUNC_DEF option). It now defines a function "foo" with tracing enabled.
"function -- { ... }". It used to define a function named "--". It now defines and executes an anonymous function. The "--" is taken to be an end-of-options guard (same as "ls --").
The sh-compatible function definition syntax, "f() { ... }", is unchanged.
The time-out (-t) value given to zsh/system's zsystem flock command is
now limited to 2^30-1 seconds (= a little over 34 years).
zstyle: For background, recall that the zstyle builtin associates styles with values for particular contexts, and when a context (such as ':foo:bar:baz') is matched by multiple patterns (such as ':foo:' and ':foo:bar:'), the style's value for the more specific of the patterns is used. In zsh 5.8 and earlier the determination of which pattern is "more specific" used semantics slightly different to those the documentation promised. The implementation was changed to match the documentation. The upshot of this is that if you set a single style in multiple contexts, zsh 5.9 may use the values set for a pattern other than the one zsh 5.8 used. For example, if you do zstyle ':foo:bar:' style value1 zstyle ':foo::baz:' style value2 and the style is looked up under a context that both patterns match (e.g., :foo:bar:baz:qux), zsh 5.9 will use value2 -- which is consistent with the documentation of both 5.8 and 5.9 -- but zsh 5.8 will use value1. If this affects you, make the implied colons in the first pattern explicit, as in: zstyle ':foo:bar::' style value1 zstyle ':foo::baz:*' style value2 This will use value1 in both 5.8 and 5.9.
Elements of the region_highlight array have gained a fourth space-separated field. Code written against 5.9 that sets the new field may break under 5.8: for example, the element "0 20 bold memo=foo", which is valid under 5.9, would not work under 5.8. (Under the hood, 5.8 does not recognize the space as terminating the highlighting specification.) On the other hand, code that does not set the new, fourth field will continue to work under both 5.8 and 5.9. (As it happens, adding a comma after "bold" will make both 5.8 and 5.9 do the right thing, but this should be viewed as an unsupported hack.)
The history expansion !:1:t2 used to be interpreted such that the 2 was a separate character added after the history expansion. Now it is an argument to the :t modifier.
For example
% echo /my/interesting/path % echo !:1:t2
used to echo "path2", but now echoes "interesting/path".
The behaviour of :h has similarly changed.
The behaviour has also changed in forms such as ${foo:t2) and *(:t2), but in those cases the previous behaviour was not meaningful.
The vcs_info function VCS_INFO_quilt-dirfind now returns a string value by setting $REPLY. Previously it printed the value to standard output. This only affects you if you override that function in your dotfiles.
The cd and chdir builtins no longer interpret operands like -1 and +2 as stack entries when POSIX_CD is enabled.
Dropping privileges with unsetopt privileged may fail (with an error
message) on some older and uncommon platforms due to library dependency
changes made in the course of fixing CVE-2019-20044. Please report this
to the zsh-workers mailing list if your system is affected. See NEWS for
more.
The gen-applied-string hook is unaffected; it still receives the patches in reverse order, from last applied to first applied.
The completion helper _remote_files, typically used after a hostname with scp-style completion, now uses remote-files instead of files as a tag. This makes it easier to restrict completions with the tag-order style.
The default build-time maximum nested function depth has been decreased from 1000 to 500 based on user experience. However, it can now be changed at run time via the variable FUNCNEST. If you previously configured the shell to set a different value, or to remove the check, this is now reflected in the default value of the variable.
The syntax
foo=([key]=value)
can be used to set elements of arrays and associative arrays. In the unlikely event that you need to set an array by matching files using a pattern that starts with a character range followed by '=', you need to quote the '=', e.g.:
foo=([aeiou]=vowel)
This is only required for array values contained within parentheses; command line expansion for normal arguments has not changed.
[[ -o foo ]]
where foo is not the name of a shell option (with optional underscores and optional "no" prefix) used to be treated as a syntax error, i.e., the enclosing command line or file were aborted. It now emits a warning and returns a non-zero exit code. For further details, see the documentation of the -o switch in the chapter "Conditional Expressions" in the zshmisc(1) manual.
alias foo='noglob foo' foo() { print function body; }
When this is encountered in a start-up file, or other place where input was read line by line, "foo" is in command position and is expanded as an alias before the function definition takes place. In previous versions of the shell, this caused two functions "noglob" and "foo" to be defined. Any expansion of an alias in a function definition is nearly always an unintended effect, as well as hard to detect, so has been made an error. (The option setting NO_MULTI_FUNC_DEF turned this case into an error, but did not help with other cases and is off by default.) The alternative, of not expanding the alias, was rejected as it was more difficult to achieve in the parser and also would silently change the shell's behaviur between versions. A new option, ALIAS_FUNC_DEF, has been added, which can be set to make the shell behave as in previous versions. It is in any case recommended to use the "function" keyword, as aliases are not expanded afterwards.
It was an undocumented, and largely useless, feature that a function
autoloaded with an absolute path was searched for along the normal fpath
(as if the leading / was missing) and, if found, loaded under the full
name including the leading slash. This has been replaced with the more
useful feature that the function is searched for only at the given
absolute path; the name of the function is the base name of the file.
Note that functions including a non-leading / behave as before,
e.g. if dir/name' is found anywhere under a directory in $fpath it is loaded as a function named dir/name'.
vcs_info: When neither a set-patch-format nor a gen-applied-string (resp. gen-unapplied-string) hook is set, vcs_info now '%'-escapes the applied-string (resp. unapplied-string) before interpolating it into the patch-format string, to prevent literal `%' signs in the interpolated value from being interpreted as prompt escape sequences. If you use ${vcs_info_msg_0_} in a context other than the shell prompt, you may need to undo the escaping with:
print -v vcs_info_msg_0_ -Pr -- "${vcs_info_msg_0_}"
This is also needed if $vcs_info_msg_0_ is used to set $psvar.
functions executed by ZLE widgets no longer have their standard input closed, but redirected from /dev/null instead. That still guards against user defined widgets inadvertently reading from the tty device, and addresses the antisocial behaviour of running a command with its stdin closed.
[New between 5.4.1 and 5.4.2] In previous versions of the shell, the following code:
() { setopt err_return; false; echo 'oh no' } && true
printed "oh no", as the ERR_RETURN behaviour was suppressed when a function was executed on the left hand side of an "&&" list. This was undocumented and inconvenient as it is generally more useful to consider execution within a function in isolation from its environment. The shell now returns from the function on executing `false'. (This is general to all functions; an anonymous function is shown here for compactness.)
[[ $a = ['a-z'] ]]
matches if the variable a contains just one of the characters "a", "-" or "z" only. Previously this would have matched any lower case ASCII letter. Note therefore the useful fact that
[[ $a = ["$cset"] ]]
matches any character contained in the variable "cset". A consequence of this change is that variables that should have active ranges need (with default zsh options) to be indicated explicitly, e.g.
cset="a-z" [[ b = [${~cset}] ]]
The "" causes the "-" character to be active. In sh emulation the
"" is unnecessary in this example and double quotes must be used to
suppress the range behaviour of the "-".
The first argument to 'repeat' is now evaluated as an arithmetic expression. It was always documented to be an arithmetic expression, but until now the decimal integer at the start of the value was used and the remainder of the value discarded. This could lead to different behaviour if the argument contains non-numeric characters, or if the argument has leading zeroes and the OCTAL_ZEROES option is set.
For some time the shell has had a POSIX_TRAPS option which determines whether the EXIT trap has POSIX behaviour (the trap is only run at shell exit) or traditional zsh behaviour (the trap is run once and discarded when the enclosing function or shell exits, whichever happens first). The use of this option has now been made "sticky" on the EXIT trap --- in other words, the setting of the option at the point where the trap is set now determines whether the trap has POSIX or traditional zsh behaviour. This means that changing the option after the trap was set no longer has any effect.
Other aspects of EXIT trap handling have not changed --- there is still only one EXIT trap at any point in a programme, so it is not generally useful to combine POSIX and non-POSIX behaviour in the same script.
There was an undocumented feature dating from the early days of zsh that glob qualifiers consisting only of the digits 0 to 7 were treated as an octal file mode to "and" with the modes of files being tested. This has been removed in order to be more sensitive to syntax errors. The "f" qualifier has for many years been the documented way of testing file modes; it allows the "and" test ("(f+1)" is the documented equivalent of "(1)") as well as many other forms.
The completion helper function _arguments now escapes both backslashes and colons in the values of option arguments when populating the $opt_args associative array. Previously, colons were escaped with a backslash but backslashes were not themselves escaped with a backslash, which lead to ambiguity: '-x foo:bar' (one argument with a backslashed colon) and '-x foo\ bar' (two arguments, and the first one ends in a backslash) would both set $opt_args[-x] to the same value. This example assumes the -x option's spec declared two arguments, as in: _arguments : -x:foo:${action}:bar:$action
For the more common case of non-repeatable options that take a single argument, completion functions now have to unescape not only colons but also backslashes when obtaining the option's argument from $opt_args.
Previously, if the function command_not_found_handler was run in place of a command-not-found error, and the function returned non-zero status, zsh set the status to 127 and printed an error message anyway. Now, the status from the handler is retained and no additional message is printed. The main reasons for this change are that it was not possible to return a non-zero status to the parent shell from a command executed as a replacement, and the new implementation is more consistent with other shells.
The output of "typeset -p" (and synonyms) now takes into account the function scope and export state of each parameter. Exported parameters are output as "export" commands unless the parameter is also local, and other parameters not local to the scope are output with the "-g" option. Previously, only "typeset" commands were output, never using "-g".
At spelling-correction prompt ($SPROMPT), where the choices offered are [nyae], previously would be accepted to mean [N] and and would be accepted to mean [Y]. Now and are invalid choices: typing either of them remains at the prompt.
The $ary[i,j] subscript syntax to take a slice of an array behaves differently when both i and j are larger than the number of elements in the array. When i == j, such a slice always yields an empty array, and when i < j it always yields an array of one empty string element. The following example illustrates how this differs from past versions.
nargs() { print $# } a=(one two) for i in 1 2 3 4; do for j in 1 2 3 4 5; do print -n "$i $j => " nargs "${(@)a[i,j]}" done done
5.2 | 5.3 ** ----------+---------- 1 1 => 1 | 1 1 => 1 1 2 => 2 | 1 2 => 2 1 3 => 2 | 1 3 => 2 1 4 => 2 | 1 4 => 2 1 5 => 2 | 1 5 => 2 2 1 => 0 | 2 1 => 0 2 2 => 1 | 2 2 => 1 2 3 => 1 | 2 3 => 1 2 4 => 1 | 2 4 => 1 2 5 => 1 | 2 5 => 1 3 1 => 0 | 3 1 => 0 3 2 => 0 | 3 2 => 0 3 3 => 0 | 3 3 => 0 3 4 => 0 | 3 4 => 1 ** 3 5 => 0 | 3 5 => 1 ** 4 1 => 0 | 4 1 => 0 4 2 => 0 | 4 2 => 0 4 3 => 0 | 4 3 => 0 4 4 => 1 | 4 4 => 0 ** 4 5 => 1 | 4 5 => 1
The behaviour of the parameter flag (P) has changed when it appears in a nested parameter group, in order to make it more useful in such cases. A (P) in the outermost parameter group behaves as before. See NEWS for more.
The default behaviour when text is pasted into an X Windows terminal has changed significantly (unless you are using a very old terminal emulator that doesn't support this mode). Now, the new "bracketed paste mode" treats all the pasted text as literal characters. This means, in particular, that a newline is simply inserted as a visible newline; you need to hit Return on the keyboard to execute the pasted text in one go. See the description of zle_bracketed_paste in the zshparams manual for more. "unset zle_bracketed_paste" restores the previous behaviour.
As noted in NEWS, the builtins declare, export, float, integer, local, readonly and typeset now have corresponding reserved words that provide true assignment semantics instead of an approximation by means of normal command line arguments. It is hoped that this additional consistency provides a more natural interface. However, compatibility with older versions of zsh can be obtained by turning off the reserved word interface, exposing the builtin interface:
disable -r declare export float integer local readonly typeset
This is also necessary in the unusual eventuality that the builtins are to be overridden by shell functions, since reserved words take precedence over functions.
array=([index]=value)
can be used with both assoiative arrays and normal arrays. In the unlikely event that you wish to create an array with an entry matching a file whose name consists of one of a range of characters matched as a [...] expression, followed by an equal sign, followed by arbitrary other characters, it is now necessary to quote the equals sign.
Various arithmetic operations have changed, in particular with respect to the choice of integer or floating point operations. The new behaviour is intended to be more consistent, but is not compatible with the old.
Old behaviour:
% print $(( 5.5 % 2 )) 1
New behaviour:
% print $(( 5.5 % 2 )) 1.5
Old behaviour:
% integer var % print $(( var = 5.5 / 2.0 )) 2.75 % print $var 2
New behaviour:
% integer var % print $(( var = 5.5 / 2.0 )) 2 % print $var 2
Old behaviour:
% unsetopt FORCE_FLOAT % print $(( 1 / 2 )) 0 % integer i=1 j=2 % print $(( i / j )) 0 % setopt FORCE_FLOAT % print $(( 1 / 2 )) 0.5 % print $(( i / j )) 0
New behaviour:
% unsetopt FORCE_FLOAT % print $(( 1 / 2 )) 0 % integer i=1 j=2 % print $(( i / j )) 0 % setopt FORCE_FLOAT % print $(( 1 / 2 )) 0.5 % print $(( i / j )) 0.5
The "zshaddhistory" hook mechanism documented in the zshmisc manual page has been upgraded so that a hook returning status 2 causes a history line to be saved on the internal history list but not written to the history file. Previously any non-zero status return would cause the line not to be saved on the history at all. It is recommended to use status 1 for this (indeed most shell users would naturally do so).
In 5.0.0, the new "sticky" emulation feature was applied to functions explicitly declared within an expression following `emulate ... -c', but did not apply to functions marked for autoload in that expression. This was not documented and experience suggests it was inconvenient, so in 5.0.2 autoloads also have the sticky property.
In other words,
emulate zsh -c 'func() { ... }'
behaves the same way in 5.0.0 and 5.0.2, with the function func always being run in native zsh emulation regardless of the current option settings. However,
emulate zsh -c 'autoload -Uz func'
behaves differently: in 5.0.0, func was loaded with the options in effect at the point where it was first run, and subsequently run with whatever options were in effect at that point; in 5.0.2, func is loaded with native zsh emulation options and run with those same options. This is now the recommended way of ensuring a function is loaded and run with a consistent set of options.
Note that the command `autoload -z' has never affected the options applied when the function is loaded or run, only the effect of the KSH_AUTOLOAD option at the point the function is loaded.
Here are some incompatibilities in the shell since the 4.2 series of releases. It is hoped most users will not be adversely affected by these.
In previous releases of the shell, builtin commands and precommand modifiers that did not accept options also did not recognize the argument "--" as marking the end of option processing without being considered an argument. This was not documented and was incompatible with other shells. All such commands now handle this syntax.
The configuration option --enable-lfs to enable large file support has been replaced by autoconf's standard --enable-largefile mechanism. As this is usually used whenever necessary, this won't usually be noticeable; however, anyone configuring with --disable-lfs should configure with --disable-largefile instead.
The configuration option --with-curses-terminfo has been replaced by the option --with-term-lib="LIBS" where LIBS is a space-separated list of libraries to search for termcap and curses features.
The option SH_WORD_SPLIT, used in Bourne/Korn/Posix shell compatibility mode, has been made more like other shells in the case of substitutions of the form ${1+"$@"} (a common trick used to work around problems in older Bourne shells) or any of the related forms with the + replaced by - or = with an optional colon preceding. Previously, with SH_WORD_SPLIT in effect, this expression would cause splitting on all white space in the shell arguments. (This was always regarded as a bug but was long-standing behaviour.) Now it is treated identically to "$@". The same change applies to expressions with forced splitting such as ${=1+"$@"}, but otherwise the case where SH_WORD_SPLIT is not set is unaffected.
Debug traps (`trap ... DEBUG' or the function TRAPDEBUG) now run by default before the command to which they refer instead of after. This is almost always the right behaviour for the inten
Content type
Image
Digest
Size
29.8 MB
Last updated
about 6 years ago
docker pull zshreds/zsh