httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: configure bug
Date Wed, 22 Apr 1998 07:33:54 GMT

In article <> you wrote:
>> 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.

Oh, you are right, _THIS_ IFS='<cr>' _WAS_ a bug. Correct. With the patch it
now reads  (DIFS='<space><tab><cr>'):

  for apc_option

which will fix this. Any votes on the patch from the posting?

                                       Ralf S. Engelschall

View raw message