| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
If "if" had a hard error in the condition, and there was no
else clause, the command status was incorrectly cleared to zero.
Add test.
|
|
See 48613
|
|
See 48613
|
|
|
|
|
|
|
|
|
|
catch errors.
|
|
|
|
get-revision is set and check-for-changes is not
Tweak: Simplify an always-true condition.
Review-by: Manuel Jacob
|
|
|
|
omission in the documentation and add an example.
The example code is a reduced version of my function from workers/47519,
with one bug fixed. (In workers/47519, if $1 doesn't contain spaces -
which is the case under hg mq - then $H and $s will be set to the same
value.)
Tweaked: Extended the contrib.yo hunk with details about mq.
|
|
|
|
that would fail
|
|
|
|
|
|
…and hide mutually exclusive options.
|
|
opusdec & opusinfo)
|
|
|
|
|
|
|
|
Changes typeset such that ${newparam-notset} yields "notset" and
"typeset -p newparam" does not show an assignment to the parameter. This
is similar to the default behavior of bash and ksh, with minor differences
in typeset output.
Also add tests for some POSIX incompatibilities plus minor changes for test
harness robustness.
|
|
This was fixed by commit b6ba74c
|
|
_arguments.
In the penultimate paragraph of the comment, the two possibilities for the
relative path cover three cases:
- The comment is read in the source tree
- The comment is read in an installed tree with --enable-function-subdirs
- The comment is read in an installed tree with --disable-function-subdirs
Review-by: Matthew Martin
Review-by: Oliver Kiddle
|
|
|
|
|
|
|
|
|
|
For future greppers, here's the correct information:
e1f5172a4 48574/0008: vcs_info git: Use best practices in an example
2144d0110 48574/0007: vcs_info docs: vcs_info_lastmsg: Correct an ambiguous/wrong description.
517e1777a 48574/0006: vcs_info docs: Change user-context name in an example, to avoid confusion with the special-casing of the value `command' in vcs_info_lastmsg.
ebcb20a9c 48574/0005: vcs_info docs: Recommend use of prompt expandos rather than terminal escape sequences.
cc833e01f 48574/0004: docs: Document that hook functions may rely on $? (see workers/48570).
9b5f80285 48574/0003: docs: Fix rendering in the man page output
d07c945e7 48574/0002 (tweaked): docs: Fix rendering of an example in the man page output
32336eab9 48574/0001: docs: Minor markup tweak
|
|
The alias was vulnerable to SHORT_LOOPS syntax, not invokable from
scripts, etc..
|
|
description.
|
|
confusion with the special-casing of the value `command' in vcs_info_lastmsg.
|
|
terminal escape sequences.
|
|
workers/48570).
|
|
In the man page output, the text was underlined from the var()
to the end of the paragraph.
The texi output in affected. For instance, the text `name' in TeX
is now slanted Roman (\slshape\rmfamily) rather than slanted teletype
(\slshape\ttfamily).
|
|
The texi output was unaffected. However, in the man page on my system,
everything after the example() was underlined and not indented.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
