- Lose any stray host bits that a user may have entered when providing
a network number and netmask to the `-a' option for IPv6. This is
corresponding to 1.79 that is for IPv4 only.
MFC after: 1 week
- Don't assume environment variable HOME is not NULL.
o Integrate standards compliance from NetBSD.
- Allow -- before the command.
- Blocking SIGQUIT isn't standards compliant.
- Proper exit(3) levels.
- Actually append to nohup.out (as documented and required
by standard) instead of clobbering it.
o Remove some FreeBSD specific access(2) cruft (relating to
incorrect appending).
o Document the fact that two or more instances of nohup can
append to the same file.
o Constify; Staticize functions; Set WARNS?=2
Reviewed by: bde
Approved by: des
Obtained from: NetBSD, OpenBSD
MFC after: 9 days
to give up after one attempt unless a background mount is requested.
Background mounts would retry 10000 times (at least 7 days) before
giving up.
For some situations such as diskless terminals, an NFS filesystem
may be critical to the boot process, so neither the "try once" nor
background mounts are appropiate. To cater for this situation,
unbreak the -R (retry count) parameter so that it also works in
the non-background case. Interpret a zero retry count as "retry
forever".
The defaults are now "try once" for non-background mounts and "retry
forever" for background mounts; both can be overridden via -R.
Add a description of this behaviour to the manpage.
the SYNOPSIS hasn't had an example number of devices since rev 1.2 which
was over 5 and a half years ago, so remove a sentence claiming that the
example in the SYNOPSIS limited bpf to 16 devices.
MFC after: 3 days
in the background. fsck_ffs uses `5' for when SOFTUPDATES are not set,
and thus background cleaning cannot take place. That seems to [semi-]apply
here. So I don't know what non-zero value to use.
If anyone has an opinion, let me know.
it may be plugged into a kernel that supports VLANs. If the kernel is
not VLAN aware, things will still work as before.
Modules don't really have option support, so this is somewhat of a hack.
another, unknown option.
Submitted by: Naoki Kobayashi <shibata@geo.titech.ac.jp> and
Harti Brandt <brandt@fokus.gmd.de>, respectively.
Pointy hat to: dd
give an example of how to rotate logs at the beginning of the month.
Although they sound the same, since both of them rotate logs at the
beginning of the day, the former ended up taking place on, e.g., July
31 00:00 instead of the expected July 31 23:59. This is contraty to POLA.
Submitted by: Dan Langille <dan@langille.org>
(ironically, the assumption is in a code block which is conditional on its
converse). This isn't strictly the correct fix; it's more of a workaround
to prevent an infinite loop. The correct fix (see
ports/editors/nvi-devel/files/patch-vi-relative r1.1) would take a file off
the vendor branch, but since the result for this version of nvi is
identical, this route was elected.
PR: 28687
Approved by: -developers
