[: -le: argument expected

[Jeremy Chadwick]

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 |