No point testing if the spec file is empty before running makespec,
the previous commands guarantee that cannot be the case, so makespec
was never being run.  Just run it unconditionally.

Seems to fix the build for me.

(kre)

Use intmax_t instead of long int when trying to represent very large
integers (10^50 or so), so we don't exceed the capacity of systems where
long int is only 32 bits.

Hopefully will unbreak the i386 build, perhaps others.

(kre)

Revert previous until Christos has a chance to work out why it breaks
the builds.

(kre)

Edgar Fuß pointed out that sh(1) did not mention comments (at all).
This has been true forever, and no-one else (including me) ever seems
to have noticed this ommission.

Correct that.

While in the area, improve the general sections on the Lexical structure
of the shell's input, and including some refinements to how quoting is
described.

(kre)

Revert previous, we have no /etc/skel/.editrc (currently anyway).
This change looks to have been accidentally included in the big
sets reduction/division.

This should fix the builds.

(kre)

Correct a very minor typo (s/id/is/)

(kre)

Revert last, unbreak build.  Unless the bind Makefiles start installing
a /var/run/named file (which in general would be wrong, as most sites run
named in a chroot these days) the file is obsolete, and should not, and
does not, get generated by the build, nor should it be included in any
sets.

Ideally we'd have an "optional" flag for the sets files, to allow them
to mention files that might exist, and don't matter (and are not included
in the sets), but that's a bigger change than is needed just to fix the
builds.

(kre)

Redo the mktemp(1) part - some mktemp's (including ours) require the
XXXX's to be at the end of the name (like mk*temp(3)) so however well
it will work with mktemp implementations which allow the X's to be
anywhere in the final component of the name, it will work just as
well on them with the X's at the end.

But we don't normally need all of that mess - knowing which temp
file is which is useful only when debugging the script, and that's
(mostly) long done.  So, in normal uses now just use $(mktemp) and
allow mktemp to pick its own name - we don't need to know what it is.
Every mktemp(1) supports that mode of operation.

Bug when debugging the script (which for current purposes will be
taken to be when the -x flag is passed to the shell running it, to
trace what it does) then we will make the temp files have names we
can recognise (and in that case, also don't delete them when done).

While here, check for mktemp(1) failing, and abort if that
happens (we assume that if it fails it will write an error
message to stderr, so the script does not need to.)

As for the purpose of the script ... of course the header file
generated (or an equivalent elsewhere) could be generated and
maintained by hand, but why would anyone want to do all that
work when software can do it for us, and do it correctly without
human thought?

This also allows the options in the master list (option.list) to be
arranged in a way that is meaningful for them, unrelated to the order
the shell needs to have them in (or rearrange them to be at run time)
and have that order shuffled however is convenient.  Currently all
the posix standard options are first, then the "hybrid" options, and
finally the local ones for this shell.  Currently "pipefail" is in the
final set, but once the next posix version is published, that will
become a standard option, and get moved in the list - the shell won't
even notice as this script puts the options into shell desired order.

(kre)

Revert last, the .pic file is used elsewhere.

(kre)

Probable hack fix for current build breakage.

Make sure to build external/mit before external/mpl (as bind in mpl
needs libuv from mit) and in mit/libuv make sure to build the
static library with the new MAKESTATICLIB mechanism, as that is
what bind needs.

(kre)

For i386, if ft[sg]etprec() are to be used, ensure there's a
prototype for them in scope (so include <ieeefp.h>)

Might fix the i386 build.

(kre)

While the change in 1.51 certainly retained binary compat with
what was in 1.50 (while silencing LINT) - it was clearly not the
correct change to make.  The code used !FLAG_POUND where it
clearly meant ~FLAG_POUND ... the former is 0, so &= 0 could
be replaced by =0 changing nothing.  But that's not what it
should have been doing, other flags should not have been
removed here, just FLAG_POUND.

This problem seems to have existed since support for %#s
was first added in 2011, which kind of suggests how rarely
that format, particularly with other flags (like %#-s)
has ever been used (with no other flags, the bug would not
be noticed).

(kre)

Revert this part:

strftime %s now uses tm_gmtoff if available.  (Problem and draft
patch reported by Dag-Erling Sm淡rgrav.)

of the tzcode2924a update.  It is bogus.  The "problem" is/was a simple
misunderstanding of what strftime(%s) is intended to output.  The "fix"
breaks it.

(kre)

PR bin/57918

Redo the previous correctly, the test should be whether or not only the
bottom 32 bits are set, rather than whether any of bits 32..63 are set.
This makes no difference if u_long (or unsigned long long) is 64 bits,
it is the same test in that case, but if u_long were 128 bits there is
a notable difference (though for the particular issue observed in the PR,
it is likely to work either way).

(kre)

Add a -D option to touch, which acts like the -d option added to
chmod/chown/chgrp (probably others) in the not too far distant past,
and causes the operation to be a no-op if no actual change would be
made (avoiding updating the file's ctime for no reason).

That is, with touch, -D causes no modifying sys call to be made to
a file if that file's atime and mtime are already set to the values
that would be used.  A common case for this is when a "-r ref-file"
is also a target file for the operation.

Unfortunately -d was already taken in touch, so next best available is -D.

(kre)

Add a -R option, which is identical to -r, except that if the reference file
is a symbolic link, the times to use are taken from those of the symbolic
link itself, instead of from the file it references.  If the reference file
is not a symbolic link, -R and -r are identical.

This allows the BUGS entry in the manual page to be removed.

(kre)

Document the -d posix-datetime arg variation, to allow specifying
fractional seconds.  (Alternate ways to achieve that for the other
ways of specifying the date and time may be forthcoming in a future
update).

Also add a warning about the (still far) future likely change of
the interpretation of 2 digit years (the coming POSIX standard
contains a similar warning).

While here, clean up wording, some macro usage, etc etc etc...

(kre)

Check that mktime() (or timegm() the one time it is used) do not
alter any of the material fields of the struct tm that was handed
to it.  If any were altered, then the time string passed in was
not a valid time representation, and so should be rejected.

This one is not an invisible change, it prevents use of things like
"-t 202402300000"  (which previously would have been interpreted as
"-t 202403010000" - the day after the 29th of Feb in 2024).

I believe this is an improvement however, and in line with the
general intent that if you specify a date and time, that exact
date and time is what touch should be using.  It does mean that
specifying "60" for the seconds field is almost guaranteed to
fail on any POSIX system, as leap seconds simply don't exist
there (on a non-POSIX-conforming system that uses leap seconds,
the :60 should work, if specified with the correct date and time
at which the leap second actually occurs).

The one exception is when parsedate(3) is used, as that does not
do this check (which allows things like "-1 day" on the 1st of
a month to work).

(This is the last of this sequence of updates to touch.c, an
update to touch.1 follows).

(kre)

Properly implement the POSIX format -d option.

Previously we have hacked that using parsedate(3) - but parsedate()
returns a time_t and consequently while it "handles" fractional seconds,
all that meant (all it really can mean) is that they're ignored.

The POSIX spec expects that (at least if the filesystem supports them)
fractional seconds can be set using the -d option.

Handle that by first attempting to parse the -d arg as a posix format
date-time string (using a reasonably strict parser), and if that fails,
then fall back on parsedate(3) to parse the arg.

If the posix format parse succeeds, the result will be the same as
parsedate(3) would return for the same string - except any fractional
seconds will be handled properly.  If it fails, then nothing changes
from what we currently do.

Note the POSIX string is
YYYY-MM-DDThh:mm:ss[.frac][Z]
where YYYY is (at least) 4 digits (leading 0's are acceptable if
you really must!) all the MM DD hh mm ss fields are exactly 2
digits, T is either 'T' or ' ', '.' is either itself, or ',',
and 'frac' is one or more digits.  Z (if given) is 'Z'.  The
[.,]frac and Z fields are optional.  Specify a time in a
slight shorthand like 2024-2-8T7:44:20  and the POSIX parse
will fail, leaving parsedate() to handle that (which it should).
But any fractional seconds which were given would be ignored.

Doc update coming - note the doc will call the YYYY field CCYY
instead, that's just a convenience to make other parts of what
is there make more sense - it is still one 4 (or more) digit field.

This should be an almost invisible change.

(kre)

Sprinkle come const - but not too much of a good thing.

NFCI

(kre)

Parameterise the "if year < 69 it is 20xx and if >=69 it is 19xx" rule
to make it simpler to (eventually, many years hence) to change that rule
to be "if year is < NN it is 21xx and if >= NN it is 20xx" instead.

Avoid comparing a time_t to -1 directly, as time_t might be unsigned.
Instead define NO_TIME as ((time_t)-1) and compare with that instead.
This makes no difference at all when time_t is signed (as it is on
NetBSD).

Use "ss" rather than "SS" as the seconds indicators (in messages)
to match with hh (hours) and mm (minutes) rather than looking like
some relation to YY (year) MM (month) and DD (day).  Why this was
ever written as SS is beyond me, but it has been that way forever.
(doc update will follow).

Minor improvement to the error message if the arg to a -t option
is unable to be parsed correctly.

NMFCI (No meaningful...)

(kre)

KNF (space after keyword, and 80 column police).

NFCI

(This is the first of a series of changes to be committed
in rapid sequence).

(kre)

Notre tzdata update to 2024a

(kre)

Complete tzdata2024a update (using tzdata2024agtz) by fixing files that
the script manages to forget to handle.

(kre)

PR bin/57894

For jobs -p for a non-job-control job, avoid just printing 0 (as
there is no process group pid) and instead output what we used to,
the pid of one of the processes in the job (usually the right one!)

XXX pullup -10 (9 and earlier not affected).

(kre)

Bump libm minor rev (libm.so.0.13 -> libm.so.0.14) after addition of
all the long double functions (with actual implementations).

(kre)

Add multiple inclusion protection guard - the long double math routines
have a tendency to sometimes make that happen.

This seems to fix the sun3 build, and probably other m68k builds which
were working before the libm upgrades (it will do nothing for any that
were failing before that).

(kre)

Simply an overly complex way of saying "0 or 1" into a cleaner version.

While here add a commment about how the __i386__ magic LD80C macro
might no longer work on all other arch's as well (if someone can verify
that it still does, or can fix it so that it still works on i386, but
also works everywhere else, then please remove that XXX comment.
The issue I am (perhaps imagining) is the (uint32_t) cast.

(kre)

It seems that we need prototypes for long double math functions, even
when !__HAVE_LONG_DOUBLE -- they still exist, but just aren't...

This might unbreak several more builds.

(kre)

This set of changes seem to be sufficient to make at least the
amd64 port build again after the long double math function infusion
from yesterday.

Feel free (without consulting me, I'm just hacking about) to revert
any of this and do it a better way.

Note: this is not intended to be complete, in particular, in <math.h>
I added prototypes only for the functions that are needed for a
successful build, not all of the new ones...

(kre)

Include <sys/bootblock.h> for struct mbr_sector

(kre)

Unwrap a line which wasn't wrapped before it had an __UNCONST() added
to it, and now that that is gone again, doesn't need wrapping any more.

That line is now unaltered from what it was 3 revs ago (bit for bit).

NFC.

(kre)

Compensate for src/common/lib/libc/atomic/atomic_init_cas.c losing
the extern declaration of __libc_atomic_init() and instead using a
new one added to src/lib/libc/include/extern.h

That file is outside src/common and src/sys so is unavailable to
kernel builds, so instead make a new include file in src/common
which the kernel can read which contains the needed extern decl
for __libc_atomic_init()

This seems to fix the evbarm builds (maybe others) - but it is
all MUCH TOO UGLY to keep.  Someone please make a better fix,
even if that just means reverting rev 1.5 of
src/common/lib/libc/atomic/atomic_init_cas.c
and all of the changes here (the addition to libc/include/extern.h
should be harmless to keep).

(kre)

Now that rusage_to_rusage50() has switched from being an external
function, to a static inline, we need <resource.h> for it to work.
Not all callers provide that (and nor should they need to), so include
it here.

Should unbreak the builds.

(kre)

Remove an ancient incorrect notion which somehow survived intact for ages.
"$@" is (as it is in double quotes) not subject to field splitting.  "$@"
generates (potentially) multiple words, but field splitting has nothing
to do with it.

While here, rename the section from "White Space Splitting (Field Splitting)"
to simply be "Field Splitting" as white space is only relevant if it happens
to occur in IFS (which is the default case, but IFS can be anything, and
isn't required to contain any white space at all).

(kre)

Fix previous so <stdbool.h> isn't included with _KERNEL (etc).
Like it used to be.

(kre)

This needs <stdbool.h> - it used to come from <sys/rbtree.h> (inappropriately)
but no longer (normally).    This should unbreak the builds.

(kre)

Put back <stdbool.h> - but only when RBDEBUG is defined (the
similarly conditional rb_tree_check() prototype needs "bool").

(kre)

PR bin/57773

Fix another bug reported by Jarle Fredrik Greipsland and added
to PR bin/57773, which relates to calculating the length of a
positional parameter which contains CTL chars -- yes, this one
really is that specific, though it would also affect the special
param $0 if it were to contain CTL chars, and its length was
requested - that is fixed with the same change.  And note: $0
is not affected because it looks like a positional param (it
isn't, ${00} would be, but is always unset, ${0} isn't) all
special parame would be affected the same way, but the only one
that can ever contain a CTL char is $0 I believe.  ($@ and $*
were affected, but just because they're expanding the positional
params ... ${#@} and ${#*} are both technically unspecified
expansions - and different shells produce different results.

See the PR for the details of this one (and the previous).

Thanks for the PR.

XXX pullup to everything.

(kre)

Stop using the obsolete test(1) -o operator, use sh || instead.
Prefer sh ! over test's ! (though that one is not completely obsolete).

(kre)

Do away with the obsolete text(1) -a operator, use sh && instead.
Prefer sh ! operator over test's ! (less question what it means).
A few minor formatting changes.

(kre)

Clean up obsolete test(1) usage - use sh's || instead of test's obsolete -o,
and sh's && instead of test's obsolete -a.

Minor formatting cleanups, including removing unneeded \ line continuations.

The somewhat bizarre way that named_migrate() was made to work in a
subshell (which of itself is fine, and looks needed) has been made more
rational.  Because of that, the need to use local vars is no longer there,
(subshells can't affect the parent) and "local" in that func could be deleted
(but hasn't been).

(kre)

Clean up obsolere test(1) -a option/operator - use sh && instead.
Take the opportunity to do a little sh formatting cleanups, the \
line continuation can ususually be avoided by placing sh operators at
the appropriate places.

Note the [ x"$var" = x"$other" ] usage no longer needs the 'x',
avoiding that kind of nonsense is partly why test was much more
precisely specified, and a lot of the unnecessary stuff made obsolete.
Those however I did not remove (they're harmless).

(kre)

Clean up obsolete test(1) usage, use sh && rather than test's old -a
(and while here prefer sh's ! operator over test's - it simplifies
things for test).

(kre)

Clean up obsolete test(1) usage - don't use -o, use sh || instead.

This one was particularly bad:

if [ -z ${dev} -o ${junk} ]; then

was supposed to be validating an entry read from a config file,
dev should be not empty, and junk should be empty (ie: correct
number of fields present).  If that test succeeds, the line is
bad, and we error out.

But if dev was empty, and junk was also empty, that turned into

if [ -z -o ]; then

which tests if "-o" is the empty string, which it isn't, so instead
of succeeding, and considering the entry invalid (no dev specified)
the code would just carry on as if all was good.

Because of this, a bunch of quoting fixes were also made (there might
perhaps be more needed).

(kre)

Don't use obsolete test(1) -a option/operator - use sh && instead.

(kre)

Whitespace:  8 spaces -> tab

(kre)

No longer use obsolete test(1) -a option/operator, use sh && instead.

While here a couple of minor formatting improvements - in general it
is always a good idea to surround sh operator chars (like '>' '(' ...)
with white space, to guard against thet possibility that some other (or
later enhanced) sh might have additional operators which happen to be
the character string used.

I don't understand while the final part of the condition for not doing
anything needs to run in a subshell, but that can stay for now.

(kre)

No longer use obsolete test "-a" option - use sh && instead.

(kre)

PR bin/57773

Fix a bug reported by Jarle Fredrik Greipsland in PR bin/57773,
where a substring expansion where the substring to be removed from
a variable expansion is itself a var expansion where the value
contains one (or more) of sh's CTLxxx chars - the pattern had
CTLESC inserted, the string to be matched against did not.  Fail.
We fix that by always inserting CTLESC in var assign expansions.
See the PR for all the gory details.

Thanks for the PR.

XXX pullup to everything.

(kre)

Correct a bizarre piece of source formatting that crept in by
accident several years ago (change a space into newline tab).

NFC

(kre)

Note update of tzdata to 2023d (2023dgtz).

(kre)

Merge tzdata2023d

(kre)

Correctly compute the "Filesystem" column with when using -W
(that added "NAME=" occupies space!)

XXX pullup -10

(kre)

Fix yet another wording (editing) botch noticed by uwe@

(kre)

Fix a couple of (not very likely) memory leaks, reported by enh@google.com
who attributed them:

  the malloc one was reported to Android (as
  https://android-review.googlesource.com/c/platform/bionic/+/2856549)
  by wuhaitao3 <wuhaitao3@xiaomi.corp-partner.google.com>; Chris Ferris
  <cferris@google.com> then spotted the goto nospc one.

(kre)

Fix a wording botch noticed by uwe@ (and one more smaller one), and
a few more markup issues.  While here, consistemntly use minus when
minus is meant, rather that just using a hyphen.

(kre)

A couple more (relatively minor) markup fixes.

(kre)

More markup fixes.    This man page remains exceedingly ugly (particularly
relating to vertical space - which often is missing where it would be
better if it weren't, or is present and wasteful/ugly).

(kre)

Work around a probably gcc12 bug in detecting "potentially clobbered"
variables after longjmp() for some architectures (sh3 at least).

This should allow the workaround to disable those warnings for this
file to be removed.

In the affected function the extra var & assignment added should simply
be deleted by any good optimiser, but if not, it doesn't matter, as
performance of this function (expandonstack()) is almost irrelevant.

(kre)

If the read builtin is told to read into IFS, we must avoid doing
that until all current uses of IFS are complete (as we have IFS's
value cached in ifs - if IFS alters, ifs might point anywhere).
Handle this by deferring assignments to IFS until everything is done.
This makes us appear to comply with the (currently) proposed requirement
for read by POSIX that field splitting complete before vars are
assigned.  (Other shells, like dash, ksh93, yash, bosh behave like this)

That might end up being unspecified though, as other shells (bosh,
mksh) assign each field to its var as it is delimited (though bosh
appears to have bugs).  If we wanted to go that route, the issue here
could have been handled by re-doing the init of ifs after every
setvar() that is performed here (except the last, after which it is
no longer needed).

XXX pullup -10

(kre)

When extracting the attributes (to printable form), avoid simply ignoring
any attribute bits which are unknown, print them as a hex value.  This
avoids "Attributes: " for most windows filesystem types, which all seem
to have but 63 set (which is supposed to mean "don't assign a drive letter"
which is akin to "noauto" in fstab - except it is set even on partitions
which do get mounted, so must mean something subtly different).

These upper 16 attribute bits are supposed to be file system type speficic
(in practice, they seem to be common to all filesystem types from one vendor)
but we don't have the info (yet anyway) to treat them like that.

ChromeOS seems to treat some of the bits as bit fields containing numeric
values - add #if 0'd (but compile tested) code to deal with those (maybe,
compile tested - but not execution tested) should someone ever get an
environment where these things occur, and could add the missing definitions
to actually test this.

(kre)

Recognise Windows Recovery partitions.

(kre)

Add the GUID for Microsoft Recovery partitions.

(kre)

Perform quoting of variable expansions, etc correctly.  That includes
(some) removing of quotes from where they're useless (superstition).

This should be NFC for these tests, as the data being quoted doesn't
happen to require it, but depending upon the data not altering, or the
code not being copied to a different environment is unwise, when it is
so easy to simply do it correctly.

A few line wrapping and white space changes as well.

Nothing changed here is intended to alter the way that the tests run,
or results generated.

(kre)

At the request of bad@ enhance the synopsis of the set built-in
command to include explicit mention of the -o opt and +o opt forms.

Fix the synopsis to have the 4 forms that the description of the
utility discusses, rather than expecting users to understand that
the 3rd and 4th forms of the command were combined into the 3rd
synopsis format.  After doing that, the options in the 3rd format
no longer need to be optional, so now all 4 formats are distinct
(previously, the third, omitting everything that was optional, and
the first, could not be distinguished).

While here, some wording and formatting "improvements" as well (nothing
too serious).

(kre)

Avoid comparing signed and unsigned values (using signed here seems
safer than the usual unsigned when this happens).  Might fix build.

(kre)

Revert previous, I missed an update...

(kre)

lua is currently building liblua.so.6.0 not ...6.1

(kre)

pathadj() is required to succeed.  If it cannot, simply issuing a
warning and continuing is not good enough.  Change the warning to
an error (and hence immediate exit) instead, that's all we can do.

Problem pointed out by tlaronde@polynum.com

XXX - pullup -10 (others?)

(kre)

If it isn't possible to determine the realpath() of ".", then simply
give up on attempting to resolve any relative path - there's no hope.

(kre)

When using -H, make the appearance of the worm head depend upon the body
(more than it did before).

(kre)

Fix building the debugging tarball of the directory tree created for
the pathname matching tests ... this is not used in any way in a normal
test run, but if there are problems, one needs a mechanism to discover
whether the issue is with the code that creates the directory tree in the
test, or with the matching (either what the test expects to happen, or
what the shell actually does).  The couple of lines being fixed here make
that mechanism work --- I have had this in my private sources for years
now, but never got around to committing it.  It is time.  NFC for any
normal test run.

(kre)

If chown and chgrp can grow -d flags to suppress performing the
operation when it will have no effect (other than changing the
inode's ctime value) then chmod and chflags should also have -d
flags for the same purpose.  Make it so.

(kre)

Fix builds (hopefully) when DTRACE hooks are not included.

(kre)

Add a little optional colour, optionally distinguish worm heads,
and optionally randomise worm lengths.  Just exit instead of
continuing with a nonsense display if the window shrinks (and
for consistency if it grows).

Most of the ideas and code from RVP.  Bugs and man page mangling
from me.

(kre)

Us daemons don't need no unions - just wait, the easy way.

(kre)

Another err message typo!  (found this one myself!!)

(kre)

Typo in an error message (pointed out by RVP; Thanks)

(kre)

Correct some unfortunate behaviour in extreme cases pointed out by RVP.
(Very long worms in a smallish window could result in the max number of
worms being 0...)

While here (also suggested by RVP) seed the random number generator,
also add a -S option to set the seed (note: while this is documented
in the updated man page, it does not appear in the usage message in
case of an error ... not likely to be used often enough to include there).

Also some minor improvements suggested by RVP:
delete the prototype for main()
exit curses mode before abort() (which should not happen, but...)
no need to return (->exit) after abort() as modern abort() can
never return.

In addition, check for extraneous (ignored) (non-option) args.
Check for absurdly small or big screens (the worm placement algorithm
doesn't work well for lines of columns < 3, and the abort() mentioned
above actually happens if one of those is == 1).

More flavours of worms added.

Some minor man page wording improvements.

(kre)

When worms default delay was changed from 0, to 20ms (Oct 2020)
it lost the ability to run flat out (no sleeps) - which while not
very useful for actually observing the behaviour of various Nematoda,
can be useful when 'worms' is being used to generate cpu heat - it
turns out to be a simple tool to make all of the app itself, the
xterm it runs in (when running under X) and the X server, all more
or less continuously busy - a trivial perpetual CPU load generator.

Changing that was not a simple matter of just allowing -d 0..1000
rather than -d 1..1000 which had always been the limits on -d, as
previously, simply by excluding 0, common error checking wasn't
essential.  -djunk would return 0 which was invalid, and so an error
- that it was invalid because 0 < 1, rather than because "junk" is not
a number wasn't material.

Now we need some slightly more elaborate error checking code for the
-d value, and if we're going to do that, may as well do the same for
the -l and -n options, which also take numeric values.  That is, it
will no longer be possible to say:
worms -n "5 worms"
Just the number is allowed (but -d now allows a "ms" or "us" suffix).

While here, place a reasonable upper limit (depending upon the
screen size, and worm length) upon the number of worms, so they
have somewhere to go, rather than just on top of each other.

exit(1) from the errx() rather than 0, in the case that curses
initscr() fails (doesn't seem right that it should appear as a
successful run of worms, if it never managed to start).

A couple more minor 80 column violations are handled, without
further penalty, in this update (one simply vanishes, the other
is wrapped).

Note that this sounds like a lot, but it is really all just minor
internal bookkeeping updates - the only real advertised user visible
change is the ability to use -d0 which just restores that which was
the default (though it could never be set via the option) until Oct 2020
- so really all that's happening is replacing minor functionality lost
then, while leaving the change of the default delay that that change
made, untouched.

No man page update required (that never excluded -d0).

(kre)

80 column police.

If this code were just a few chars over the limit, it might get
let off with a warning, but 214 in an 80 zone is way beyond that.

Six months loss of coding licence, and a 214000 character fine.

NFCI.

(I verified the the code was unchanged by joining the resulting
lines back into one again, and then diff'ing that line against
the original - it is identical).

(kre)

Garbage collect "char *mp" - it used to point at memory malloc()'d
to hold the termcap entry, back when worms used termcap rather than
curses, and termcap was termcap, rather that a terminfo wannabe.

This should have been removed when worms was converted to curses in
1999, but wasn't, so worms has been doing a meaningless malloc(1024)
and never using the result, ever since.

While here, since the line needed changing anyway to remove mp,
change a malloc() of a product into calloc() so it can deal with
any possible (admittedly extremely unlikely here) integer overflows.

NFCI

(kre)

PR misc/57343 (Jim Spath) - fixed a typo in atf_tc_skip message.

(kre)

Remove an end of file trailing blank line that served no purpose.

NFCI

(kre)

The great shell trailing whitespace cleanup of 2023...
Inspired by private e-mail comments from mouse@

NFCI.

(kre)

Correct the previous (change both "2023b" -> "2023c" not just one in the
dup & correct).

(kre)

tzdata updated to 2023c (2023cgtz).

(kre)

Merge tzdata2023c

(kre)

PR misc/57305 from Nan Xiao

Be consistent with method (and style) when referring to the mbufs and
ifstat sub-commands when describing what is available (and correct
"mbuf" to be "mbufs" which is what the internal command really is).

That is don't just "double quote" one and 'single quote' the other.

(kre)

PR bin/56014 from Kouichi Hashikawa

Don't try to optimise away placing the "s" or " " after "N user"
(" " where N==1, "s" otherwise) when it seems unnecessary, as that
fails when the number of users hasn't changed, but the screen is
being redrawn from nothing (as in after being resumed from a ^Z,
as in the PR, but just doing a ^L would make the same thing happen).

XXX pullup -10 (maybe -9 as well - seems too trivial for -8).

(kre)

Undo previous "restore lost break" and fix the issue that seems to
have been intending to correct properly (or at least, more rationally).

This makes adding/deleting drives for "vmstat" (and "iostat", though
the man page doesn't say that it also works there) using the :display
:ignore and :drive sub-commands work sensibly using fnmatch()
rather than what was there most of the time since it was added.

Previously ":ignore dk*" would ignore the first dk (wedge) found in
the system (whether or not it was ignored already) and that was it.
[":ignore dk* dk*" would just do that twice.]

Now the same command will ignore all dk* drives (all wedges), which
is what I would anticipate almost anyone would expect it to do.

Similarly for ":display" (to add drives) and ":drives" to explictly
list particular ones.

When the fnmatch() code was added, almost 9 and a half years ago now,
it was almost correct - except always resulted in an error occurring
(though that was little more than a minor inconvenience).

That was "fixed" 5 months later (9 years and almost a month ago now)
with the cvs log message "restore lost break" - which was absolutely
the wrong thing to do (the break was fine when no patterns were used,
and so a name could only ever match one drive - but wrong when the
whole point is to match many).

Somehow in the past 9+ years, no-one noticed that this functionality
had been rendered almost useless.

While here, fix a related problem ... just above I referred to the
error that occurred as a "minor inconvenience" - that's because while
an error would be shown on the screen, it would then immediately be
removed again, an observant user might notice the quick flash, but
that would be it.

Handle that by detecting whether any changes are actually made, and
don't go completely redrawing the screen (removing the error message
that was just placed there) if there is no point.  This doesn't
entirely fix this problem, as if we do

:drives foo wd*

and there is no "foo" drive in the system, we'd get an error message
from that, but adding the wd* drives (assuming there are some, of course)
counts as a change, so that error message will still not last very long.
The order of that command line makes no difference, it isn't that wd drives
were found after foo wasn't, but that the whole line matched (at least one)
drive (and changed its state - for the "drives" command, that is equivalent
to matched) - but also contained an entry which did not match at all.
That's a harder problem to fix.

No pullups planned, as no-one seems to mind how it has been all this time.

(kre)

After a ':' (as in login:group or just :group) insist that there
actually be a group name (of some form, don't care what) present.

(kre)

PR misc/57287 from Nan Xiao

While it has always been assumed that everyone "just knew" that a simple
"su' meant "su root" perhaps the man page really should make that explicit.

Do that (using slightly different wording than suggested in the PR).

(kre)

Actually make the only changes that actually existed in the 2023b update...

(kre)

tzdata updated from 2023a to 2023b

(kre)

Merge tzdata2023b

(kre)

More tzdata2023a updates (these are files we don't use for anything normally)

(kre)

tzdata updated to 2023a

(kre)

More merge/updates for tzdata 2023a

(kre)

Merge tzdata2023a

(kre)

Do a better job handling EACCES errors from exec() calls.  If the
EACCES is from the namei(), treat it just like ENOENT or ENOTDIR
(and if that is the final error, the exit status from a failed exec
will be 127).  If the EACCES is from the exec() itself, that indicates
the file to be run exists, but has no 'x' permission.  That's a
meaningful error (as distinct from just "yet another PATH element
search failure").

While here, return the first meaingful error we encountered while
searching PATH, rather than the last (and ENOENT if there are none
of those).

This change results in some failed command executions returning status
127 now, where they returned 126 before - which better reflects the
intent of those values (127 is simply "not found" whereas 126 is "found
but couldn't be executed").

We still do nothing to distinguish errors encountered looking up the
command name give, with errors encountered (by the kernel) attempting to
run an interpreter needed for the exec to succeed (#! line path, or
/libexec/ld.elf_so and similar - or anything else of a similar nature).

(kre)

Switch from using _setjmp()/_longjmp() (on BSD systems which aren't SVR4)
(and setjmp()/longjmp() elsewhere) to using sigsetjmp()/siglongjmp()
everywhere.

NFCI.

(kre)

Change a few #defines from octal to hex (pdp11 days are long gone).
Improve the layout of those definitions at the same time.

NFC.

(kre)

PR misc/57276 from Nan Xiao

Remove redundant word ("to").

(kre)

In bwrite() if the write() returned -1, the associated errno was
being used after a (possible) call to printf (only happens when
debugging) and a certain call to free() (via brelse()).
Make a copy, and use that instead.

(kre)

Correct a minor word usage error in a comment.  NFC.

(kre)

Use %zd to print ssize_t (%z[uxo] for size_t), rather than %jd
(just like the other adjacent printfs do)

Should fix i386 build.

(kre)

Don't inappropriately use xargs to run rcorder -- xargs is designed
to run the given command as many times as necessary, but rcorder must
be run just once, with all the rc.d scripts as args.  If that turns out
to be too many (E2BIG on exec) then we have more serious problems, working
around it by use of xargs just makes a mess (for rcorder).

Make the -e option cause the script to exit 0 if some enabled script was
found, and 1 if not, so one can do:
if service -e foobar >/dev/null
then
whatever we want to do when foobar is enabled
else
anything we want instead if it is not
fi
Someday perhaps add a -q to suppress the output instead of requiring
the redirect, but that day is not this one.  Make all error exit status
codes be >1 (and use the standard 126 instead of 255, for "exec failed").

Note that with more than one service given with -e, or when none are (so
all enabled scripts are listed) the exit status is 0 if any enabled script
was found (ie: anything was printed to stdout), not if all named scripts
exist and are enabled.  Testing the status works best with just one
script name given as an arg.

Correctly quote script names (and use eval where required) so scripts
(or paths to scripts) containing spaces, tabs, or shell operator chars
might be handled correctly (newlines in names will still cause failures.)

Treat rc.d scripts that do not have an rcvar (hence are always enabled)
as enabled scripts, rather than disabled - but ignore the LOGIN DAEMON...
pseudo-scripts.

While here, replace archaic uses of "test" ('[') (that is, -a etc) with
standard defined usages only, replace a baroque use of sed with sh code
(which is simpler and much faster, not that speed matters) - but do use sed
instead of two grep invocations.  Replace all uses of "echo" with "printf"
(just "because"!)  Make the usage more useful (explain what the various
option combinations achieve, explicitly), and also while here, make the
formatting look closer to something I can deal with (personally I prefer
tab indents almost everywhere, but 4 space is OK...)  Aligned runs of 8
spaces were all replaced by a tab.  For the options, use sh boolean cmds
(true|false), and simply run them, rather than making them be empty or set
and using test -n, it is easier to follow (and a tiny fraction of a ns faster).
Change a comment so what it says is relevant to the code that is present,
rather than to the change (referring to code that used to be present) with
which it was added.

Catch the manual page up with the minor parts of this intended to be
visible to users (like the exit status change).

(kre)

Add (newly added): expm1l log1pl log2l lgammal tgammal
so that the library gets the correct symbols defined in it.

(kre)

Adjust the tilde expansion test to deal with (very) recent changes
to what the shell produces for tilde expansions, when the expansion
of the tilde prefix ends with '/' and the character immediately following
is another '/' - previously /bin/sh (and most other shells, but not all)
retained both slashes, and this test expected that behaviour.

No longer, now only one of the two will appear.  Adjust the expected
test results accordingly, and add an extra loop iteration to make sure
this is thoroughly tested (one more tilde expansion value).

Also, add two new test cases that test for the new (explicit - though
it was always stated this way, but not as explicitly) that if HOME is
an empty string (not unset - that remains an unspecified case, as it
was) then the expansion of ~ must generate "", and not nothing.
The current test was unable to distinguish those two, since it
simply looked for characters in the output, so add a new test cases
explicitly to test for this particular case.  This also means (also
previously in the standard, but not as explicitly) that shells are
not permitted to decide "The ~ expansion produces an empty string, that
is weird, let's generate something else instead" which some shells were
doing.

(kre)

Adjust tilde expansion as will be documented in the forthcoming
version of the POSIX standard (Issue 8).  I believe we were already
compliant with what is to be required, but POSIX is now encouraging
(and will likely require in a later version) that if a tilde expansion
produces a string which ends in a '/' and the '~' that was expanded
is immediately followed by a '/' in the input word, that one of those
two slashes be omitted.  The worst (current) example of this is
when HOME=/ and we expand ~/foo - previously producing //foo which is
(in POSIX) a path with implementation defined semantics, and so not
what we should be generating by accident.  Change that, so now if
the ~ prefix expansion ends in a '/' and there is a '/' following
immediately after, the resulting word contains only one of those
chars (in the example just given, we will now produce /foo instead).

POSIX is also making it clear that the expansion that results from
the tilde expansion is treated as quoted (not subject to pathname
expansion, or field splitting, or any var/arith/command substitutions)
and that if HOME="" the expansion of ~ must generate "" (not nothing).
Our implementation did all of that already (though older versions
used to treat an empty expansion of HOME the same as if HOME was
unset - that was fixed some time ago).

The actual modification made here is probably smaller than this log entry,
and without added comments, certainly is!

(kre)

Unless -v is given, ignore EEXIST errors from the IOC_CPU_UCODE_APPLY ioctl()
used to implement "cpuctl ucode N",  which indicates that the microcode
to be loaded already exists in the CPU, and as such, isn't really a
very interesting "error".

(kre)

Fix a typo in a newly added comment.

Someone please tell me why these things become obvious only after
the code has been committed!

NFC

(kre)

When processing swapon -a (or swapctl -A, or swapctl -U) ignore lines in
fstab that have nothing to do with swapping (fs_type is neither "sw" nor "dp")
before running getfsspecname() on the fs_spec field of the line.

This avoids entries like this:

NAME=OFTEN_UNCONNECTED  /local/archived ffs    rw,log,noauto    0 0

in fstab from generating spurious error messages when the wedge named
is not currently connected to the system - that is the drive on which the
wedge exists is not connected, or not powered on.  "noauto" handles that
for some other uses, the "0"s in fs_freq and fs_passno work for other uses,
but swap{on,ctl} never look at those fields (not for this purpose).

Non "sw"/"dp" lines were being ignored anyway, but not until (a little) later.

(kre)

Allow (but do not require) the magic '--' option terminator in
the builtin 'alias' command.  This allows portability (not that
anyone should really care with aliases) for scripts from other
shells in which the alias command has options, and the -- is
required to allow the first alias name to begin with a '-'.

That is, for us, alias -x='echo x'  works fine, always has,
and still does.  But other shells treat that as an attempt
to use the -x option (and maybe -= etc), and require
alias -- -x='echo x'.  For us that variant used to complain
about the alias -- not existing (as an arg with no '=' is
treated as a request to extract the value of the alias).

Posix also generally requires all standard commands (or
which "alias" is one, unfortunately) to support '--' even
if they have no options, for precisely this reason.

(kre)

Use %zu rather than %lu to print a size_t (should fix i386 build).

But, philosophical question, shouldn't the product of two size_t
variables really be an area_t, or something like that?

(kre)

Add errc() and verrc() to the list of functions which do not return,
but exit() instead.

This was omitted when the *c() set of functions were added in 2014.

(kre)

PR lib/57141 - never decrement len without actually performing a STEP.

(kre)

More markup errors.  \+ was intended to be \&+ and .EV .Ev of course.
As best I can tell, the rest of what mandoc -Wall complains about is
incorrect (it could probably be avoided by adding more markup, but
there doesn't seem to be any point).

(kre)

Using .Cm Cm makes no sense at all - no idea what I was thinking there
(perhaps just an editing error).

(kre)

POSIX is addint this utility in Issue 8 (whenever it appears).  However
they do not specify "long" options (ever).  The --preserve and --foreground
options in this utility had no short form, so they "invented" -p and -f
so only standard form one char options needed to be specified.

Change the opt processing here so -p == --preserve and -f == --foreground
so we support the options POSIX will specify.

No other changes here, just adding those alternates for the options.

(kre)

Don't forget pci17

(kre)

This test makes (made) a false assumption about the way that
process scheduling works.  That a process (or in this case,
a thread) is no longer blocked at time T does not mean that it
will resume execution at time T.  The OS is free to devote
resources to other processes/threads instead - all we should
normally be able to expect is that if it is not unblocked before
time T, that it will not start running before then.

In general though, the pthread_cond_*wait() functions don't guarantee
even that - but for this test, the possibility of something else
randomly signalling the condvar isn't believable, so don't worry about
that possibility (but do fail without calling strerror(0) on the off
chance it does happen).

Once we cease testing that the process resumed running before some
particular time, we can stop dealing with qemu timekeeping issues,
it might (seem to) take qemu twice as long as was requested before
the thread resumes, but that's OK - the same thing could happen on
a loaded system for other reasons.

Beyond that, the test also has (had) a race condition.  When using
CLOCK_REALTIME though that clock needed to have advanced to T before
the ETIMEDOUT should happen, there is no guarantee that it will stay >T
(CLOCK_REALTIME is allowed to be reset backwards).  So, only test
that the current time (after ETIMEDOUT) >= T when we're using
CLOCK_MONOTONIC - for CLOCK_REALTIME the time might have stepped
back between when the ETIMEDOUT happened and when the thread
obtains the current clock reading.  For that case, all we can test
is that the ETIMEDOUT actually happens.

With much of what was there now gone, the code can be simplified,
we no longer need to do timespec arithmetic, just one comparison
(simpler to test that Tend >= Tstart+period than Tend-Tstart > period
as we need Tstart+period for the abstime value for the timeout anyway).

Note that this still tests for the issue reported in PR lib/47703
which is where the test came from in the first place.

ps: we seem to be missing pthread_cond_clockwait() which is the same
as pthread_cond_timedwait() except that the clock to use is passed
as a parameter, rather than as an attribute of the condition variable.

(kre)

Undo the previous revert - turns out that vers 1.7 was correct after
all, and I am simply unable to read or comprehend (properly).

(kre)

It appears that POSIX intends to add a -d X option to the read command
in its next version, so it can be used as -d '' (to specify a \0 end
character for the record read, rather than the default \n) to accompany
find -print0 and xargs -0 options (also likely to be added).

Add support for -d now.  While here fix a bug where escaped nul
chars (\ \0) in non-raw mode were not being dropped, as they are
when not escaped (if not dropped, they're still not used in any
useful way, they just ended the value at that point).

(kre)

Revert last.  remains in northamerica as a zone, does not need a link here
(this one came from the gtz fork, rather than some local botch...)

(kre)

Merge more changes that should have been made, but weren't.  One day
I will work out why this doesn't happen automatically.    Ugh.

(kre)

Note tzdata2022g

(kre)

tzdata update to 2022g
Added zoneinfo files:
America/Ciudad_Juarez

(kre)

Sort (NFCI)

(kre)

Merge tzdata2022g

(kre)

Merge changes that should have been merged in earlier updates, but
got missed.  This is in preparation for an updata to tzdata2022g
which is coming soon (still from the gtz fork).

There is a (small) chance this update might break the build, that will
be fixed (if it happens) when 2022g is merged (which should not be
very far into the future).

(kre)

Adapt to recent gpt(8) change which now issues a message when
the secondary GPT header is moved.  Do it this way rather than
just using -q to suppress the message, so the test verifies that
the appropriate action was taken.

(kre)

Add missing backward compat links that were in the tzdata2022f
release, but didn't make it into the tzdata2022fgtz fork that
we use - and nor did the original zone data come back.

Links seem adequate for these (and were all some of them ever were).

(kre)

PR bin/57053 is related (peripherally) here.

sh has been remembering the process group of a job for a while now, but
using that for almost nothing.

The old way to resume a job, was to try each pid in the job with a
SIGCONT (using it as the process group identifier via killpg()) until
one worked (or none did, in which case resuming would be impossible,
but that never actually happened).  This wasn't as bad as it seems,
as in practice the first process attempted was *always* the correct
one.  Why the loop was considered necessary I am not sure.  Nothing
but the first could possibly work.

This worked until a fix for an obscure possible bug was added a
while ago - now a process which has already finished, and had its
zombie collected via wait*() is no longer ever considered to have
a pid which is a candidate for use in any system call.  That's
because the kernel might have reassigned that pid for some newly
created process (we have no idea how much time might have passed
since the pid was returned to the kernel for reuse, it might have
happened weeks ago).

This is where the example in bin/57053 revealed a problem.

That PR is really about a quite different problem in zsh (from pksrc)
and should be pkg/57053, but as the test case also hit the problem
here, it was assumed (by some) they were the same issue.

The example is (in a small directory)
ls | less
which is then suspended (^Z), and resumed (fg).  Since the directory
is small, ls will be finished, and reaped by sh - so the code would
now refuse to use its pid for the killpg() call to send the SIGCONT.
The (useless) loop would attempt to use less's pid for this purpose
(it is still alive at this point) but that would fail, as that pid
is not a process group identifier, of anything.  Hence the job
could not be resumed.

Before the PR (or preceding mailing list discussion) the change here
had already been made (part of a much bigger set of changes, some of
which might follow - sometime).  We now actually use the job's
remembered process group identifier when we want the process group
identifier, instead of trying to guess which pid it happens to be
(which actually never took any guessing, it was, and is always the
pid of the first process created for the job).  A couple of minor
fixes to how the pgrp is obtained, and used, accompany the changes
to use it when appropriate.

(kre)

Note in the description of "jobs -p" that the process id returned is
also the process group identifier (that's a requirement from POSIX, and
is what we have always done - just not been explicit about in sh.1).
Add a note that this value and $! are not necessarily the same (currently,
and perhaps forever, never the same in a pipeline with 2 or more elements).

(kre)

Note tzdata 2022f update (via 2022fgtz)

(kre)

Merge tzdata2022f

(kre)

Fix a merge or conversion problem (probably) - a .SH BUGS
(meaningless macro in mdoc) followed by the first line of the
real BUGS section somehow ended up inserted after the first
word of the STANDARDS section.  Delete the noise.

(kre)

Avoid sending banner (if configured) twice.  Apparent merge error.
Patch from RVP (issue noticed by John D. Baker).

(kre)

Update dzdata to 2022e (2022egtz).

(kre)

Merge tzdata2022e

(kre)

Add links for Europe/Uzhgorod and Europe/Zaporozhye (to Europe/Kyiv)
These are gone as separate zones, but the names should remain.

(kre)

Note update to tzdata2022d (2022dgtz)

(kre)

Merge tzdata2022d

(kre)

Oops, somehow managed to commit an older version where NBSH_INVOCATION
start char was '@' rather than '!' (which meant not lexically ordered).
This is how it was intended to be (and is documented).

(kre)

Add the -l option (aka -o login): be a login shell.  Meaningful only on
the command line (with both - and + forms) - overrides the presence (or
otherwise) of a '-' as argv[0][0].

Since this allows any shell to be a login shell (which simply means that
it runs /etc/profile and ~/.profile at shell startup - there are no other
side effects) add a new, always set at startup, variable NBSH_INVOCATION
which has a char string as its value, where each char has a meaning,
more or less related to how the shell was started.  See sh(1).
This is intended to allow those startup scripts to tailor their behaviour
to the nature of this particular login shell (it is possible to detect
whether a shell is a login shell merely because of -l, or whether it would
have been anyway, before the -l option was added - and more).  The
var could also be used to set different values for $ENV for different
uses of the shell.

(kre)

More wording improvements.  There might be more to come.

(kre)

Minor wording improvements.

Note these do not alter anything about what the man page specifies,
just say a couple of things in a slightly better way, hence no Dd
update accompanies this change (deliberately).

(kre)

Move a comment that used to be in the correct place, once upon a time,
back where it belongs, and make it stand out more, so other text is
less likely to find itself pushed between the comment and the text
to which it appears.  This change should make no visible difference
to the man page displayed.

(kre)

Whitespace.

(kre)

Correct spelling of terminal (it doesn't have a 2nd m).

(kre)

Fix the syntax of the non _LP64 code fragment to match that in the
_LP64 fragment, so hopefully 32 bit ports with XEN (i386) will
build again.

(kre)

Add debugging trace points for history and the editline interface.
NFC for any normal shell (not compiled with debugging (sh DEBUG) enabled.

We have had a defined debug mode for this for years, but since I have
not often played in this arena, never used it.  Until recently (relatively).
This (or a small part of it) played a part in discovering the fc -e
bug cause.  I have had it in my tree a while now - recent changes
kept causing merge conflicts (all because I hadn't bothered to commit
this), so I think now is the time...

(kre)

Improve the description of the read builtin command.

(kre)

Don't output the error for bad usage (no var name given)
after already writing the prompt (set with the -p option).

That results in nonsense like:

$ read -p foo
fooread: arg count

While here, improve the error message so it means something.

Now we will get:

$ read -p foo
read: variable name required
Usage: read [-r] [-p prompt] var...

[Detected by code reading while doing the work for the previous fix]

(kre)

PR bin/56972  Fix escape ('\') handling in sh read builtin.

In 1.35 (March 2005) (the big read fixup), most escape handling and IFS
processing in the read builtin was corrected.  However 2 cases were missed,
one is a word (something to be assigned to any variable but the last) in
which every character is escaped (the code was relying on a non-escaped char
to set the "in a word" status), and second trailing IFS whitespace at
the end of the line was being deleted, even if the chars had been escaped
(the escape chars are no longer present).

See the PR for more details (including the case that detected the problem).

After fixing this, I looked at the FreeBSD code (normally might do it
before, but these fixes were trivial) to check their implementation.
Their code does similar things to ours now does, but in a completely
different way, their read builtin is more complex than ours needs to
be (they handle more options).  For anyone tempted to simply incorporate
their code, note that it relies upon infrastructure changes elsewhere
in the shell, so would not be a simple cut and drop in exercise.

This needs pullups to -3 -4 -5 -6 -7 -8 and -9 (fortunately this is
happening before -10 is branched, so will never be broken this way there).

(kre)

Add support for fetching and using the Global Time Zone fork of tzdata
in addition to the older (Eggert) version.  The GTZ vesion is the one
we're currently using, so automating its use helps.

While here, correctly compare version numbers, correctly handling the
almost unthinkable need for a multi-char suffix after the year as the
version ID.  This was almost correct before, but would have failed in
the case that 9999za was being updated to 10000a

And add the ability (should not be needed often) to fetch one version
but claim to be using another (this was useful this time, as 2022c
followed quickly on the heels of 2022b - but made no changes at all
to the data, just some of the build infrastructure we don't use).
The GTZ version hadn't been updated (there was no real need, since the
data, which is all that it alters, had not changed) at the time, so
we updated to 2022c using the gtz data file for 2022b.  (The 2022cgtz
data file now exists - but didn't then).

(kre)

Add Europe/Kyiv to the sets list - fix the builds.  Apologies...

(kre)

Balance the parentheses in the previous update...

(kre)

Note tzdata2022c

(kre)

Merge tzdata2022c

(kre)

Change the NEWS parser to handle the more recent (as in going back several
years now) format (wording) that is used there, rather than that which
preceded it.  With this we get the intended "what changed" in the generated
CVS commit message, rather than lots of emptiness.

(kre)

Correct a typo in a comment.  NFC.

(kre)

Minor alteration to the description of what df -b does (plus tiny reformat)

(kre)

Add 4 new flags:
-b (from FreeBSD) - set blocksize to blocks (512 bytes)
(overrides a contrary setting in BLOCKSIZE)
-H (from FreeBSD and Linux): -h using SI units (powers of 10).  Ugh.
-N suppress the header line (except with -P which requires it).
-f show only free space (or inodes) in a minimal format (implies -N)
(that is, with one file[system] specified, print 1 number only)
With -c, show only the total.
Intended to be useful for scripting (aka, I needed it.)

While here, improve the usage message (group options where they apply,
there is no reason, for example, that -g should be shown differently
to -k -m ..., and those options aren't at all useful with -G)

Update the man page to match.

(kre)

Provide _GNU_SOURCE for t_clone now that is required to make clone()
visible.

(kre)

Revert this to 1.205, undoing changes apparently mistakenly
committed in 1.206, and the total disaster that the attempt to
revert those in 1.207 created.

(kre)

Add an Xr to realpath(1) (which does much the same as readlink -f).
Try not to forget the damn comma!

(kre)

Note realpath(1) update.

(kre)

Add ATF tests for realpath(1)

Note that realpath can act differently for root than for other users
(where an ordinary user will see EACCESS root just barrels right through).

The tests adapt themselves, when run as root, less error cases can be
tested than when run as some other user.

(kre)

Make realpath(1) compat with the planned (not yet approved) specification
for POSIX.8 (its next version).  (Should the requirements change, the code
here can be updated).

This adds two new options.  -e and -E
-e just tells realpath to do what it has done since it was imported here.
-E makes realpath more compatible with the coreutils version, and allows
  the final component of the path to not exist (the final component after
  all symlinks have been expanded, not of the arg on the command line - though
  that one not existing is one case of the more general spec.).

POSIX is not going to specify which of those is the default - instead is
planning to require users to always explicitly specify one.

The default (now) here is -E.  This makes us more compat with coreutils.
realpath was added in the first place because it is (apparently) used in
real world scripts - the more we can support, the better.

Note that in all cases where realpath -e succeeds, realpath -E will succeed
as well.  This means that any uses of "realpath file" that have been
working in HEAD will still work.  Some cases that would have failed
will work (by default) now.

(kre)

PR bin/56917

If getfsspecname() fails that will usually mean that a NAME=wedge or
ROOT.x partition is unabailable.  raidframe specified unavailable
partitions as "absent" so in this case, pass "absent" rather than the
unaltered NAME= or ROOT.x string, which the kernel has no clue what
do do with, and doesn't configure the raid at all.

(kre)

Cleanup the "hup" function - quote properly, and test for the pid
file existing (with something in it) before simply using it, so the
error message can be controlled, rather than just sh's cannot open file msg.

(kre)

Get rid of the (insulting)
We recommend that you create a non-root account...
message from single user mode shell startups.

(kre)

Make this better ...  Allow config file for raidN to be found
in /etc/conf/raid/raidN (as well as in /etc/raidN.conf) (less
clutter in /etc).

Allow config files to exist for raids that are autoconfigured (just
skip anything autoconfigured) - this allows a (simplistic) recovery
mechanism if autoconf fails, and makes it simpler to enable/disable
autoconf at will, while keeping the raid working.

While here, add sh quoting where it is needed, and remove it from
where it is pointless.

(kre)

If /rescue is at the head of $PATH (which is how it starts out in /rescue/sh
unless changed by something - and has been since NetBSD 3) don't blindly
simply change it to a PATH that doesn't have /rescue in it at all.

This doesn't solve the "/rescue/tar execs /usr/bin/gzip" problem completely,
as if PATH is in the environment when /rescue/sh is started, that one will
override the shell's built in PATH, but this is better than nothing.

(kre)

Fix core dump caused by
ksh -c '(i=10; echo $((++-+++i)))'
reported by Steffen Nurpmeso (not on a NetBSD list or PR).

Seems pointless to fix just one of the bugs in this thing, but this one was
easy enough (and stupid enough).  (The "i=10" part is unimportant, as is the sub-shell).

(kre)

Bring shutdown(8) into the 21st century.

I found this juxtaposition in the shutdown man page kind of
interesting:

    time  Time is the time at which shutdown will bring the system down
  and may be the word now or a future time in one of two formats:
  ... [2nd format:] [[[[[cc]yy]mm]dd]hh]mm,  ...
  If the century [cc] is not specified, it defaults to 1900 for
  years [yy] between 69 and 99, ...

In that, all the "[text]" except the one "[[[[["(etc) sequence are my
interjections, The ellipses ("...") represent where I omitted irrelevant
(for here) text.

Interesting yes, bizarre also.  Requiring a future time, and then
defaulting to the (long gone) 20th century (for any random year)
makes no sense at all.    So I fixed it.

In another hundred years or so, anytime from 2100 onwards, but best
left at least a decade into the new century, it will need altering again.
[One could write the code to automate this adjustment, but the man
page would still need updating.]  More significant changes will be
needed as the 101st century approaches (years 10000 and beyond), as
then a 2 digit century will no longer be adequate.  Call me then, and
if I'm able, I'll fix it.

If someone really has a need to schedule a shutdown for sometime
between 1969 and 1999 that can still be done by explicitly giving
the "19" cc value.  It is just no longer ever the default.

Otherwise, now, years 20..90 mean the 21st century (2020..2099)
(the first 2 of those are already unusable, but, IMO, that's OK)
and years 00..19 mean the 22nd century (2100..2119) (except that
00, 2100, is still technically the final year of the 21st century).

This is advance planning for near the end of the 21st century when
someone wants to schedule a shutdown for early in the following
century, and can't be bothered typing the 2 century digits.

(kre)

Remove the notge (I added a day or so ago) about IFS interfering with -s
output (potentially) - it is almost certainly wrong.

(kre)

Some corrections to stat to make it more reasonable, and comply with
the man page, in particular, in one of the EXAMPLES it is claimed:

    This example produces output very similar to that from find ... -ls
    (except that find(1) displays the time in a different format, and find(1)
    sometimes adds one or more spaces after the comma in ���major,minor��� for
    device nodes):

and then uses %9Z in the format, but conveniently does not use a
device file to demonstrate.

If it had, the result would have been:

  8033      0 brw-r-----    1 root              operator                  4,      51 Jun  8 02:44:45 2022 /dev/sd3

Note the spaces which were claimed to exist (sometimes) in find(1) output
but not with stat.  Oops.

Omitting those spaces seems like a good idea, so does using the same
field width for the result in both cases, rather than producing 9 chars
in the ordinary file case, and 19 (2 * 9 + 1) in the device case (for %9Z).

Now we will get:

  8033      0 brw-r-----    1 root              operator            4,51  Jun  8 02:44:45 2022 /dev/sd3

While here, also make the file number (%@) when reading stdin be 0, it is
not the 1st file in the arg list.

Some (very minor) KNF applied at the same time.

In stat.1 make these changes explicit.

(kre)

Divide stat.1 into stat.1 (now only includes stat(1)) and readlink.1

Apologies to cvs commit purists, but making this division required
line by line reading of the man pages, and I simply could not resist
also correcting some errors, addressing some omissions, improving some
wording ... all at the same time.

(kre)

Significant changes to output layout methods - except for -x and -y
which have not (yet) been touched (-xD needs *serious* improvements).

While this still has no run-time configurability, it is now easy to
adjust the column widths in the source and recompile.  Dynamic (auto)
column width sizing is probably out of the question (requires predicting
the future) but options to allow the widths to be set isn't out of the
question.

The columns are now (mostly) considerably wider than they were before,
hence wider windows are needed to view the same info.  In an 80
column window the default display (with tty & cpu included) displays
just 2 drives.  160 columns will fit 7 (but with -I, just 4).

One new option added (-z) suppresses output which is true 0 (but still
prints 0 for values rounded down to 0) for everything except tty stats.
For drive output, the drive must have done nothing during the interval
to get its output data blanked.

Also options -H h -W w to set the output size (page height & width), the
former used to decide when to print headers, and the latter to calculate
the number of drives to print when no drive names were given.  Env vars
LINES and COLUMNS are used if the options are not given, with fallback
to the terminal size (if output is to a terminal, and its sizes are
known), and if all else fails, 20 lines, 80 columns.  Specifying 0
means unlimited (infinite).  So "iostat -W 0" will show all of the
drives, across one (often very) long line.  Wedges count as drives.

When drives are specified, the output will now appear in the order they were
given on the command line, rather than the order the system discovered them
during auto-configuration.  If specified as an fnmatch(3) pattern, drives that
match will appear in auto-conf order, but that's generally what is wanted.
When none are specified, you still get the first N (however many fits based
upon the options selected) in auto-conf order (usually useless, more so now
given that less will fit).

Lastly, for those who looked at the patch I sent to current-users@
and were horrified at how kludgey it was, rest assured, that was just
a quick hack to demonstrate what the output format changes would look
like.  This version (I hope) is not nearly so disgusting.

(kre)

Fix processing of the archaic arg format (BACKWARD_COMPATIBILITY) so it
doesn't repeat the processing every iteration.  Repeatedly seeing the wait
interval does no harm, but setting the iteration count (reps) over and
over again rather defeats its purpose.

(kre)

Implement "raidctl -t config-file"

This does the same config file parse  that -c/-C do, but only
that (hence no raidframe device is needed, or accepted).

Any syntax errors in the config file will be reported, nothing
else happens.

(kre)

Fix some config file parsing.

First, and what got me started on this set of cleanups, the queue
length in the "queue" section (START queue) is limited to what will
fit in a char without losing accuracy (I tried setting it to 200,
rather than the more common (universal?) 100 and found that the
value configured into the array was -56 instead.

Why the value needs to be passed through a char variable I have no
idea (it is an int in the filesystem raidframe headers) - but that's
the way it is done, and changing it would be an ABI change I believe
(and so need versioning to alter) and that isn't worth it for this
(or not now, IMO).

Instead check that the value in the char is the same value as was
read from the config file, and complain if not.  Those of you with
unsigned chars will be able to have queue lengths up to 255, the
rest of us are limited to 127.

While looking at that, I noticed some code that obviously fails to
understand that scanf("%s") will never return a string containing
spaces, and proceeded to attempt to remove trailing spaces from the
result ... amusingly, after having used the result for its intended
purpose (non existent trailing spaces unremoved), after which that
buffer was never used again.  That code is now gone (but for now,
just #if 0'd rather than actually deleted - it should be cleaned up
sometime).

Then I saw some other issues with how the config was parsed - a
simple (unbounded) scanf("%s") into a buffer, which hypothetically
might not be large enough (not a security issue really, raidctl has
no special privs, and it isn't likely that root could easily be
tricked into running it on a bogus config file - or not without
looking first anyway, and a huge long string would rather stand
out).  Bound the string length to something reasonable, and
assert() that the buffer is big enough to contain it.

Lastly, in the event of one particular detected error in the
config file, the code would write a warning, but then just go
ahead and use the bad data (or nothing perhaps) anyway - a
failure of logic flow (unlikely to have ever happened, everyone
seems to simply copy the sample config from the man page, and
make minor adjustments as needed).

If any of these changes make any difference to anyone (except
me with my attempt to make longer queues - for no particularly
well thought out reason), I'd be very surprised.

(kre)

In the previous (and some earlier) version(s) of raidctl.c
the following comment appeared:

/*
* After NetBSD 9, convert this to not output the numRow's value,
* which is no longer required or ever used.
*/

We are after NetBSD 9 (well after).  The change requested in that
comment is made here, and the comment is thus removed.

A couple of places in rf_configure.c where a value for the "rows"
parameter was output in an error message (always simply as the
constant 0) have also been updated (those messages will no longer
include "row 0", which they always said previously).  One of them
was also slightly reworded to be clearer what problem it was
experiencing (when it said 'unable to get device file' it meant
it was unable to locate the name for the device in the config file,
not that it was found, and there was some other problem with it).

(kre)

Reorder the getopts() switch () (slightly) to sort the options.  NFCI.

(kre)

KNF (whitespace & 80 column limits) - NFCI.

This is the first of a series of 5 commits in this
directory, all coming within minutes or now.

(kre)

fix local privilege escalation due to a race condition

NetBSD-SA2016-006 included an incomplete fix for CVE-2016-6253,
a local privilege escalation vulnerability in mail.local(8).

mail.local(8) attempts to open(2) a user's existing mailbox file
to append to it.  If that call fails, mail.local(8) will then issue
a second open(2) call to create the file (O_CREAT).

An attacker had the opportunity to create the file in question (as
a symlink, or link to some other file) in between these two open(2) calls.

Fix this by using O_EXCL in the 2nd open call, if the file exists when
that one happens, something is going wrong, so just abort.  Also, only
attempt that 2nd open if the reason the first failed was that the file
did not exist (this doesn't fix the issue, but it potentially saves
some cycles).

Thanks to Jan Schaumann for bringing this to our attention.

(kre)

Alter error messages so they no longer claim that bad input is illegal.

(kre)

Introduce a new macro JNUM to replace the idiom jp-jobtab+1
(the job number, given jp a pointer to a jobs table entry)
used open coded previously in many places (mostly in DEBUG mode
trace messages, so not included in most shells, but there are
a few others).

Make the type of JNUM() be int rather than the ptrdiff_t the
open coded version became ... which when used in some printf()
type function arg list was cast to some other arbitrary (but not
consistent) int type for which there is a standard %Xd type
format conversion.  Now we can (and do) just use %d for this.

If the number of jobs ever exceeds the range of an int, we would
have far more serious problems than the broken output this would
cause.

While here improve a comment or two, and use JOBRUNNING instead
of 0 where the intent is the former (JOBRUNNING is #defined as 0).

NFCI.

(kre)

Redo the way the builtin cmd 'ulimit' getopt() (nextopt() really, but it
is essentially the same) arg string is generated, to lessen the chances
that the table of limits, and the arg string that allows limits to be
reported or set will get out of sync.  They weren't (as long as we didn't
grow an RLIMIT_SWAP) this is just tidier.

While here, reorder the limits table fields, and shrink a couple that
were needlessly wasteful, to save some space -- for most architectures
this should save 8 bytes per table entry (there are currently 13).
(Some minor code bloat offsets this slightly because of int type
promotions now required).

NFCI.

(kre)

While doing the previous change, I noticed that when used in a
particularly perverse way, the error message for a bad octal
constant as the new umask value could incorrectly claim that the
-S option (which would need to be present to cause this issue)
was the detected bad value.  Fix that to report the actual
incorrect arg.

And while fiddling, also check for args to umask that are too big
to be sane mask values (the biggest permitted is 07777) and use
mode_t as the mask variable type, rather than int.

(kre)

Avoid generating error messages implying that user errors are illegal.

(kre)

Note that biosboot without -A clears the PMBR "active" flag.
While here, fix some grammar and make the selection options
for biosboot a little clearer.

Ride nia@'s Dd bump.

(kre)

Updated to tzdata2022agtz which is a 2022a fork with backzone zones
moved back into the main data repo (restoring old data)

(kre)

Merge tzdata2022agtz

(kre)

Note tzdata 2022a (using tzdata2022agtz upstream fork)

(kre)