Re: tests/misc/printenv.sh: env/printenv: reverse sort order on aarch64

[Bernhard Voelker]

On 02/02/2015 04:43 AM, Jim Meyering wrote:
> On Sun, Feb 1, 2015 at 4:02 PM, Bernhard Voelker
> <address@hidden> wrote:
>> On aarch64, we're experiencing a test failure in tests/misc/printenv.sh
>> on the openSUSE Build Service: the output of 'env' is sorted exactly
>> in reverse order compared to that of 'printenv'.

> I'd guess that the aarch64 libc's execvp reverses the order of the pointers,

Bingo!
'env' produces the same output as 'env env env' and 'env env env env env'
on that aarch64 platform, while 'env env' and 'env env env env' produce
the tac'ed output.

> which suggests we should not be relying on the order of those lines.

hmm, we're relying on some kind of order between 'env' and 'printenv'
also in other places, e.g. in tests/misc/env-null.sh ... with a big
comment there wrt. sort order:

  # POSIX is clear that environ may, but need not be, sorted.
  # Environment variable values may contain newlines, which cannot be
  # observed by merely inspecting output from env.
  # Cygwin requires a minimal environment to launch new processes: execve
  # adds missing variables SYSTEMROOT and WINDIR, which show up in a
  # subsequent env.  Cygwin also requires /bin to always be part of PATH,
  # and attempts to unset or reduce PATH may cause execve to fail.
  #
  # For these reasons, it is better to compare two outputs from distinct
  # programs that should be the same, rather than building an exp file.
  env -i PATH="$PATH" env -0 > out1 || fail=1
  env -i PATH="$PATH" printenv -0 > out2 || fail=1
  compare out1 out2 || fail=1
  env -i PATH="$PATH" env --null > out2 || fail=1
  compare out1 out2 || fail=1
  env -i PATH="$PATH" printenv --null > out2 || fail=1
  compare out1 out2 || fail=1

Well, that actually assumes that the sorting (if any!) is the same
on subsequent invocations ... which the introducing comment negates.
A clearer way would be to explicitly sort the output.

OTOH, it seems that the sort order of env/printenv is quite stable
on all known platforms, so I think it might be sufficient for now to
use the same number of execv()s to work around the problem for the
failing case as shown in my initial diff.

> Also note that the grep regexp is slightly too loose: it excludes
> any name that begins with "_", rather than just the one that is mentioned
> in that comment.

Good catch.
I'll take care of this in the upcoming patch, too.

Thanks & have a nice day,
Berny