[bug #62506] do-not-seek-the-unseekable.sh: result depends on "make -j<n>"

[G. Branden Robinson]

Update of bug #62506 (project groff):

                  Status:            Works For Me => In Progress            

    _______________________________________________________

Follow-up Comment #5:

[comment #4 comment #4:]
>   The test for "/dev/stdin" to be a character device is harmful.

No, it isn't--it's the whole point of the check.

>   The test is for a seekability, it does not matter what "/dev/stdin"
> stands for.

You are overlooking the history of the underlying change.


commit ecf7aeccbb4e5ecf54277117b503edf27dffbd9f
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Mar 3 05:24:08 2022 +1100

    [preconv]: Test operands for seekability.
    
    Stop assuming that the default input stream, or an explicit '-' operand,
    is the only unseekable stream.  Check instead.
    
    * src/preproc/preconv/preconv.cpp (do_file): Add new Boolean
      `is_seekable`.  Test the input stream with `fseek()` per a suggestion
      from Ingo Schwarze.  Report unseekability in debug output and skip
      coding tag and uchardet tests altogether (precisely paralleling our
      description in the preconv(1) man page).  Also update debugging output
      to say "<standard input>" instead of "-".
    
    Fixes <https://savannah.gnu.org/bugs/?62131>.
    
    Also add editor aid comments and drop old style Emacs file-local
    variable setting.

commit fffc018c0d5faeb6b7954291e2998f911c20197b
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Mar 4 07:40:35 2022 +1100

    [preconv]: Regression-test Savannah #62131.
    
    * src/preproc/preconv/tests/do-not-seek-the-unseekable.sh: Do it.
    * src/preproc/preconv/preconv.am (preconv_TESTS): Run test.
    
    Test fails at this commit.


The point of this part of the test is to exercise the code path where the
input stream was not named "-" but is nevertheless not seekable.  If
'/dev/stdin' _is_ seekable, then we are not producing the desired execution
trace and our test result would not be valid.  Consequently we have to skip
it.

>   In my case (make -j) it is a pipe, which is not seekable, also the
> test is positive, yes, true, PASS.

I run "make -j" routinely and never see this behavior.
 
>   If "/dev/stdin" is seekable, the test fails (FAIL), which should then
> be examined.

No, if /dev/stdin is seekable, it simply means that the conditions we require
for the test were not met.  It doesn't mean that preconv has regressed.
 
>   If "/dev/stdin" does not exist (-e /dev/stdin) then testing that has
> no purpose and the result is PASS (the nonexistent item is not
> seekable!).

If a test has no purpose (that is, cannot report a valid result), the correct
semantics are to SKIP it, not PASS it.

In POSIX 1003.3, which the Automake test infrastructure closely (but not
exactly) models, 'SKIP' can be thought of as synonymous with 'UNSUPPORTED', or
perhaps 'UNRESOLVED'.  (In fact, 'SKIP' seems to be an umbrella for both of
these plus 'UNTESTED'.)

Please see
https://www.gnu.org/software/dejagnu/manual/A-POSIX-Conforming-Test-Framework.html
.

'PASS' is the wrong result if a valid test cannot be performed due to
environmental limitations.

I have the following change pending.


$ git diff src
diff --git a/src/preproc/preconv/tests/do-not-seek-the-unseekable.sh
b/src/preproc/preconv/tests/do-not-seek-the-unseekable.sh
index 3cb364044..2d0b7440b 100755
--- a/src/preproc/preconv/tests/do-not-seek-the-unseekable.sh
+++ b/src/preproc/preconv/tests/do-not-seek-the-unseekable.sh
@@ -41,8 +41,10 @@ echo "$output" | grep -q "stream is not seekable" || wail
 
 # /dev/stdin might not exist in a chroot.  Or, if it's not (a symbolic
 # link to) a character special device, the next test will not be valid.
+# Similarly, we must have a controlling terminal.
 test -z "$fail"
 test -c /dev/stdin || exit 77 # skip
+test "$(tty)" != "not a tty" || exit 77 # skip
 
 echo "testing seekability of standard input stream" >&2
 output=$(printf '' | "$preconv" -d /dev/stdin 2>&1)


I believe the foregoing will resolve this bug.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62506>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/