mec.gnu@xxxxxxxxxxxxxx (Michael Elizabeth Chastain) wrote: > I tried coreutils 5.1.3 on hppa2.0w-hp-hpux11.11 and alphaev68-dec-osf5.1. > I ran into several problems, documented below. ... Thanks again for the testing and report. > alphaev68-dec-osf5.1, gnu make 3.79.1, osf cc > > configure works > build works > 'make install' fails as before, because config/install-sh is mode 644. > after fixing that, 'make install' works fine > > make check says: > > make[3]: Entering directory `/house/chastain/cu-osf-3/build/tests' > ../../src/csplit: /: closing delimiter `/' missing > FAIL: csplit That's due to a bug in OSF 5.1's /bin/sh. When I ran that same test a few days ago, I found that it would pass when invoked using bash, and so I didn't dig any deeper. Your report has prompted me to do more. Here's some code to demonstrate the OSF /bin/sh failure: $ x=// $ eval "echo \$x" / With most other Bourne shells, the output is `//'. But OSF 5.1's /bin/sh omits the last slash: `/'. OSF's /bin/sh treats two or more adjacent slashes specially. Here's another example: $ x='a // /// b' $ eval "echo \$x" a / // b Hmm. I had assumed it was eval-related. It's not: $ echo / // /// //// .// //. / / // /// ./ //. $ set -x $ echo abc| tr -t ab // + echo abc + tr -t ab / /bc Sheesh. Problems like this are what drove me to use/develop GNU tools so long ago. I've Cc'd the autoconf list, since its manual has a nice section on shell portability issues. I know that // can be treated specially when it is the leading part of a pathname, but I've never heard of a shell performing the // -> / substitution indiscriminately.
