Re: coreutils-5.1.3 released: bug-fix-only, candidate for stable 5.2.0

[Jim Meyering]

address@hidden (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.