When calculating the length of the args that can be
appended in a "find .... -exec something {} +"
usage, remember to allow for the arg pointers, which
form part of what is allowed in ARG_MAX.
From a fairly empty installation of HEAD on amd64
and with a "/tmp/args" command that simply prints
its arg count, and the length of the arg strings,
with this mod I see ..
netbsd# find / -exec /tmp/args {} +
Argc 5000 Arglen 107645
Argc 5000 Arglen 151324
Argc 5000 Arglen 187725
Argc 5000 Arglen 206591
Argc 5000 Arglen 172909
Argc 5000 Arglen 186264
Argc 5000 Arglen 167906
Argc 2881 Arglen 98260
The upper limit of 5000 args is in the code.
Using the biggest of those, 5000
args, plus 206591 bytes of strings
uses 246591 bytes total (this excludes
the command name, so add a few more).
That's fairly close to the ARG_MAX
of 262144.
On another system (with longer paths) I see:
(this is just a small part of the output, using a
different version of the dummy command, and a
slightly different invocation)
Args: 4546 Len 218030
Args: 4878 Len 217991
Args: 4813 Len 218028
Args: 4803 Len 218029
There, 4878*8 + 217991 == 257015 which is about
as close as we'd want to come to the arg limit.
XXX pullup -8
attributes against a user-specified timestamp (rather than the
attributes of a reference file).
Update the parse routines so they have access to the name of the
option being parsed. This enables accurate error reporting for
"aliases" of primaries.
Now that aliases work, introduce some aliases for consistency with
Gnu findutils.
per the standard. Per (brief) discussion on tech-userlevel.
There should really be a form where you can do the equivalent of
"-exec blah {} blah +", but I think we're going to need to call it
something other than -exec. As it is it's sort of surprising that the
standards people didn't add a different name -- note what happens if
you try to do something like "find ... -exec expr {} + 2 \;".
This primary causes find to stop traversing the filesystem and
exit immediately if a previous condition was met. If no value is
specified, the exit value will be 0, else n. Note that other
primaries will be evaluated and acted upon before exiting.
Ok matt@, garbled@.
-false This primary always evaluates to false. This can be used follow-
ing a primary that caused the expression to be true to make the
expression to be false. This can be useful after using a -fprint
primary so it can continue to the next expression (using an -or
operator, for example).
This was brought up on the tech-userlevel list in October.
Using -fprint on findutils or new NetBSD find(1) does not do what
I wanted. For example, if saving results of all files that start
with a vowel or saving results of all files owned by group operator,
then the list of files owned by group operator would not include
the files starting with a vowel.
findutils's find has a workaround for this with -false and also a
"," comma opeator. (I made add this comma operator later; you can use
the comma to perform multiple independent tests.)
code) comes from findutils; it behaves the same.
From my manpage addition:
-fprint filename
This primary always evaluates to true. This creates filename or
overwrites the file if it already exists. The file is created at
startup. It writes the pathname of the current file to this
file, followed by a newline character. The file will be empty if
no files are matched.
Here is an example usage:
find /etc \( -name "*pass*" -fprint file1 \) -o \( -group operator -fprint file2 \) -o -name "w*"
Note that this example will NOT include entry in file2 if it is
matched in first expression. (This also is same behaviour as
findutils, and I have implemented a -false primary to handle that.
I will commit it later.)
This creates the file as command line argument parsing time.
If there is an error somewhere on that line, such as missing values
or mismatched parenthesis, then a file may still be created.
(Even if a later -fprint filename is unwritable.) This is similar
behaviour to findutils. (It has been suggested that this find could
be code to create the files in an extra stage after the command-line
argument parsing and before the actual function processing.)
I will add -fprintx and -fprint0 soon.
This was discussed on tech-userlevel.
Our behavior is now consistent with Solaris, and more useful than previous.
Unfortunately we end up strtol()-ing twice (once via atoi()) to avoid
changing find_parsenum().
ctime than its argument.
From kre in PR bin/14802; originally suggested name was "updated" but
renamed due to GNU find(1) being prior art for this functionality.
andvar