Utilities option. Its value is printed at the beginning of the line if tracing
(-x) is active. PS4 defaults to the string "+ " which is compatible with the
old behaviour to always print "+ ".
We still need to expand variables in PS1, PS2 and PS4.
PR: 46441 (part of)
Submitted by: schweikh
Obtained from: NetBSD
demanded by POSIX.
- A redirection error is only fatal (meaning the execution of a shell script is
terminated) for special built-ins. Previously it was fatal for all shell
builtins, causing problems like the one reported in PR 88845.
- Variable assignments remain in effect for special built-ins.
- Option or operand errors are only fatal for special built-ins.
This change also makes errors from 'fc' non-fatal (I could not find any reasons
for this behaviour).
Somewhat independently from the above down-grade the error handling in the
shift built-in if the operand is bigger than $# from an error() call (which is
now fatal) to a return 1. I'm not sure if this should be considered a POSIX
"operand error", however this change is needed for now as we trigger that error
while building libncurses. Comparing with other shells, zsh does the same as
our sh before this change (write a diagnostic, return 1), bash behaves as our
sh after this commit (no diagnostic, return 1) and ksh93 and NetBSD's sh treat
it as a fatal error.
itself and its children. Instead of calling times() (as implied by POSIX) this
implementation directly calls getrusage() to get the times because this is more
convenient.
termination with set -e if a command fails in a loop body inside a function
with an explicitely tested exit status, eg
f() {
for i in 1 2 3; do
false
done
}
f || true
Briefly reviewed by: cracauer
two cases of unwanted termination with set -e:
* if-commands containing several commands separated by semicolons, eg
if false; false; then [...]
* functions with an explicitely tested exit status that contain a failing
command which is not the last one, eg
f() {
false
false
}
f || true
PR: 77067, 85267
Briefly reviewed by: cracauer
Joe Marcus Clarke <marcus@FreeBSD.ORG>, subshells could lose a
non-zero exit status.
This commit is Joe's proposed patch. Thanks!
I verified that the problem Joe found is fixed and I ran a full world
with this patch.
I don't plan to ever commit language patches to /bin/sh again. It is
a minefield too big to navigate without a full-time committment, which
I am not willing to do on our /bin/sh.
Under normal circumstances I would recommend using NetBSD's sh which
has a lot of language fixes (like the ones what these patches were
about) but unfortunately they had implemented broken signal behaviour
for shellscript containing interactive programs. Similar issues apply
to pdksh which is OpenBSD's sh.
From my perspective bash2 is the only really working bourne sh out
there and that one is GPLed. Oh well.
should slightly reduce the number of system calls in critical portions of
the shell, and select a more efficient path through the fdalloc code.
Reviewed by: bde
sh -e behaviour was incorrect when && and || statements where used in
"if" clauses.
This is the patch submitted by MORI Kouji <mori@tri.asanuma.co.jp>.
It fixes the issue at hand, but sh fixes like this are super-hard to
verify that they don't break anything else. I ran some of my old test
cases and a few big GNU configure scripts that detected mistakes
before, with the previous sh, patched sh and bash. No differences in
behaviour found. MFC recommended after longer than usual time.
Compiles on i386 and sledge.
shell function and alias lookup. The -p option has been implemented, the
UPE -v and -V options have not. The old `command' command has been renamed
to `builtin'.
o Old-style K&R declarations have been converted to new C89 style
o register has been removed
o prototype for main() has been removed (gcc3 makes it an error)
o int main(int argc, char *argv[]) is the preferred main definition.
o Attempt to not break style(9) conformance for declarations more than
they already are.
o Change
int
foo() {
...
to
int
foo(void)
{
...
errexit (-e) processing. This solves a problem where 'make clean' would
fail with an unspecified error in certain automake-generated makefiles.
Reviewed by: no objections from -hackers...
MFC after: 2 weeks
than two processes (got that? :-), the stdin fd of the middle
processes that has just been set up was accidetially closed. Don't do
this.
PR: bin/14527
make /etc/rc interruptible in cases when programs hang with blocked
signals) isn't standard enough.
It is now switched off by default and a new switch -T enables it.
You should update /etc/rc to the version I'm about to commit in a few
minutes to keep it interruptible.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
This patch causes too many side effects, one of which bites hard is
when interrupting a 'make fetch' in the ports tree (PR#1990).
This whole area is a real can of worms....
This most definately should go into 2.2
Reviewed by: steve, bde
merge of parallel duplicate work by Steve Price and myself. :-]
There are some changes to the build that are my fault... mkinit.c was
trying (poorly) to duplicate some of the work that make(1) is designed to
do. The Makefile hackery is my fault too, the depend list was incomplete
because of some explicit OBJS+= entries, so mkdep wasn't picking up their
source file #includes.
This closes a pile of /bin/sh PR's, but not all of them..
Submitted by: Steve Price <steve@bonsai.hiwaay.net>, peter
