Formerly, return always returned from a function if it was called from a
function, even if there was a closer dot script. This was for compatibility
with the Bourne shell which only allowed returning from functions.
Other modern shells and POSIX return from the function or the dot script,
whichever is closest.
Git 1.8.4's rebase --continue depends on the POSIX behaviour.
Reported by: Christoph Mallon, avg
As per POSIX, a simple command must have at least one redirection,
assignment word or command word.
These occured in rare cases such as eval "f()" .
The extension of allowing no commands inside { }, if, while, for, etc.
remains.
POSIX does not require ++ and -- in arithmetic. It is probably more useful
to reject them than to treat ++x and --x as x silently.
Note that the behaviour of increment and decrement can be obtained via
(x+=1), ((x+=1)-1), (x-=1) and ((x-=1)+1).
PR: bin/176444
Although using -i with -c does not seem very useful, it seems inappropriate
to read commands from the terminal in this case.
Side effect: if the -s -c extension is used and the -s option is turned off
using 'set +s' during the interactive part, the shell now exits after an
error or interrupt. Note that POSIX only specifies -s as option to sh, not
to set.
See also Austin Group issue #718.
This is required by POSIX, at least for pids that are not known child
processes.
Other problems with job specifications still cause wait to abort with
exit status 2.
PR: 176916
This is only part of the PR; the behaviour for unknown/invalid pids/jobs
remains unchanged (aborts the builtin with status 2).
PR: 176916
Submitted by: Vadim Goncharov
This reverts commit r247274.
As maintainer of sh, I disapprove of this feature addition.
It is too specific and can be done without easily using find(1) or stat(1).
I will add some hints to the test(1) man page shortly.
In general, FreeBSD sh is not the place to invent new shell language
features. This is how it has been maintained and adding features randomly
does not work with that.
The new syntax (e.g. [ FILE1 -ntca FILE2 ]) looks cryptic to me.
In most shells (including our sh), break outside a loop does nothing with
status 0, or at least does not abort. Therefore, scripts sometimes (buggily)
depend on this.
This test case sometimes fails because of an EINTR-related race condition.
Fixing this race condition likely requires an extra system call per byte,
which would make the read builtin even slower than it already is, or very
complicated trickery. Therefore, remove the test case for now.
* If read -t times out, return status as if interrupted by SIGALRM
(formerly 1).
* If a trapped signal interrupts read, return status 128+sig (formerly 1).
* If [EINTR] occurs but there is no trap, retry the read (for example
because of a SIGWINCH in interactive mode).
* If a read error occurs, write an error message and return status 2.
As before, a variable assignment error returns 2 and discards the remaining
data read.
If syntactically invalid job identifiers are to be taken as jobs that exited
with status 127, this should not apply to options, so that we can add
options later if need be.
This ensures 'return' in a trap returns the correct status to the caller.
If evalskip is not set or if it is overridden by a previous evalskip, keep
the old behaviour of restoring the exit status from before the trap.
access, birth, change and modify times of two files, instead of only
being able to compare modify times. The builtin test in sh(1) will
automagically acquire the same expansion.
Approved by: grog
MFC after: 2 weeks
If there is a write error on stdout, a message will be printed (to stderr)
and the exit status will be changed to 2 if it would have been 0 or 1.
PR: bin/158206
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.
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.
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.
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
