Backwards compatibility with the new acct(5) format will be
implemented through the explicit versioning of acct records,
not through an export/import procedure.
failed path is one which was specified on the command line.
This is a compromise between the situation prior to revision 1.57
(where a race between tar(1) and rm(1) could cause tar(1) to
spuriously report an error) and the situation after revision 1.57
(where "tar -c /no/such/path" prints a warning but returns with
an exit code of zero).
Inspired by: rafan
MFC after: 1 week
Not because I admit they are technically wrong and not because of bug
reports (I receive nothing). But because I surprisingly meets so
strong opposition and resistance so lost any desire to continue that.
Anyone who interested in POSIX can dig out what changes and how
through cvs diffs.
"The setenv( ) function shall fail if:
[EINVAL] The name argument is a null pointer, points to an empty string,
or points to a string containing an '=' character."
The fix (like all others in this subject) is backward-compatible.
"The setenv( ) function shall fail if:
[EINVAL] The name argument is a null pointer, points to an empty string,
or points to a string containing an '=' character."
The fix (like all others in this subject) is backward-compatible.
o Print "unknown ICMP" instead of "(null)" if we don't have a description for a icmp type.
Based on code
Submitted by: Christoph Weber-Fahr
PR: misc/112126
MFC after: 2 weeks
each file independently from other files. The new semantics are
desired in the most of practical cases, e.g.: delete lines 5-9
from each file.
Keep the previous semantics of -i under a new option, -I, which
uses a single continuous address space covering all files to edit
in-place -- they are too cool to just drop them.
Add regression tests for -i and -I.
Approved by: dds
Compared with: GNU sed
Discussed on: -hackers
MFC after: 2 weeks
This fixes infinite restart in the following case:
Makefile: foo
foo: bar
do-something
Unlike GNU make, BSD make considers "Makefile" node as remade even
if "foo" is up-to-date and was not actually rebuilt.
GNU make does not consider nodes without commands as remade if child nodes
were not actually rebuilt.
Most probably, more proper fix would be to bring BSD make behaviour in-line
with GNU make but this would be more intrusive change.
occur on the write side of extracting a file to ARCHIVE_WARN errors
when returning them from archive_read_extract.
In bsdtar: Use the return code from archive_read_data_into_fd and
archive_read_extract to determine whether we should continue trying to
extract an archive after one of the entries fails.
This commit makes extracting a truncated tarball complain once about
the archive being truncated, instead of complaining twice (once when
trying to extract an entry, and once when trying to seek to the next
entry).
Discussed with: kientzle
titles extracted from argv vector instead of the real executable names.
This is useful when you want to watch applications that set their status
information via setproctitle(3).
Approved by: alfred
MFC after: 2 weeks
unmount jail-friendly file systems from within a jail.
Precisely it grants PRIV_VFS_MOUNT, PRIV_VFS_UNMOUNT and
PRIV_VFS_MOUNT_NONUSER privileges for a jailed super-user.
It is turned off by default.
A jail-friendly file system is a file system which driver registers
itself with VFCF_JAIL flag via VFS_SET(9) API.
The lsvfs(1) command can be used to see which file systems are
jail-friendly ones.
There currently no jail-friendly file systems, ZFS will be the first one.
In the future we may consider marking file systems like nullfs as
jail-friendly.
Reviewed by: rwatson
read data from the standard input. This allows tail -f to pipe
data to lastcomm, and thereby real-time monitoring of executed
commands. The manual page includes the exact incantation.
MFC after: 2 weeks
and had no chance to match it by the 2nd address precisely.
Otherwise the unclosed range would bogusly extend to the end
of stream.
Add a basic regression test for the bug fixed. (This change
also fixes the more complex case 5.3 from `multitest.t'.)
Compared with: SUN and GNU seds
Tested by: regression tests
MFC after: 1 week
in parentheses. The ?: operator has a remarkably low precedence, so
expressions like (MATCH(foo) && bar) would have an unexpected meaning
w/o the parentheses around MATCH().
Tested with: md5(1)
them are related to the `c' function's need to know if we are at
the actual end of the address range. (It must print the text not
earlier than the whole pattern space was deleted.) It appears the
only sed function with this requirement.
There is `lastaddr' set by applies(), which is to notify the `c'
function, but it can't always help because it's false when we are
hitting the end of file early. There is also a bug in applies()
due to which `lastaddr' isn't set to true on degenerate ranges such
as `$,$' or `N,$' if N appears the last line number.
Handling early EOF condition in applies() could look more logical,
but it would effectively revert sed to the unreasonable behaviour
rev. 1.26 of main.c fought against, as it would require lastline()
be called for each line within each address range. So it's better
to call lastline() only if needed by the `c' function.
Together with this change to sed go regression tests for the bugs
fixed (c1-c3). A basic test of `c' (c0) is also added as it helped
me to spot my own error.
Discussed with: dds
Tested by: the regression tests
MFC after: 1 week
into separate append_archive and append_archive_filename functions; the first
takes a "struct archive *" as input, while the second takes a filename, opens
the archive, and calls the first.
There should be no changes in behaviour as a result of this commit; it simply
reorganizes code to make more sense. At some point in the future it may be
possible to share code between append_archive and read_archive, but not yet.
Discussed with: kientzle
affecting the return value from bsdtar), since (a) it usually occurs
due to a perfectly innocent (and unavoidable) race condition where a
user deletes a file in the window between bsdtar reading a directory
and attempting to read the file; and (b) aside from printing a warning
message, bsdtar behaves exactly as if the file had been deleted prior
to bsdtar reading its parent directory.
Reviewed by: kientzle
MFC after: 6 days
complaining about lstat(2) failing. It's a bit scary to find the message
tar: /: Cannot stat: No such file or directory
printed while doing a backup.
MFC after: 1 week
better job searching for the bsdtar binary to test and the gtar binary
to use for inter-operability testing. It should now find the built
(but not installed) binary if there is one, then search for an
installed binary in a number of standard locations.
* New test scripts exercise some basic functionality
* Most header inclusions are now protected (portability)
* read.c now relies on security checks in libarchive instead
of trying to do its own (optimization)
* -p now enabled by default for root, add --no-same-permissions
to disable it
* Comments, minor style fixes.
caused fstat to produce duplicated output for threaded processes. Instead
use KERN_PROC_PROC to get just one kinfo_proc per process.
MFC After: 2 weeks
