On Mon, 2008-06-02 at 20:40 -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Joe Marcus Clarke <[EMAIL PROTECTED]> 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?
This will yield false positives as many (all?) contain embedded C code.
We have been using one regexp that seems to work nicely: " == ". For
example:
@${FIND} ${WRKSRC} -name Makefile.in | ${XARGS} ${REINPLACE_CMD} -e \
's|" == "|" = "|g'
You don't typically find '"' on either side of a == in C.
Joe
--
PGP Key : http://www.marcuscom.com/pgp.asc
signature.asc
Description: This is a digitally signed message part
