Examples:
export x=~
now expands the tilde
local y=$1
is now safe, even if $1 contains IFS characters or metacharacters.
For a word to "look like an assignment", it must start with a name followed
by an equals sign, none of which may be quoted.
The special treatment applies when the first word (potentially after
"command") is "export", "readonly" or "local". There may be quoting
characters but no expansions. If "local" is overridden with a function there
is no special treatment ("export" and "readonly" cannot be overridden with a
function).
If things like
local arr=(1 2 3)
are ever allowed in the future, they cannot call a "local" function. This
would either be a run-time error or it would call the builtin.
This matches Austin Group bug #351, planned for the next issue of POSIX.1.
PR: bin/166771
It is planned to expand variable assignments as assignments (no word
splitting, different tilde expansion) when they follow a "declaration
utility" (export, readonly or local). However, a quoted character cannot be
part of a "name" so things like \v=~ are not assignments, and the existing
behaviour applies.
not updated as part of `make installworld' such as files in /etc. It
manages updates by doing a three-way merge of changes made to these files
against the local versions. It is also designed to minimize the amount
of user intervention with the goal of simplifying upgrades for clusters
of machines.
The primary difference from mergemaster is that etcupdate requires less
manual work. The primary difference from etcmerge is that etcupdate
updates files in-place similar to mergemaster rather than building a
separate /etc tree.
Requested by: obrien, kib, theraven, joeld (among others)
to build FreeBSD (they are used in Perl man pages). We never needed embedded
"!" in targets that I can find.
We got this from OpenBSD and I cannot find any other make that supports
such things -- contrary to their commit message claim: "This behaviour
is also consistent with other versions of make.".
test.
POSIX says that SIGPIPE affects a process and therefore a SIGPIPE caused and
received by a subshell environment may or may not affect the parent shell
environment.
The change assumes that ${SH} is executed in a new process. This must be the
case if it contains a slash and everyone appears to do so anyway even though
POSIX might permit otherwise.
This change makes builtins/wait3.0 work in ksh93.
bison, keeping full compatibility with our previous yacc implementation.
Also bring the ability to create reentrant parser
This fix bin/140309 [1]
PR: bin/140309 [1]
Submitted by: Philippe Pepiot <ksh@philpep.org> [1]
Approved by: des (mentor)
MFC after: 1 month
Check that the expected domain(9) families all handle the socket option
correctly and do proper bounds checks. This would catch bugs as fixed
in (r230938,)r230981.
Sponsored by: Cisco Systems, Inc.
In the first command of a 'for', $? should be the exit status of the last
pipeline (command substitution in the word list or command before 'for'),
not always 0.
expressions properly. Some of the tests depend on the compiler
implementing C99's FENV_ACCESS pragma, and only commercial compilers
do; those tests are currently skipped. If any of the enabled tests
fail, then odds are the libm regression tests will fail also.
This should make it easier to diagnose reported problems on platforms
I don't have.
Currently, gcc passes all the tests that don't depend on FENV_ACCESS
on amd64 and sparc64. Clang fails a few on amd64 (see clang bug
11406). Both gcc and clang fare poorly on i386, which has well-known
issues.
Before this fix, only the first statement of the trap was executed if
evalskip was set. This is for example the case when:
o "-e" is set for this shell
o a trap is set on EXIT
o a function returns 1 and causes the script to abort
Reviewed by: jilles
MFC after: 2 weeks
Also, rework evalcase() to not evaluate any tree. Instead, return the
NCLISTFALLTHRU node and handle it in evaltree().
Fixed bugs:
* If a ;& list with non-zero exit status is followed by an empty ;; or final
list, the exit status of the case command should be equal to the exit
status of the ;& list, not 0.
* An empty ;& case should not reset $?.
* If no pattern is matched, POSIX says the exit status shall be 0 (even if
there are command substitutions).
* If a pattern is matched and there are no command substitutions, the first
command should see the $? from before the case command, not always 0.
The errno message display added in r222292 did not take attempting to
cd to a non-directory or something that cannot be stat()ed into account.
PR: bin/164070
MFC after: 10 days
These files contained various combinations of Big5, eucJP and KOI8-U
encoded strings. The byte representations of their respective encodings
have been translated to $'...' escape sequences as understood by our sh(1).
With help from: jilles
