update the following features to use the monotonic clock for calculating time
deltas and intervals:
* MAILCHECK parameter
* PERIOD parameter
* SECONDS parameter
* %(nS.t.f) prompt-expansion sequence
* time built-in's elapsed time and cpu % values
* zsh/zftp ZFTP_TMOUT parameter
* zsh/zprof timings
also use CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC on macOS
This is a special case where TRAPEXIT is unset within a TRAPEXIT
as it should never run in a nested context, so just save the
function structure temporarily on the heap.
Backs out part of 188c5cd5 (workers/50874). With this change, after a
new subshell is forked upon suspend of the right side of a pipeline, the
previous foreground subjob is resumed first and the new subshell remains
stopped until that job finishes.
inittyptab() must be called when returning from a function with
"setopt localoptions MULTIBYTE|BANGHIST|SHSTDIN", and also in
function dosetopt() when setting these options (via $options, for
example). We intentionally did not take account of the options
EMACS/VI because these options are obsolete and their use is
not recommended.
Don't attempt to query invalid job off end of table, resulting in
crashes from $jobtstates.
If background task started in subshell, look at tatsks within subshell
instead of main shell. Document and add test.
If the file was sourced from an interactive shell with
INTERACTIVE_COMMENTS not set, comments were not parsed.
Note there is a remaining edge case where the sourced
file is in fact entered at the comment line.
zsh typically runs the final command in a pipeline in the main shell
instead of a subshell. However, POSIX specifies that all commands in a
pipeline run in a subshell, but permits zsh's behavior as an extension.
The default /bin/sh implementations on various Linux distros and the
BSDs always use a subshell for all components of a pipeline.
Since zsh may be used as /bin/sh in some cases (such as macOS Catalina),
it makes sense to have the common sh behavior when emulating sh, so do
that by checking for being the final item of a multi-item pipeline and
creating a subshell in that case.
From the comment above execpline(), we know the following:
last1 is a flag that this command is the last command in a shell that
is about to exit, so we can exec instead of forking. It gets passed
all the way down to execcmd() which actually makes the decision. A 0
is always passed if the command is not the last in the pipeline. […]
If last1 is zero but the command is at the end of a pipeline, we pass
2 down to execcmd().
So there are three cases to consider in this code:
• last1 is 0, which means we are not at the end of a pipeline, in which
case we should not change behavior.
• last1 is 1, which means we are effectively running in a subshell,
because nothing that happens due to the exec is going to affect the
actual shell, since it will have been replaced. So there is nothing
to do here.
• last1 is 2, which means our command is at the end of the pipeline, so
in sh mode we should create a subshell by forking.
input is nonzero if the input to this process is a pipe that we've
opened. At the end of a multi-stage pipeline, it will necessarily be
nonzero.
Note that several of the tests may appear bizarre, since most developers
do not place useless variable assignments directly at the end of a
pipeline. However, as the function tests demonstrate, there are cases
where assignments may occur when a shell function is used at the end of
a command. The remaining assignment tests simply test additional cases,
such as the use of local, that would otherwise be untested.
