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

Coleman Kane cokane at FreeBSD.org
Tue Jun 3 14:07:34 UTC 2008


On Mon, 2008-06-02 at 21:32 -0600, M. Warner Losh wrote:
> In message: <1212461214.18384.83.camel at shumai.marcuscom.com>
>             Joe Marcus Clarke <marcus at marcuscom.com> writes:
> : On Mon, 2008-06-02 at 20:40 -0600, M. Warner Losh wrote:
> : > 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?
> : 
> : 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.
> 
> heh...
> 
> Another option would be to add support for it to our test, maybe with
> a warning... :-)
> 
> Warner
> 

If we chose to do that, then I'd also suggest a compile flag to turn on
"strict POSIX compliance". Then, perhaps some ports-auto-build-box
somewhere could generate a report of the configure scripts that do such
things, and could be used to nag them into fixing this problem. Maybe
someone should nag the bash developers...

-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20080603/99d9dfb3/attachment.pgp


More information about the cvs-all mailing list