httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ras...@lerdorf.on.ca (Rasmus Lerdorf)
Subject Re: configure bug
Date Wed, 22 Apr 1998 07:18:23 GMT
> No, it is ok at these places, because the for-loop iterates over the result of
> "grep" and should get one line per iteration. Hmmm.. but you are right, we
> should restore the IFS correctly at any point, i.e. we should really be
> paranoid here because wrong IFS can cause a lot of trouble inside braindead
> Bourne-Shell variants. How about the appended "maximum-paranoid" patch?

I wasn't saying this on a theoretical level.  I had an APACI install fail
on me on a Linux box because the IFS was set to only IFS='<cr>'.  It was
the one on line 225 in the command line options parsing.  I had 
--prefix=/whatever --activate-module=src/modules/php3/libphp3.a
all on the same line and the generated apaci script was completely messed
up.  In src/apaci I got:

echo '-DHTTPD_ROOT="/whatever --activate-module=..."'
echo '-DSUEXEC_BIN="/whatever --activate-module=.../sbin/suexec"'
echo '-DSHARED_CORE_DIR="/whatever --activate-module=.../libexec"'

Changing line 225 to have IFS='<space><tab><cr>' fixed the problem for me.

Granted, I can't reproduce this bug on a Solaris box, and the Linux box I
had this problem on is running bleeding-edge version of the kernel, bash
and just about everything else you can imagine.

-Rasmus


Mime
View raw message