cvs commit: src/bin/sh expand.c parser.c parser.h

[M. Warner Losh]

In message: <1212440845.18384.49.camel at shumai.marcuscom.com>
            Joe Marcus Clarke <marcus at marcuscom.com> writes:
: On Mon, 2008-06-02 at 16:52 -0400, Coleman Kane wrote:
: > On Mon, 2008-06-02 at 14:45 -0400, John Baldwin wrote:
: > > On Thursday 15 May 2008 03:55:27 pm Stefan Farfeleder wrote:
: > > > stefanf     2008-05-15 19:55:27 UTC
: > > > 
: > > >   FreeBSD src repository
: > > > 
: > > >   Modified files:
: > > >     bin/sh               expand.c parser.c parser.h 
: > > >   Log:
: > > >   Expand $LINENO to the current line number.  This is required by 
: > > SUSv3's "User
: > > >   Portability Utilities" option.
: > > >   
: > > >   Often configure scripts generated by the autotools test if $LINENO works 
: > > and
: > > >   refuse to use /bin/sh if not.
: > > >   
: > > >   Package test run by:    pav
: > > 
: > > This breaks the build of editors/openoffice-2
: > > 
: > > Specifically, the libxslt configure script has two statements like this:
: > > 
: > > if test "1" == "1"
: > > then
: > > 	blah blah
: > > endif
: > > 
: > > Specifically note the "==" passed to test(1).  POSIX says this should be "=", 
: > > and that's all our test(1) implements.  The bash manpage for the builtin-test 
: > > command says:
: > > 
: > >        string1 == string2
: > >               True if the strings are equal.  = may be used in place of == for
: > >               strict POSIX compliance.
: > > 
: > > IOW, it encourages "==".  I'm not sure if we want to force the use of bash for 
: > > certain ports or if we want to just implement bash'isms in our tools as we 
: > > encounter them (or patch the port?).  In this case the patch is not 
: > > complicated (just replace the two '==' with '=' in libxslt's configure 
: > > script).
: > > 
: > 
: > This is annoying... I had to clean this behavior up once recently in
: > someone else's script. POSIX "test" syntax has been "=" and not "==" for
: > a long time. Bash is not C... so I don't understand why the attempt to
: > document "==" as the "proper" operator. My thinking is the offending
: > script should be fixed with a patch that gets forwarded upstream to the
: > libxslt team (including a mention that /bin/sh and /bin/test are not
: > documented to support "==" by POSIX).
: 
: This is one of the most pervasive bashisms around.  We (gnome@)
: typically fix the script to use "=" then forward the information
: upstream.  Solaris is also bit by this, so it's usually not a big deal
: to get upstream vendors to fix their scripts.

Maybe a 'grep ==' on all configure scripts should be SOP, eh?

Warner