[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: factor tests: ugly long file names

From: Jim Meyering
Subject: Re: factor tests: ugly long file names
Date: Fri, 26 Oct 2012 10:34:31 +0200

Bernhard Voelker wrote:
> I was just wondering if we shouldn't refactor the new factor tests.
> They have ugly and long file names (the test data), and have identical content
> (which is redundancy which in turn should be avoided IMO):
> $ md5sum *.sh
> 31c3a9e8b5dad969dafd07c348c48233

As you've seen, the factorization, ahem, is already done, in a sense.
Those test cases are recorded in factored form in tests/
No line there is longer than 80.

While there are many of these long-named factor tests, the only file
saved in version control is, and those long-named files are
merely temporaries that are hard-linked to

However, as you've seen, the resulting (expanded) file names
are very long.  We could easily shave off a few bytes by
recording "START-N" rather than "START-END" pairs.

-  $(tf)/$(p)08551616-$(p) \
+  $(tf)/$(p) \

-  $(tf)/$(t1)-$(t1) \
+  $(tf)/$(t1) \

With this matching change:

diff --git a/tests/factor/ b/tests/factor/
index 6ff24c3..d63f733 100755
--- a/tests/factor/
+++ b/tests/factor/
@@ -3,8 +3,8 @@
 # Expect to be invoked via a file whose basename matches
 # /^(\d+)\-(\d+)\-([\da-f]{40})\.sh$/
 # The test is to run this command
-# seq $1 $2 | factor | shasum -c --status <(echo $3  -)
-# I.e., to ensure that the factorizations of integers $1..$2
+# seq $1 $(expr $1 + $2) | factor | shasum -c --status <(echo $3  -)
+# I.e., to ensure that the factorizations of integers $1..$1+$2
 # match what we expect.

 # Copyright (C) 2012 Free Software Foundation, Inc.
@@ -25,6 +25,7 @@ set $t
 echo "$3  -" > exp

-seq $1 $2 | factor | shasum -c --status exp && f=0
+end=$(expr $1 + $2)
+seq $1 $end | factor | shasum -c --status exp && f=0

 Exit $f

If "make check" output line length were really important

A simple additional change would be to use md5sum in place of sha1sum.
We don't need the added strength/length of sha1sum for this.

You could save more by encoding the checksum in base64 rather than hex,
but with that, the mechanics may get involved, so I wouldn't bother.

Another simple change: use only 8 or 10 hex digits instead
of the full checksum.

You're welcome to pursue it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]