[platform-testers] new snapshot available: sed-4.4.104-290c

[Jim Meyering]

Hello Jim,

https://meyering.net/sed/sed-4.4.104-290c.tar.xz

AIX 2 (00FA74164C00,CC=xlc)
Alpine Linux 3.6 (with musl libc)
Darwin 16.7.0 (x86_64)
Debian 8.10 (i686)
Debian 8.9 (mips64)
Debian unstable (sparc64)
FreeBSD 11.1-RELEASE-p7 (amd64)
Linux 3.10.0-514.10.2.el7.ppc64le (ppc64le)
Linux 3.10.0-514.26.2.el7.ppc64 (ppc64)
NetBSD 7.1 (amd64)
OpenBSD 6.2 (amd64)
Raspbian 8.0 (armv7l)
Ubuntu 14.04 (aarch64)
Ubuntu 16.04 (x86_64,CC=clang-3.8)
Ubuntu 16.04 (x86_64,CC=clang-4.0)
Ubuntu 16.04 (x86_64,CC=clang-5.0)
Ubuntu 16.04 (x86_64,CC=gcc)
Ubuntu 16.04 (x86_64,CC=gcc-4.9)
Ubuntu 16.04 (x86_64,CC=gcc-5.4)
Ubuntu 16.04 (x86_64,CC=gcc-6.4)
Ubuntu 16.04 (x86_64,CC=gcc-7.2)
Ubuntu 16.04 (x86_64,CC=tcc)
However, on OpenBSD, AIX and Alpine Linux
the gnulib 'test-localename' failed.
This is somewhat strange, because gnulib's updates

[...]

localename: Add support for musl libc.

https://lists.gnu.org/archive/html/bug-gnulib/2018-02/msg00071.html
I'm not sure why it still failed on Alpine linux (which uses musl).
FAIL: test-localename
=====================
test-localename.c:183: assertion 'strcmp (name, "fr_FR.UTF-8") == 0' failed
Abort trap (core dumped)
FAIL test-localename (exit status: 134)
FAIL: test-localename
=====================
FAIL test-localename (exit status: 132)
FAIL: test-localename
=====================
test-localename.c:183: assertion 'strcmp (name, "fr_FR.UTF-8") == 0' failed
Aborted
FAIL test-localename (exit status: 134)
Additionally, on Alpine linux which uses busybox's diff(1),
FAIL: test-version-etc.sh
=========================
diff: unrecognized option: c
FAIL test-version-etc.sh (exit status: 1)

Wow. Thank you for all that prompt testing.

I've just addressed the test-version-etc.sh issue by pushing the
attached to gnulib. I agree that the other gnulib/test failures appear
unrelated to sed, but will wait at least a day before making the
release.

[Eric Blake]

Post by Jim Meyering

Additionally, on Alpine linux which uses busybox's diff(1),
FAIL: test-version-etc.sh
=========================
diff: unrecognized option: c
FAIL test-version-etc.sh (exit status: 1)

Wow. Thank you for all that prompt testing.
@@ -36,7 +36,7 @@ EOT
/^Packaged by/d
2,3 s/Copyright (C) [0-9]\{4,4\}/COPYRIGHT/' |
tr -d '\015' |
- diff -c $TMP - || ERR=1
+ diff $TMP - || ERR=1

Is 'diff -u' portable to busybox? ed script diffs are a pain to read in
comparison to context or unified diffs, so I think this change is a
reduction in quality if something better is available.

POSIX requires diff to support both -u and -c; you may want to also
report the missing support for -c to the busybox maintainers.

[Jim Meyering]

Post by Eric Blake

Post by Jim Meyering

Additionally, on Alpine linux which uses busybox's diff(1),
FAIL: test-version-etc.sh
=========================
diff: unrecognized option: c
FAIL test-version-etc.sh (exit status: 1)

Wow. Thank you for all that prompt testing.
@@ -36,7 +36,7 @@ EOT
/^Packaged by/d
2,3 s/Copyright (C) [0-9]\{4,4\}/COPYRIGHT/' |
tr -d '\015' |
- diff -c $TMP - || ERR=1
+ diff $TMP - || ERR=1

Is 'diff -u' portable to busybox? ed script diffs are a pain to read in
comparison to context or unified diffs, so I think this change is a
reduction in quality if something better is available.

Thanks. It can be better, indeed: use our very own init.sh, with its
compare function. Done in the attached.

[Paul Eggert]

test=${1##*/}
I would strongly urge removal of such shell extensions.

That syntax has been standard ever since POSIX formalized the shell in
IEEE Std 1003.2-1992 (I just pulled out my trusty printed copy and
checked). It's a bit of a stretch to call it an "extension" 26 years
after standardization.

That being said, I too have a soft spot in my heart for Solaris, and
regularly check portability to the Solaris 10 server that is still the
central server in our department. If it's easy to port to Solaris 10,
which I think is still the case, we might as well do it. I'll see if I
can pry some time free to fix the glitches. The first thing I noticed, I
fixed as per the attached (cc'ing bug-gnulib).

[Jim Meyering]

test=${1##*/}
I would strongly urge removal of such shell extensions.

That syntax has been standard ever since POSIX formalized the shell in IEEE
Std 1003.2-1992 (I just pulled out my trusty printed copy and checked). It's
a bit of a stretch to call it an "extension" 26 years after standardization.

I would strongly urge not to remove such constructs, but rather to
begin your script with the sourcing of init.sh, which ensures the
remainder of the script is interpreted by a sensible shell.
Alternatively, I could have done this:

test=`echo "$1" |sed 's,.*/,,'`

But that would violate my "don't use backticks" rule, of necessity,
since $(...) probably doesn't work in such an old interpreter. So at
first, I was inclined to include this line at the top:

. "${srcdir=.}/testsuite/init.sh"

But there's an even better solution:

[Paul Eggert]

Thanks, with that change (and updating to the latest Gnulib, though I doubt that
matters), sed builds and passes 'make check' on my Solaris 10 Generic_150400-34
sparc server, compiling with Sun C 5.9 124867-12 2009/11/22.

[Bruno Haible]

Hi Jim,

Post by Jim Meyering
But that would violate my "don't use backticks" rule, of necessity,
since $(...) probably doesn't work in such an old interpreter.

In my recent experience with Solaris 10, HP-UX 11.31, AIX 7, IRIX 6.5,
it was only the IRIX /bin/sh that did not grok $(...).

Personally I prefer backticks because with `...` I don't need to think
about which shell is used to execute the script.

Bruno

[Bruno Haible]

+
+ havelib: port to Solaris 10 /bin/sh
+ * m4/lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Use 'test ! EXPR'
+ instead of '! test EXPR'.
+

Thanks Paul!

[Nelson H. F. Beebe]

Post by Paul Eggert
...

test=${1##*/}
I would strongly urge removal of such shell extensions.

That syntax has been standard ever since POSIX formalized the shell in
IEEE Std 1003.2-1992 (I just pulled out my trusty printed copy and
checked). It's a bit of a stretch to call it an "extension" 26 years
after standardization.
...

I just looked up that standard (page 37) and tried its several
examples with /bin/sh on Solaris 10. To my surprise, some of them
produced errors, and not the output shown in those examples.

I then repeated the experiment with /usr/xpg4/bin/sh, and they
worked as shown in POSIX.

Next, I looked at the manual page for sh:

DESCRIPTION
The /usr/bin/sh utility is a command programming language that executes
commands read from a terminal or a file.

The /usr/xpg4/bin/sh utility is a standards compliant shell. This util-
ity provides all the functionality of ksh(1), except in cases discussed
in ksh(1) where differences in behavior exist.

So, Solaris 10 /bin/sh is not fully in accord with POSIX, and thus
remains the most `primitive' shell that we have to deal with in
practice. I suspect that we'll be running Solaris 10 systems for at
least another five or so years at my site.

I've always found the shell's ${parameter<OPERATOR>word} expansion
rules hard to remember, and so, instead of

$ x=/one/two/three
$ echo ${x##*/}
three

I normally use

$ basename $x
three


-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: [phone] -
- University of Utah FAX: [phone] -
- Department of Mathematics, 110 LCB Internet e-mail: ***@math.utah.edu -
- 155 S 1400 E RM 233 ***@acm.org ***@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[Paul Eggert]

Post by Nelson H. F. Beebe
I just looked up that standard (page 37) and tried its several
examples with /bin/sh on Solaris 10. To my surprise, some of them
produced errors, and not the output shown in those examples.
I then repeated the experiment with /usr/xpg4/bin/sh, and they
worked as shown in POSIX.

Yes, and this is why scripts like 'configure' automatically reexecute
themselves with bash or ksh or whatever, if they find themselves running
on Solaris 10 /bin/sh. Although it's a bit awkward, it's better than
trying to live within the intersection of the old SunOS sh and a POSIX
shell. In 'sed' you found one script that wasn't doing that, but Jim has
fixed that now (by removing the script!).

I just now checked and ./configure still tries sh5, an Ultrix-based
POSIXish shell that was last released in 1995! We have the late Fred
Canter to thank for that, I imagine. See:

Hall J. The last farkle. Linux J. 2007-12-02.
https://www.linuxjournal.com/node/1005779