ludo@gnu.org (Ludovic Courtès) skribis:

> So the two lines that fail are these:
>
> # Explicitly disallow values above CUT_MAX
> (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || fail=1
> (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || fail=1
>
> I don’t understand why at this point, but I found that removing
> “2>/dev/null” from these two lines lets the test pass (and AIUI, this
> redirection is not necessary for the test; it just hides the
>
>   cut: byte/character offset '4294967296' is too large
>   
> error message.)

With the attached file I (and a patch coreutils such that it would
build; #:tests? #f is enough), I was able to reproduce the problem.  The
build log I get is this:

--8<---------------cut here---------------start------------->8---
+ ulimit -v 2004
+ echo before
before
+ /gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut -b4294967296 /dev/null
/gnu/store/9bkl74hd3f1gysdkq22hp8w4z9w8022l-bash-4.4.12/bin/sh: xmalloc: variables.c:4539: cannot allocate 69 bytes (57344 bytes allocated)
+ echo after 2
after 2
/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut: byte/character offset '4294967296' is too large
Try '/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut --help' for more information.
/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut: byte/character offset '4294967296' is too large
Try '/gnu/store/iglljv347sj1mjx8r6li7plb4h7cv8h9-coreutils-8.26/bin/cut --help' for more information.

;;; (bash "/gnu/store/9bkl74hd3f1gysdkq22hp8w4z9w8022l-bash-4.4.12/bin/sh")

;;; (status 0 0)

;;; (status2 256 1)

;;; (status3 256 1)
--8<---------------cut here---------------end--------------->8---

The thing that’s failing here is the shell that invokes ‘cut’, and thus
we get an exit value of 2 whereas the test explicitly checks for 1.

This is very sensitive: depending on the command sequence we pass to “sh
-c”, we hit that problem or we don’t.  The fact that removing
“2>/dev/null”  solved the problem was probably just chance.

So I think Coreutils commit 28803c8a3144d5d4363cdbd148bbe067af1a67c2,
which arbitrarily increased the value passed to “ulimit -v”, goes in the
right direction after all but is insufficient.

I’m trying out a new patch based on that and will push if it works.

Ludo’.