Date: Tue, 03 Jun 2008 10:05:46 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: src-committers@FreeBSD.org, jhb@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, stefanf@FreeBSD.org, marcus@marcuscom.com Subject: Re: cvs commit: src/bin/sh expand.c parser.c parser.h Message-ID: <1212501946.15220.1.camel@localhost> In-Reply-To: <20080602.213239.-861051005.imp@bsdimp.com> References: <1212440845.18384.49.camel@shumai.marcuscom.com> <20080602.204014.-222576415.imp@bsdimp.com> <1212461214.18384.83.camel@shumai.marcuscom.com> <20080602.213239.-861051005.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-MXy7s6rPc8W8/jq+KxPt
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Mon, 2008-06-02 at 21:32 -0600, M. Warner Losh wrote:
> In message: <1212461214.18384.83.camel@shumai.marcuscom.com>
> Joe Marcus Clarke <marcus@marcuscom.com> writes:
> : On Mon, 2008-06-02 at 20:40 -0600, M. Warner Losh wrote:
> : > In message: <1212440845.18384.49.camel@shumai.marcuscom.com>
> : > Joe Marcus Clarke <marcus@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
> : > : > > >=20
> : > : > > > FreeBSD src repository
> : > : > > >=20
> : > : > > > Modified files:
> : > : > > > bin/sh expand.c parser.c parser.h=20
> : > : > > > Log:
> : > : > > > Expand $LINENO to the current line number. This is require=
d by=20
> : > : > > SUSv3's "User
> : > : > > > Portability Utilities" option.
> : > : > > > =20
> : > : > > > Often configure scripts generated by the autotools test if =
$LINENO works=20
> : > : > > and
> : > : > > > refuse to use /bin/sh if not.
> : > : > > > =20
> : > : > > > Package test run by: pav
> : > : > >=20
> : > : > > This breaks the build of editors/openoffice-2
> : > : > >=20
> : > : > > Specifically, the libxslt configure script has two statements l=
ike this:
> : > : > >=20
> : > : > > if test "1" =3D=3D "1"
> : > : > > then
> : > : > > blah blah
> : > : > > endif
> : > : > >=20
> : > : > > Specifically note the "=3D=3D" passed to test(1). POSIX says t=
his should be "=3D",=20
> : > : > > and that's all our test(1) implements. The bash manpage for th=
e builtin-test=20
> : > : > > command says:
> : > : > >=20
> : > : > > string1 =3D=3D string2
> : > : > > True if the strings are equal. =3D may be used i=
n place of =3D=3D for
> : > : > > strict POSIX compliance.
> : > : > >=20
> : > : > > IOW, it encourages "=3D=3D". I'm not sure if we want to force =
the use of bash for=20
> : > : > > certain ports or if we want to just implement bash'isms in our =
tools as we=20
> : > : > > encounter them (or patch the port?). In this case the patch is=
not=20
> : > : > > complicated (just replace the two '=3D=3D' with '=3D' in libxsl=
t's configure=20
> : > : > > script).
> : > : > >=20
> : > : >=20
> : > : > This is annoying... I had to clean this behavior up once recently=
in
> : > : > someone else's script. POSIX "test" syntax has been "=3D" and not=
"=3D=3D" for
> : > : > a long time. Bash is not C... so I don't understand why the attem=
pt to
> : > : > document "=3D=3D" as the "proper" operator. My thinking is the of=
fending
> : > : > 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 "=3D=3D" by POSIX).
> : > :=20
> : > : This is one of the most pervasive bashisms around. We (gnome@)
> : > : typically fix the script to use "=3D" then forward the information
> : > : upstream. Solaris is also bit by this, so it's usually not a big d=
eal
> : > : to get upstream vendors to fix their scripts.
> : >=20
> : > Maybe a 'grep =3D=3D' on all configure scripts should be SOP, eh?
> :=20
> : This will yield false positives as many (all?) contain embedded C code.
> : We have been using one regexp that seems to work nicely: " =3D=3D ". F=
or
> : example:
> :=20
> : @${FIND} ${WRKSRC} -name Makefile.in | ${XARGS} ${REINPLACE_CMD} -e \
> : 's|" =3D=3D "|" =3D "|g'
> :=20
> : You don't typically find '"' on either side of a =3D=3D in C.
>=20
> heh...
>=20
> Another option would be to add support for it to our test, maybe with
> a warning... :-)
>=20
> Warner
>=20
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...
--=20
Coleman Kane
--=-MXy7s6rPc8W8/jq+KxPt
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEABECAAYFAkhFT7YACgkQcMSxQcXat5encQCfTr98vpxdBNY6ffI35ckSmk0d
+PYAn2kvYW0fJBrwtBJPONlTIHmF/7Sz
=xlgg
-----END PGP SIGNATURE-----
--=-MXy7s6rPc8W8/jq+KxPt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1212501946.15220.1.camel>