Re: [Mailman-Users] mailman install problems (syntax error at line 1: `; ' unexpected)
On Thu, August 5, 2010 07:14, CJ Keist wrote:
Hi, Trying to install mailman mailman-2.1.13rc on Solaris 10x86. Getting an error when I try to do make install. I found similar post on this error on making sure using correct version of python. I have two version of python installed, there is the native python that comes with Solaris, version 2.4.6, and then I installed a newer version from Blastwave 2.6.2. It doesn't matter what version I use, still get same error with make install.
setenv PATH /usr/bin:/usr/sbin:/opt/csw/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/sfw/bin [SNIP]
Don't do this stuff in csh, use sh or bash.
Set your path so that Blastwave/OpenCSW is searched first: PATH=/opt/csw/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/usr/openwin/bin:/usr/sfw/bin export PATH
Cheers,
Gary B-)
Thanks for the reply. See below for the solution I found.
On 8/5/10 10:10 PM, Gary R. Schmidt wrote:
On Thu, August 5, 2010 07:14, CJ Keist wrote:
Hi, Trying to install mailman mailman-2.1.13rc on Solaris 10x86. Getting an error when I try to do make install. I found similar post on this error on making sure using correct version of python. I have two version of python installed, there is the native python that comes with Solaris, version 2.4.6, and then I installed a newer version from Blastwave 2.6.2. It doesn't matter what version I use, still get same error with make install.
setenv PATH /usr/bin:/usr/sbin:/opt/csw/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/sfw/bin
[SNIP]
Don't do this stuff in csh, use sh or bash.
I did try running in both sh and bash but still got same error. But I did get mailman to install. The problem was with the Makefile in the misc folder.
EMAILPKG= JACODECSPKG= KOCODECSPKG=
PACKAGES= $(EMAILPKG) $(JACODECSPKG) $(KOCODECSPKG)
There were no packages defined. Does this mean I didn't run configure correctly? I simply commented out the for p loop:
#for p in $(PACKAGES); \
#do \
#gunzip -c $(srcdir)/$$p.tar.gz | (cd $(PKGDIR) ; tar xf -); \
#(cd $(PKGDIR)/$$p ; umask 02 ; PYTHONPATH=$(PYTHONLIBDIR) $(PYTHON)
$(SETUPCMD));
#done
This got mailman installed and looks to be working okay.
Set your path so that Blastwave/OpenCSW is searched first: PATH=/opt/csw/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/usr/openwin/bin:/usr/sfw/bin export PATH
Cheers, Gary B-)
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/cj.keist%40colostate.ed...
-- C. J. Keist Email: cj.keist@colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
CJ Keist wrote:
I did try running in both sh and bash but still got same error. But I did get mailman to install. The problem was with the Makefile in the misc folder.
EMAILPKG= JACODECSPKG= KOCODECSPKG=
PACKAGES= $(EMAILPKG) $(JACODECSPKG) $(KOCODECSPKG)
There were no packages defined. Does this mean I didn't run configure correctly?
No, it means that configure found suitable email and Korean and Japanese codecs packages in the installed Python and thus didn't need to install the ones that ship with Mailman.
I simply commented out the for p loop:
#for p in $(PACKAGES); \ #do \ #gunzip -c $(srcdir)/$$p.tar.gz | (cd $(PKGDIR) ; tar xf -); \ #(cd $(PKGDIR)/$$p ; umask 02 ; PYTHONPATH=$(PYTHONLIBDIR)$(PYTHON) $(SETUPCMD));
#doneThis got mailman installed and looks to be working okay.
That is a perfectly acceptable workaround, but the question is why doesn't your make properly handle
for p in ; do ... ; done
and treat it effectively as a no-op when the for list is empty?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
CJ Keist wrote:
I simply commented out the for p loop:
#for p in $(PACKAGES); \
That is a perfectly acceptable workaround, but the question is why doesn't your make properly handle
for p in ; do ... ; done
Because make doesn't (shouldn't) do anything with commands except substitute make variables, then pass them to the shell. Bourne shells require the tokens following "in" to constitute a list. The idiom for an empty list is the empty string.
One way to handle this in GNU Make is
ifeq($(PACKAGES),) PACKAGES = "" endif
(Untested, IIRC -- the point is that make doesn't care about the quotation marks at all, so it passes the literal string '""' to the shell as the value of the make variable PACKAGES.)
Stephen J. Turnbull wrote:
Mark Sapiro writes:
CJ Keist wrote:
I simply commented out the for p loop:
#for p in $(PACKAGES); \That is a perfectly acceptable workaround, but the question is why doesn't your make properly handle
for p in ; do ... ; done
Because make doesn't (shouldn't) do anything with commands except substitute make variables, then pass them to the shell. Bourne shells require the tokens following "in" to constitute a list. The idiom for an empty list is the empty string.
One way to handle this in GNU Make is
ifeq($(PACKAGES),) PACKAGES = "" endif
(Untested, IIRC -- the point is that make doesn't care about the quotation marks at all, so it passes the literal string '""' to the shell as the value of the make variable PACKAGES.)
I agree that the underlying issue is with the shell, but in at least these bash versions:
GNU bash, version 3.2.49(22)-release (i686-pc-cygwin)
GNU bash, version 3.2.48(1)-release (i386-apple-darwin10.0)
GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
the construct
for p in ; do echo Huh? $p ; done
is accepted and does nothing. Further, since 2.1.12, the 'normal' value of PACKAGES in this Makefile is null, and this is the first report of this problem I've seen.
If there are in fact versions of sh/bash that don't accept the "for p in ;" construct, then I'd like to fix this in the Makefile, but I'd like to have a way to a) see the failure, and b) test the fix.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
If this helps. I'm on Solaris 10 10/09 s10s_u8wos_08a SPARC. This make installed failed with
tcsh - version 6.12.00 bash - version 3.00.16(1)
As for bourne shell, don't know how to get the version info.
On 8/7/10 9:13 AM, Mark Sapiro wrote:
Stephen J. Turnbull wrote:
Mark Sapiro writes:
CJ Keist wrote:
I simply commented out the for p loop:
#for p in $(PACKAGES); \That is a perfectly acceptable workaround, but the question is why doesn't your make properly handle
for p in ; do ... ; doneBecause make doesn't (shouldn't) do anything with commands except substitute make variables, then pass them to the shell. Bourne shells require the tokens following "in" to constitute a list. The idiom for an empty list is the empty string.
One way to handle this in GNU Make is
ifeq($(PACKAGES),) PACKAGES = "" endif
(Untested, IIRC -- the point is that make doesn't care about the quotation marks at all, so it passes the literal string '""' to the shell as the value of the make variable PACKAGES.)
I agree that the underlying issue is with the shell, but in at least these bash versions:
GNU bash, version 3.2.49(22)-release (i686-pc-cygwin)
GNU bash, version 3.2.48(1)-release (i386-apple-darwin10.0)
GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
the construct
for p in ; do echo Huh? $p ; done
is accepted and does nothing. Further, since 2.1.12, the 'normal' value of PACKAGES in this Makefile is null, and this is the first report of this problem I've seen.
If there are in fact versions of sh/bash that don't accept the "for p in ;" construct, then I'd like to fix this in the Makefile, but I'd like to have a way to a) see the failure, and b) test the fix.
-- C. J. Keist Email: cj.keist@colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
----- Original Message ---------------
Subject: Re: [Mailman-Users] mailman install problems (syntax error atline1:`; ' unexpected) From: CJ Keist <cj.keist@ColoState.EDU> Date: Sat, 07 Aug 2010 09:25:19 -0600 To: Mark Sapiro <mark@msapiro.net> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>, mailman-users@python.org
If this helps. I'm on Solaris 10 10/09 s10s_u8wos_08a SPARC. This make installed failed with
tcsh - version 6.12.00
It can't be using tcsh because there is no 'for' at all in tcsh.
bash - version 3.00.16(1)
As for bourne shell, don't know how to get the version info.
Bourne shell is sh, but on most systems with bash, sh is just a link to bash (Bourne again shell).
What does
bash -c 'for p in ; do echo Huh? $p ; done'
do?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Another update. It looks to be a make problem. The make I used was in /usr/ccs/bin. Using GNU make, in /usr/sfw/bin ran just fine.
On 8/7/10 10:26 AM, Mark Sapiro wrote:
----- Original Message ---------------
Subject: Re: [Mailman-Users] mailman install problems (syntax error atline1:`; ' unexpected) From: CJ Keist<cj.keist@ColoState.EDU> Date: Sat, 07 Aug 2010 09:25:19 -0600 To: Mark Sapiro<mark@msapiro.net> Cc: "Stephen J. Turnbull"<stephen@xemacs.org>, mailman-users@python.org
If this helps. I'm on Solaris 10 10/09 s10s_u8wos_08a SPARC. This make installed failed with
tcsh - version 6.12.00
It can't be using tcsh because there is no 'for' at all in tcsh.
bash - version 3.00.16(1)
As for bourne shell, don't know how to get the version info.
Bourne shell is sh, but on most systems with bash, sh is just a link to bash (Bourne again shell).
What does
bash -c 'for p in ; do echo Huh? $p ; done'
do?
-- C. J. Keist Email: cj.keist@colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
Running the bash command came back to the prompt with no errors.
On 8/7/10 10:26 AM, Mark Sapiro wrote:
bash -c 'for p in ; do echo Huh? $p ; done'
-- C. J. Keist Email: cj.keist@colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301
All I want is a chance to prove 'Money can't buy happiness'
CJ Keist wrote:
Running the bash command came back to the prompt with no errors.
On 8/7/10 10:26 AM, Mark Sapiro wrote:
bash -c 'for p in ; do echo Huh? $p ; done'
That's the expected result.
Per your immediately previous post, it seems the issue was some incompatibility with a specific (non-GNU) make. Instead of commenting the offending portion of the makefile, we could (expanding on Stephen's suggestion) make it
ifneq ($(strip $(PACKAGES)),)
for p in $(PACKAGES);
do
gunzip -c $(srcdir)/$$p.tar.gz | (cd $(PKGDIR) ; tar xf -);
(cd $(PKGDIR)/$$p ; umask 02 ; PYTHONPATH=$(PYTHONLIBDIR)
$(PYTHON) $(SETUPCMD));
done
endif
however, the ifneq ... endif is a GNU make construct and that itself may not work in non-GNU makes.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, 7 Aug 2010, Mark Sapiro wrote:
I agree that the underlying issue is with the shell, but in at least these bash versions:
GNU bash, version 3.2.49(22)-release (i686-pc-cygwin)
GNU bash, version 3.2.48(1)-release (i386-apple-darwin10.0)
GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
the construct
for p in ; do echo Huh? $p ; done
is accepted and does nothing.
You can add to that:
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) (running on Debian Lenny)
GNU bash, version 4.0.38(1)-release (x86_64-redhat-linux-gnu) (running on Fedora 12)
GNU bash, version 3.2.25(1)-release (i686-redhat-linux-gnu) (running on CentOS 5.5)
These are all the different ones I had access to.
Geoff.
Mark Sapiro writes:
I agree that the underlying issue is with the shell, but in at least these bash versions:
GNU bash, version 3.2.49(22)-release (i686-pc-cygwin)
GNU bash, version 3.2.48(1)-release (i386-apple-darwin10.0)
GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
the construct
for p in ; do echo Huh? $p ; done
OK, I must be remembering *very* old versions of bash or something.
FWIW, dash 0.5.5, bash 4.0.1, and zsh 4.3.4 all behave as you say, too. If dash does it, I'd guess it's POSIX-ly correct, since dash is pretty minimal by design.
participants (5)
-
CJ Keist -
Gary R. Schmidt -
Geoff Shang -
Mark Sapiro -
Stephen J. Turnbull