If a utility called by xargs exits with status 255 or because of a signal,
POSIX requires writing an error message.
PR: 165155
Submitted by: Matthew Story matthewstory gmail com
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
Also add $FreeBSD$ to a few files to keep svn happy.
Discussed with: imp, rwatson
it to kick off a new command before the previous has finished, resulting
in corrupted (interleaved) output. It is also fooled by non-exiting
children it did not start, failing to exit until all extraneous children
have exited.
This patch makes xargs keep track of children it starts, ignoring
pre-existing ones.
but don't expect a proper ASCII string to exist right here right now, don't
use strcmp(3) which checks for a NUL. As we're still building the argument
up, the next character might be garbage. It would probably be just as safe to
temporarily write a NUL there, but if we've reached the end of argument memory
that might not be the best idea, I think. It's unclear.
Doing it this way seems to meet the most with the original intent.
PR: 85696
Prodded by: stefanf
do something sensible (namely: treat then '\0' as the EOL character, when
deciding what "a line" is for -N). Note that -I implies -N.
MFC after: 3 days
1. Conform to IEEE Std 1003.1-2004, which state that "Constructed
arguments cannot grow larger than 255 bytes", and
2. Avoid a buffer overflow.
Unfortunately the standard doesn't indicate how xargs is supposed to
handle arguments which (with the appropriate substitutions) would grow
larger than 255 bytes; this solution handles those by making as many
substitutions as possible without overflowing the buffer.
OpenBSD's xargs resolves this in a different direction, by making
all the substitutions and then silently truncating the resulting string.
Since this change may break existing scripts which rely upon the buffer
overflow (255 bytes isn't really all that long...) it will not be MFCed.
- Don't fail if we can't open /dev/null since this can happen if
xargs is jail'ed or chroot'ed.
These fixes were submitted by Todd Miller from the OpenBSD project.
There was one problem in those fixes that broke -o, which is corrected
here and should be committed to the OpenBSD repo by Todd soon.
MFC in: 3 days
FreeBSD. This method attempts to centralize all the necessary hacks
or work arounds in one of two places in the tree (src/Makefile.inc1
and src/tools/build). We build a small compatibility library
(libbuild.a) as well as selectively installing necessary include
files. We then include this directory when building host binaries.
This removes all the past release compatibilty hacks from various
places in the tree. We still build on tip of stable and current. I
will work with those that want to support more, although I anticipate
it will just work.
Many thanks to ru@, obrien@ and jhb@ for providing valuable input at
various stage of implementation, as well as for working together to
positively effect a change for the better.
the child process, before executing the command. This is very useful
when you do stuff like ``find ... | xargs interactive_application''.
Without -o, the application would inherit the pipe as its stdin, and
you thus lose any control over it.
This flag has been carefully chosen to not conflit with other options
of other xargs utilities like GNU xargs.
Reviewed by: jmallett
(I skipped those in contrib/, gnu/ and crypto/)
While I was at it, fixed a lot more found by ispell that I
could identify with certainty to be errors. All of these
were in comments or text, not in actual code.
Suggested by: bde
MFC after: 3 days
This corrects a problem whereby xargs could not walk the environment table
to count the amount of space it used, and treated it as if it were empty.
This problem was introduced in rev 1.15.
MFC after: 2 days
than triggering a usage(). Allow -R and -I to be specified in any order, and
thus change how -R checks for -I not being given and triggering a usage().
Partially requested by: gad