We (will soon) have support for -exec and -execdir clauses that end with a ';' (i.e. run this command for every file/directory). We need to also add support for clauses that end with a '+' (i.e. batch up the files/dirs and then run the command for as many as possible at once).
Unfortunately this isn't easy in an os-independent way because the standard library doesn't expose any way of telling when a command-line is going to be too long. I raised rust-lang/rust#40384 but it's not getting much traction.
So we need to go for a lowest common denominator approach. Choose a hard-coded limit (I'd suggest a bit less than 8kB, to allow for any inaccuracies in the next bit), come up with an efficient way of estimating the command-line length (doing this accurately is going to involve reimplementing too much of std::process::Command) and trigger the command when the estimated total goes over the limit.
To do this we need to
- add a MultiExecMatcher class to find::matchers::exec (implementing the finished_dir and finished methods to make the exec calls for any remaining files that haven't been executed yet)
- tweak find::process_dir to call the finished and finished_dir methods as appropriate
- tweak find::matchers::build_matcher_tree to stop returning an error when -exec[dir] finds a + and create a MultiExecMatcher instead.
We (will soon) have support for -exec and -execdir clauses that end with a ';' (i.e. run this command for every file/directory). We need to also add support for clauses that end with a '+' (i.e. batch up the files/dirs and then run the command for as many as possible at once).
Unfortunately this isn't easy in an os-independent way because the standard library doesn't expose any way of telling when a command-line is going to be too long. I raised rust-lang/rust#40384 but it's not getting much traction.
So we need to go for a lowest common denominator approach. Choose a hard-coded limit (I'd suggest a bit less than 8kB, to allow for any inaccuracies in the next bit), come up with an efficient way of estimating the command-line length (doing this accurately is going to involve reimplementing too much of std::process::Command) and trigger the command when the estimated total goes over the limit.
To do this we need to