| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
@italic on the AUR stated that bfs from the AUR fails to build on
Manjaro. From the build log, it seems like <time.h> doesn't get
included properly. I assume it's picking up ./time.h instead.
I couldn't reproduce the build issue in the default configuration, but
it does fail with EXTRA_CFLAGS="-I." which isn't good. So rename
everything with an x prefix to stop clashing.
Link: https://aur.archlinux.org/packages/bfs#comment-856102
Link: https://paste.rs/eqR
|
|
|
|
|
|
| |
Otherwise output from commands may appear unexpectedly earlier than
output from bfs. We use fflush(NULL) to flush all streams, which is
more than GNU find does, but seems to be a useful extension.
|
| |
|
|
|
|
|
| |
This reduces the number of E2BIGs we see if binary search reaches the
top of the possible range.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would shrink the command by one argument at a time until a
successful execution. This is okay if the ARG_MAX estimate is just a
little bit off, but is terribly slow when it's off by a lot.
One situation where it's very far off is when a 32-bit build of bfs
launches a 64-bit binary. In this case, bfs thinks the argv pointers
are 4 bytes, while they actually take up 8 bytes. The performance is
quite bad:
$ time ./bfs-64 ~/code/linux -exec echo {} + >/dev/null
./bfs-64 ~/code/linux -exec echo {} + > /dev/null 0.03s user 0.07s system 99% cpu 0.095 total
$ time ./bfs-32 ~/code/linux -exec echo {} + >/dev/null
./bfs-32 ~/code/linux -exec echo {} + > /dev/null 0.08s user 10.33s system 100% cpu 10.390 total
After this change, performance is much better:
$ time ./bfs-32 ~/code/linux -exec echo {} + >/dev/null
./bfs-32 ~/code/linux -exec echo {} + > /dev/null 0.03s user 0.08s system 99% cpu 0.110 total
|
| |
|
|
|
|
|
|
| |
This lets us keep more open FDs cached in bftw(). The limit is lowered
before running -exec commands, in case they're incompatible with a high
limit (e.g. due to select()).
|
| |
|
|
|
|
| |
Thanks to https://github.com/include-what-you-use/include-what-you-use
|
| |
|
| |
|
|
|
|
|
| |
The API remains similar, with some added accessor functions for lazy
initialization of the pwcache and mtab.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This adds a bfs: prefix to error/warning messages for consistency with
other command line tools, and leaves only the "error:"/"warning:" part
colored like GCC. It also uniformly adds full stops after messages.
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this, we'd fork and then segfault on every file as NULL was
passed to execvpe(). Found while looking through old FreeBSD find bugs:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=36521
bfs still supports the (dubious, possibly unintentional?) GNU find
extension to POSIX that allows
$ bfs -exec {} \;
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Linux-style accounting, we really only need to handle a single page
of wasted space due to rounding. Subtracting two pages for extra
headroom was reasonable on systems with 4K pages, but overkill on
systems like ppc64le with 64K pages. Worse yet was the fact that Alpine
Linux only gives us 128K for arguments.
Instead, only subtract a single page, plus the POSIX-recommended 2048
bytes.
Credit to Mike Sullivan for the initial patch and testing on Alpine
ppc64le.
Fixes:
http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/bfs/bfs-1.2.2-r0.log
Co-authored-by: Mike Sullivan <mksully22@gmail.com>
|
| |
|
| |
|
|
|
|
|
| |
Also, don't pass the address of errno itself to write(), since write()
is allowed to modify it.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
From looking at the Linux exec() implementation, it seems a big part of
the reason we needed extra headroom was that the arguments/environment
are copied page-by-page, so even a small accounting difference could
result in an error of an entire page size. Grow the headroom to two
entire pages to account for this.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I ran into "argument list too long" errors with a
bfs -type f -exec grep pattern '{}' +
command, despite the current accounting being pretty careful. Some
experimentation showed that an additional 2048 bytes of headroom is
always safe.
While we're at it, explicitly account for the terminating NULL pointers
in argv and environ.
|
| |
|
|
|
|
| |
-ok should look for a ; even if it sees {} +, according to POSIX.
|
|
|
|
|
|
|
|
|
| |
POSIX explicitly forbids this extension:
> Only a <plus-sign> that immediately follows an argument containing
> only the two characters "{}" shall punctuate the end of the primary
> expression. Other uses of the <plus-sign> shall not be treated as
> special.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This fixes strange "Inappropriate ioctl for device" errors when using
-exec ... + with output redirection. errno was set to ENOTTY by the
isatty() call during startup for color auto-detection, and never cleared
before eval_exec() wants to check if anything went wrong.
|
| |
|
| |
|
|
|
|
| |
Thanks to https://www.in-ulm.de/~mascheck/various/argmax/
|
| |
|
|
|