"env name=value ... cmd ..." is just a pessimized way of doing
"name=value ... cmd ..." in real shells. Set the environment
(without using env(1)) before starting xargs so that env(1)
is not needed in "xargs env name=value ... cmd ..."
"env name=value ... cmd ..." was just a pessimized way of doing
"name=value ... cmd ...". Note that make(1) can't optimize
either of these to an exec of env(1) or "cmd" even if the second
"..." is simple, since it can't tell that the shell metacharacter
in "name=value" is actually handled by env(1).
uudecode(1), as this behaviour was explicitly added in revision 1.12 as
the result of PR 2882. Remove space (' ') from the delimiter characters
handed to strtok(3).
Reviewed by: mike
Approved by: mike
Pointy hat to: me
only doing ipnat(8). Go back to using $ipfilter_active, but turn off
$ipfilter_active when loading ipl.ko has failed.
Submitted by: devet@devet.org (Arjan de Vet)
MFC after: 3 days
chmodding using an octal mode, as uudecode needs to handle symbolic modes
as chmod and such do.
Suggested by: Tim J. Robbins <tim@robbins.id.au>
Also move meta-character (~ in this case) globbing to only if we are reading
the filename from the encoded file, as otherwise it is the shell's job.
Reviewed by: mike
Approved by: mike
than %u for printing signed 64-bit types. It fails on different machines,
and has the wrong signdness.
Fixed old printf format error on the same line. %u is not suitable for
printing 32-bit types on all machines.
"Fixed" format printf error in previous commit. This file is not
formatted in KNF. Partially restore bug for bug compatibility: indent
the printf args too much, but don't format them for 160-column terminals.
than %u for printing signed 64-bit types. It fails on different machines,
and has the wrong signdness.
Fixed old printf format error on the same line. %u is not suitable for
printing 32-bit types on all machines.
While I'm here, make the menu entries on the documentation menu begin
with "1" instead of "2".
Reviewed by: imp, rwatson, murray
Approved by: imp, rwatson, murray
MFC after: 1 week
best path forward now is likely to change the lockmgr locks to simple
sleep mutexes, then see if any extra contention it generates is greater
than removed overhead of managing local locking state information,
cost of extra calls into lockmgr, etc.
Additionally, making the vm_map lock a mutex and respecting it properly
will put us much closer to not needing Giant magic in vm.
