This is not needed now that tests automatically look for `gpatch` on mac
since commit 1254f146f8 ("tests: validate "patch" and "ed" commands
once, print meaningful messages (#226)")
The fewer PATH changes, the better.
Signed-off-by: Marc Herbert <Marc.Herbert@gmail.com>
When we fail to find `gpatch`, don't say that we failed to find `patch`.
Cosmetic fix to commit 1254f146f8 ("tests: validate "patch" and "ed"
commands once, print meaningful messages (#226)")
This is an extremely minor fix because the error message already printed
"gpatch validation failed, no such file or directory" even before this
commit.
Signed-off-by: Marc Herbert <Marc.Herbert@gmail.com>
macOS' /usr/bin/patch and GNU patch have very subtle incompatibilities
that cause only some "more advanced" tests to fail in obscure and very
time-consuming ways - while other tests pass. In some cases (depending
on test threads racing), the lack of newlines in some test data even
causes the whole test suite to stall.
This fix runs `patch -version` (only once), makes sure the output starts
with "GNU patch" and shows a meaningful assert message when not. It also
looks for `gpatch` instead of `patch` on macOS and shows a meaningful
assert message if either is missing.
Fixes: #225
This also provides faster and better feedback when `ed` is missing (see
#39) and implements a portable and basic check.
Last but not least, this new code is generic enough to support the
validation of any other test dependency in the future.
* feat: u64 for --bytes and --ignore-initial
fix: bumped up tempfile to "3.26.0"
The variables for --bytes, --ignore-initial and line count where size 'usize',
thus limiting the readable bytes on 32-bit systems.
GNU cmp is compiled with LFS (Large File Support) and allows i64 values.
This is now all u64, which works also on 32-bit systems with Rust.
There is no reason to implement a 32-bit barrier for 32 bit machines.
Additionally the --bytes limit can be set to 'u128' using the feature
"cmp_bytes_limit_128_bit".
The performance impact would be negligible, as there only few calculations
each time a full block is read from the file.
---------
Co-authored-by: Gunter Schmidt <gsgit@beadsoft.de>
Co-authored-by: Sylvestre Ledru <sylvestre@debian.org>
Fixes#223. Very simple reproduction
```
cd diffutils
mkdir a
touch a/alef a/alefn a/alef_ a/alefx a/alefr a/fuzz.file
cargo test
```
=> fail
https://www.gnu.org/software/diffutils/manual/html_node/Multiple-Patches.html
states that the "old" file name has precedence over the "new" filename.
I hit this problem because some other (and unfortunately: unknown for
now) test issue left bogus `a/alef*` file(s) behind in my workspace. I
didn't bother cleaning them up because I assumed some test would keep
recreating them and that cost me a lot of time.
This issue seems to have existed since the very first commit.
Interestingly, there as a previous attempt in 2024 to fix this in commit
a3a372ff36 ! So I was apparently not the only affected. BUT that
fix was immediately reverted by commit ba7cb0aef9 in the same
PR. Admittedly, that fix seemed somewhat off-topic in
https://github.com/uutils/diffutils/pull/33. So here it is again.