Subject: Re: pkg/36257 (games/wesnoth has msgfmt problems (plurals) [NetBSD 3.0])
To: None <,,>
From: Robert Elz <kre@munnari.OZ.AU>
List: pkgsrc-bugs
Date: 05/09/2007 18:50:04
The following reply was made to PR pkg/36257; it has been noted by GNATS.

From: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: pkg/36257 (games/wesnoth has msgfmt problems (plurals) [NetBSD 3.0]) 
Date: Thu, 10 May 2007 00:47:06 +0700

     Date:        Wed,  9 May 2007 16:20:04 +0000 (UTC)
     From:        Joerg Sonnenberger <>
     Message-ID:  <>
   |  Are you sure?
 Yes, though it certainly depends upon both the version of test,
 and the number of operands - I haven't looked at the modern (in
 sh) implementations, but original test was totally heuristically
 driven - if it had 3 args, and the middle one was an operator, it
 assumed the other two must be operands, which is generally pretty
 safe, but starts getting much trickier when there are more operands).
 Since it is so trivial to avoid even the possibility of a problem
 in a way that works for every version of test, it is generally a
 good idea to do that.
   |  Read the specification for test.
 I don't much care (for this purpose, as distinct from writing/correcting
 an implementation) what the specification says - what matters is what
 the implementations in the wild actually do.
   |  The operator order is far from trivial,
   |  but most cases of using prefix values serve the purpose of hacking
   |  around Solaris /bin/sh bugs with empty arguments and the like.
 Solaris test (and solaris /bin/sh) were (at least based upon) the
 original versions, back in the days when in cases of ambiguity in the
 man pages, the source code ruled...
 Working with those "bugs" is one of the things that portable code needs
 to handle.
   |  Avoiding -a and -o is a good thing, yes. That's different from this
   |  though.
 Aside from cases where you can rewrite things to simplify and avoid
 a logical operator completely, the only reason to avoid -a and -o 
 (using && and || instead) is to avoid strangeness in implementations of
 test.   If you were confident that test whatever -a whatever_else
 would have the same effect (always) as test whatever && test whatever_else
 then using the former would always be better - even where test is built
 into the shell, it means less work, and also allows test to cache stat
 results (in expressions like "test -b x -o -c x").