POSIX requires that the output of the "set" command (with no args -- it
gives a list of variables, and their values) be sorted according to
the collating sequence defined by the current locale.
Now I'm not aware of any locale where the collating sequence order of
ascii letters, digits, and '_' are any different than they are in the
C locale (and those are the only characters that can occur in variable
names - unless there is perhaps a locale that defines "dictionary" order
as the sort order) but never mind, that isn't the bug...
What "collating sequence order" does mean however, if not "collating
sequence order, except when we happen to have two variable names, where
one name is a prefix of the other (say X and XY) and the first character
of the 'Y' part of the longer name happens to be a digit..."
"set" is not a frequently used command (particularly in scripts where
it matters - that is, the no args form, nothing here alters anything
about any use of set with args) and is already a bit slow (sluggish...)
because of the sort requirement, so let's make it fractionally even
slower, but correct.
Since day0 pt_exec.c shipped with a dummy stub for "exec" operation, stop
waiting longer and eliminate it now. This functionality can be achieved
with filters.
Drop FreeBSD CVS repos references. There are certainly still some mirrors
or old mirrors available, but since the project moved to SVN+GIT entirely
drop it.
Add CVS Id - where missing - to the documentation files. This helps users
to determine how recent are the files.
This as discussed on current-users in the thread
entitled:
Proposal: new libc/libutil functions to map SIGXXXX <-> "XXXX"
that can be found (starting at):
http://mail-index.netbsd.org/current-users/2017/04/28/msg031600.html
These functions provide the mechanism to enable applications
to divorce themselves from internal details of the signal
implementation.
Libc minor bumped, prototypes in <signal.h>, sets lists updated (and sorted).
One and all: feel free to improve the sources & man page (etc), but
please do not change the function signatures without discussion.
! ! pipeline
(And for now the other places where ! is permitted)
we should at least generate the logically correct exit
status:
! ! (exit 5); echo $?
should print 1, not 5. ksh and bosh do it this way - and it makes sense.
bash and the FreeBSD sh echo "5" (as did we until now.)
dash, zsh, yash all enforce the standard syntax, and prohibit this.
by FreeBSD sh (though different, for other reasons) - but the bug discovered
while searching for why a (nonsense) attempted test of the forthcoming
code to handle "! ! pipeline" properly wasn't working... (it was how I was
testing it that was broken, but until I achieved enlightenment, I was bug
hunting, and found this...)
Most likely the bugs here wouldn't have affected any real code (no bug
reports anyway), but ...
This isn't a functional difference because huge + x > one is
always true for a small x, and is probably a magical incantation
to raise inexact if x != 0
Found by GCC 8.0
