You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Jim Gallacher <jp...@jgassociates.ca> on 2006/02/06 22:38:36 UTC
bash bug (was Re: mod_python 3.2.7 available for testing)
A couple of thoughts on this issue.
According to the gentoo bug report quoted below, the problem in
configure.in is the double backslash escape sequence in the line:
MP_VERSION=`echo $MP_VERSION | sed s/\\"//g`
Changing this to:
MP_VERSION=`echo $MP_VERSION | sed s/\"//g`
fixes it for bash 3.1. I wonder why we are using \\" since the gentoo
fix seems to work ok with bash 3.0 (and GNU sed) on my system just as
well. Is it there to support other shells, other sed versions, older
bash versions... ??
I suggest we either adopt the gentoo fix, or avoid the problem
altogether by using tr. eg.
MP_VERSION=`echo $MP_VERSION | tr -d '"'`
I'm assuming tr is always available on UNIX-like systems.
Jim
Jim Gallacher wrote:
> The bash 3.1.x bug is the likely culprit.
>
> For more info see:
>
> http://www.modpython.org/pipermail/mod_python/2006-January/019965.html
> http://www.modpython.org/pipermail/mod_python/2006-January/019969.html
> http://bugs.gentoo.org/show_bug.cgi?id=118948
>
> Jim
>
>
> Sébastien Arnaud wrote:
>
>> Hi Graham,
>>
>> I am using:
>>
>> arnaudsj@andromeda ~/mod_python-3.2.7 $ bash --version
>> GNU bash, version 3.1.7(1)-release (x86_64-pc-linux-gnu)
>> Copyright (C) 2005 Free Software Foundation, Inc.
>>
>> I will look at if I can find later the BASH bug you are referring to.
>> I had the feeling that it was not directly mod_python causing the
>> issue, but that I ought to report the issue, since the problem was
>> not existent when I compiled the latest official release of
>> mod_python (3.1.4)
>>
>> Thanks,
>>
>> Sébastien
>>
>>
>> On Feb 6, 2006, at 2:06 PM, Graham Dumpleton wrote:
>>
>>> What version of BASH shell are you using? Can't remember the
>>> version, but a
>>> particular patch level revision of BASH released recently has a bug
>>> in it
>>> which causes configure to error. Ie., it is a BASH bug and not
>>> mod_python.
>>>
>>> Have to run now, so more later.
>>>
>>> Graham
>>>
>>> On 07/02/2006, at 6:46 AM, Sébastien Arnaud wrote:
>>>
>>>> Hi,
>>>>
>>>> I hate to be the first one to report an issue with 3.2.7 tarball...
>>>> It might be related to my lack of knowledge (just joined the dev
>>>> list a few days ago), but here it is:
>>>>
>>>> It is failing during the configure process...
>>>>
>>>> arnaudsj@andromeda ~/mod_python-3.2.7 $ ./configure --with-apxs=/
>>>> usr/sbin/apxs2
>>>> checking for gcc... gcc
>>>> checking for C compiler default output file name... a.out
>>>> checking whether the C compiler works... yes
>>>> checking whether we are cross compiling... no
>>>> checking for suffix of executables...
>>>> checking for suffix of object files... o
>>>> checking whether we are using the GNU C compiler... yes
>>>> checking whether gcc accepts -g... yes
>>>> checking for gcc option to accept ANSI C... none needed
>>>> checking for ar... ar
>>>> checking for a BSD-compatible install... /usr/bin/install -c
>>>> checking whether make sets $(MAKE)... yes
>>>> checking for main in -lm... yes
>>>> checking for an ANSI C-conforming const... yes
>>>> checking your blood pressure... a bit high, but we can proceed
>>>> configure: checking whether apxs is available...
>>>> checking for --with-apxs... /usr/sbin/apxs2 executable, good
>>>> checking Apache version... 2.0.55
>>>> checking for Apache libexec directory... /usr/lib64/apache2/modules
>>>> checking for Apache include directory... -I/usr/include/apache2
>>>> checking for --with-python... no
>>>> checking for python... /usr/bin/python
>>>> checking Python version... 2.4
>>>> checking Python install prefix... /usr
>>>> checking checking where python libraries are installed... /usr/
>>>> lib64/python2.4
>>>> checking for Py_NewInterpreter in -lpython2.4... yes
>>>> checking what libraries Python was linked with... -lpython2.4 -
>>>> lpthread -ldl -lutil -lm
>>>> checking linker flags used to link Python...
>>>> checking where Python include files are... -I/usr/include/python2.4
>>>> ./configure: line 3427: syntax error near unexpected token `('
>>>> ./configure: line 3427: ` as_lineno_3=`(expr $as_lineno_1 + 1) 2>/
>>>> dev/null`'
>>>>
>>>> System is an Opteron 170 running Gentoo in 64 bit mode (2005.1
>>>> profile):
>>>>
>>>> uname -a
>>>> Linux andromeda 2.6.14-gentoo-r5 #1 SMP Sun Jan 15 21:46:56 CST
>>>> 2006 x86_64 Dual Core AMD Opteron(tm) Processor 170 AuthenticAMD
>>>> GNU/Linux
>>>>
>>>> /usr/sbin/apache2 -v
>>>> Server version: Apache/2.0.55
>>>> Server built: Jan 19 2006 15:46:57
>>>>
>>>> /usr/sbin/apache2 -l
>>>> Compiled in modules:
>>>> core.c
>>>> prefork.c
>>>> http_core.c
>>>> mod_so.c
>>>>
>>>> Python is 2.4.2
>>>>
>>>> FYI, mod_python 3.1.4 configures, compiles and runs fine on the
>>>> same system.
>>>>
>>>> Please let me know if you need anymore info.
>>>>
>>>> Thanks,
>>>>
>>>> Sébastien
>>>>
>>>>
>>>> On Feb 5, 2006, at 8:10 PM, Jim Gallacher wrote:
>>>>
>>>>> Mod_python 3.2.7 tarball is available for test. Here's hoping this
>>>>> will be to final time we need your help testing before the
>>>>> official release.
>>>>>
>>>>> 3.2.7 adds a fix for the connection read issue that was causing
>>>>> problems on FreeBSD.
>>>>>
>>>>> Here are the rules:
>>>>>
>>>>> In order for a file to be officially announced, it has to be
>>>>> tested by
>>>>> developers on the dev list. Anyone subscribed to this list can (and
>>>>> should feel obligated to :-) ) test it, and provide feedback *to
>>>>> _this_
>>>>> list*! (Not the mod_python@modpython.org list, and preferably not me
>>>>> personally).
>>>>>
>>>>> The files are (temporarily) available here:
>>>>>
>>>>> http://www.modpython.org/dist/
>>>>>
>>>>> Please download it, then do the usual
>>>>>
>>>>> $ ./configure --with-apxs=/wherever/it/is
>>>>> $ make
>>>>> $ (su)
>>>>> # make install
>>>>>
>>>>> Then (as non-root user!)
>>>>>
>>>>> $ cd test
>>>>> $ python test.py
>>>>>
>>>>> And see if any tests fail. If they pass, send a +1 to the list, if
>>>>> they
>>>>> fail, send the details (the versions of OS, Python and Apache, the
>>>>> test
>>>>> output, and suggestions, if any).
>>>>>
>>>>> Thank you for your assistance,
>>>>> Jim Gallacher
>>>>>
>>>>
>>>
>>
>
>
Re: bash bug (was Re: mod_python 3.2.7 available for testing)
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Sébastien Arnaud wrote:
> Hi,
>
> I would like to report:
>
> +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2
>
> After replacing the troubling line (line 3038, configure):
>
> from:
> MP_VERSION=`echo $MP_VERSION | sed s/\\"//g`
> to (Deron's 1st suggestion):
> MP_VERSION=`echo $MP_VERSION | sed 's/"//g' `
>
> I guess now it's up to you to decide if you want to integrate the patch
> or if you want to leave it as is for this release ;)
In the interest of actually *releasing* something I think this should
wait for a future bug fix release. In the interim the fix is simple
enough that someone on an affected platform can manually change
configure.in. It's not an ideal solution, but then neither is an endless
series of beta and release candidates. ;)
I'll create a JIRA issue so this doesn't get lost.
Jim
Re: bash bug (was Re: mod_python 3.2.7 available for testing)
Posted by Sébastien Arnaud <ar...@emedialibrary.org>.
Hi,
I would like to report:
+1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2
After replacing the troubling line (line 3038, configure):
from:
MP_VERSION=`echo $MP_VERSION | sed s/\\"//g`
to (Deron's 1st suggestion):
MP_VERSION=`echo $MP_VERSION | sed 's/"//g' `
I guess now it's up to you to decide if you want to integrate the
patch or if you want to leave it as is for this release ;)
Thanks,
Sébastien
On Feb 6, 2006, at 4:13 PM, Deron Meranda wrote:
> On 2/6/06, Jim Gallacher <jp...@jgassociates.ca> wrote:
>> A couple of thoughts on this issue.
>>
>> According to the gentoo bug report quoted below, the problem in
>> configure.in is the double backslash escape sequence in the line:
>>
>> MP_VERSION=`echo $MP_VERSION | sed s/\\"//g`
>>
>> Changing this to:
>> MP_VERSION=`echo $MP_VERSION | sed s/\"//g`
>>
>>
>> fixes it for bash 3.1. I wonder why we are using \\" since the gentoo
>> fix seems to work ok with bash 3.0 (and GNU sed) on my system just as
>> well. Is it there to support other shells, other sed versions, older
>> bash versions... ??
>>
>> I suggest we either adopt the gentoo fix, or avoid the problem
>> altogether by using tr. eg.
>>
>> MP_VERSION=`echo $MP_VERSION | tr -d '"'`
>>
>> I'm assuming tr is always available on UNIX-like systems.
>
> Personally I prefer tr because it's more readable. But I don't know
> it's availability outside Unix. You can try single-quoting the sed
> expression and eliminationg the backslashes altogether:
>
> MP_VERSION=`echo $MP_VERSION | sed 's/"//g' `
>
> If there is also some problem with a sed treating " as a special
> character, you can always use character classes:
>
> MP_VERSION=`echo $MP_VERSION | sed 's/["]//g' `
>
> I generally find that avoid backslashes at all cost improves
> portability of scripts across broken shells/seds.
> --
> Deron Meranda
Re: bash bug (was Re: mod_python 3.2.7 available for testing)
Posted by Deron Meranda <de...@gmail.com>.
On 2/6/06, Jim Gallacher <jp...@jgassociates.ca> wrote:
> A couple of thoughts on this issue.
>
> According to the gentoo bug report quoted below, the problem in
> configure.in is the double backslash escape sequence in the line:
>
> MP_VERSION=`echo $MP_VERSION | sed s/\\"//g`
>
> Changing this to:
> MP_VERSION=`echo $MP_VERSION | sed s/\"//g`
>
>
> fixes it for bash 3.1. I wonder why we are using \\" since the gentoo
> fix seems to work ok with bash 3.0 (and GNU sed) on my system just as
> well. Is it there to support other shells, other sed versions, older
> bash versions... ??
>
> I suggest we either adopt the gentoo fix, or avoid the problem
> altogether by using tr. eg.
>
> MP_VERSION=`echo $MP_VERSION | tr -d '"'`
>
> I'm assuming tr is always available on UNIX-like systems.
Personally I prefer tr because it's more readable. But I don't know
it's availability outside Unix. You can try single-quoting the sed
expression and eliminationg the backslashes altogether:
MP_VERSION=`echo $MP_VERSION | sed 's/"//g' `
If there is also some problem with a sed treating " as a special
character, you can always use character classes:
MP_VERSION=`echo $MP_VERSION | sed 's/["]//g' `
I generally find that avoid backslashes at all cost improves
portability of scripts across broken shells/seds.
--
Deron Meranda