From owner-freebsd-apache@FreeBSD.ORG Fri Feb 1 19:11:57 2008 Return-Path: Delivered-To: freebsd-apache@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44CDE16A41A for ; Fri, 1 Feb 2008 19:11:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 31F7B13C4E3 for ; Fri, 1 Feb 2008 19:11:57 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 4BBCB1CC05F; Fri, 1 Feb 2008 10:52:33 -0800 (PST) Date: Fri, 1 Feb 2008 10:52:33 -0800 From: Jeremy Chadwick To: "Chris H." Message-ID: <20080201185233.GA72487@eos.sc1.parodius.com> References: <20080131184116.ennj4jbvw480ws8s@webmail.1command.com> <1201863996.2975.27.camel@localhost> <20080201074213.93ievskew4wgsgg4@webmail.1command.com> <1201885283.2975.56.camel@localhost> <20080201101814.eyq71kiqo084gck8@webmail.1command.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080201101814.eyq71kiqo084gck8@webmail.1command.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Tom Evans , freebsd-apache@freebsd.org, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org, Pete French Subject: Re: [: -le: argument expected X-BeenThere: freebsd-apache@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Support of apache-related ports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2008 19:11:57 -0000 On Fri, Feb 01, 2008 at 10:18:14AM -0800, Chris H. wrote: > I wanted to sync up my ports database before hand. So ran a portsdb -uU. > This - interestingly enough, resulted in both [: -le: argument expected, > and [: -eq: argument expected being emitted /many/ times during the portsdb > process. So, now I'm stumped. It is clear that it is /not/ specific to the > php5-apache-module. But rather, something that is common to that, and other > ports. It's clear that /bin/[ is the command complaining. But my guess is > that something else is triggering it - perl perhaps? Don't know, and ATM > don't know how to find out, or what to try next. :( Some educational history and points: /bin/[ is the same thing as /bin/test (one might be a hardlink, I can't remember). If you've ever seen an sh script, you'll see a lot of this: if [ x"$o" = x"hello" ]; then ... fi Which is identical to: if test x"$o" = x"hello"; then ... fi There's some important things to note about this, though. Many shells (such as bash) include their own internal version of test, which is wise because it saves on having to fork a /bin/[ or /bin/test process every time something wanted to run a comparison operation. test(1) describes the applicable comparison operators (=, !=, -gt, -le, etc.). > [: -le: argument expected This means something somewhere is doing: if [ val1 -le $val2 ]; then ... fi I'm willing to bet val2 is a variable which isn't being set prior to the test conditional being run, which would mean the test conditional would be expanded by the shell into this: if [ val1 -le ]; then ... fi Which is going to emit the error in question. To confirm that the problem is coming from a /bin/sh script (or something that actually uses /bin/[ or /bin/test, versus, say, a bash shell script which uses bash's internal [/test), we can do this: icarus$ /bin/sh # if [ 123 -le ]; then echo hi; fi [: -le: argument expected # if test 123 -le; then echo hi; fi test: -le: argument expected Note the difference if [ or test is used within bash: bash# if [ 123 -le ]; then echo hi; fi -bash: [: 123: unary operator expected bash# if test 123 -le; then echo hi; fi -bash: test: 123: unary operator expected What all this means: the error is being induced by a /bin/sh script of somekind. That said, the added fact that "make extract" causes this for you means that the error is coming from something within the ports framework, which means something in ports/Mk. This sort-of thing has happened in the past, and has occasionally turned out to be caused someone having some very bad typos in /etc/make.conf which broke all sorts of things. > make emits the above, as well as the following: > > configure.in:152: warning: AC_PROG_LEX invoked multiple times > ../../lib/autoconf/programs.m4:779: AC_DECL_YYTEXT is expanded from... > aclocal.m4:2080: PHP_PROG_LEX is expanded from... > configure.in:152: the top level Second time someone's told you -- this is normal based on the current autoconf framework in ports. I've complained about this to ale@ in the past, but was told "if it bothers you that much, fix it; it's harmless otherwise". And being as I have dealt with similar autoconf warnings in ports that *I* maintain, I can tell you that getting them to not emit such warnings is a real pain in the ass. > config.status: executing default commands > ===> Building for php5-5.2.5_1 > "Makefile", line 592: warning: duplicate script for target > "main/internal_functions.lo" ignored Also "normal". > -I/usr/ports/lang/php5/work/php-5.2.5/Zend -O2 -fno-strict-aliasing > -pipe -prefer-non-pic -c > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c -o > sapi/apache/sapi_apache.lo > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c: In function > 'apache_php_module_main': > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > 'NOT_FOUND' undeclared (first use in this function) > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > (Each undeclared identifier is reported only once > /usr/ports/lang/php5/work/php-5.2.5/sapi/apache/sapi_apache.c:44: error: > for each function it appears in.) > *** Error code 1 Hmm, this looks like there could be two versions of Apache APR on your machine (one from the www/apache20 port, and possibly some other port installing something similar to devel/apr on the same box). This could also be induced by something broken in /etc/make.conf, but it's hard to tell. It's getting to the point where for someone to help you with this, they're going to need access to the machine. I can't reproduce this behaviour on any of my personal FreeBSD boxes, nor any of our production machines (running RELENG_6 and RELENG_7), and I haven't seen anyone else on this list able to reproduce the symptom either. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |