> So there's already an attempt to reject invalid shell var names. In
> the ==foo=bar case, $ac_envvar ends up empty (hence the eval errors
> out and the export ends up displaying the current environment).
Indeed. And the same bug was previously reported and fixed in autotest,
http://gi
On Nov 4, 2008, at 10:26 AM, Eric Blake wrote:
Indeed. And the same bug was previously reported and fixed in
autotest,
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=372769c
,
then followed with a slicker patch that also catches leading digits:
http://git.savannah.gnu.org/
The other day, one of our developers accidentally typed the following:
./configure ==prefix=foo ...
and since our configure script and build process is pretty long, he
didn't notice the error until he typed "make install" and it tried to
install into /usr/local. Oops!
Granted, this is
A bug report on the autoconf list recently reported that autoconf has been
producing configure files for several years now with a dependence on
tr[1], even though tr is not listed in the set of safe programs[2]. Since
there have been no bug reports about an inability to configure packages
because
Hello Eric,
* Eric Blake wrote on Tue, Nov 04, 2008 at 02:21:05PM CET:
> A bug report on the autoconf list recently reported that autoconf has been
> producing configure files for several years now with a dependence on
> tr[1],
I didn't see it, where exactly would that be?
> 2008-11-04 Eric Bla
A bug report on the autoconf list recently reported that autoconf has been
producing configure files for several years now with a dependence on
tr[1]
[1] http://lists.gnu.org/archive/html/autoconf/2008-10/msg00124.html
The config.status for texinfo uses tr in one place, as far as I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Karl Berry on 11/4/2008 4:33 PM:
Hi Karl, Ralf,
> A bug report on the autoconf list recently reported that autoconf has been
> producing configure files for several years now with a dependence on
> tr[1]
> [1] http://list
