The test case:
tmain.c
=====
int main(int argc, char *argv[])
{
int i;
for (i=0; i<argc; i++)
printf ("argv[%d]=%s\n", i, argv[i]);
}
tmain.sh
======
#!./tmain -a -b /some/testest/path -A -q
Blah, blash
Compile tmain.c and then run ./tmain.sh. On my linux box I get:
argv[0]=tmain
argv[1]=-a -b /some/testest/path -A -q
argv[2]=./tmain.sh
On a freebsd machine I get:
argv[0]=./tmain
argv[1]=-a
argv[2]=-b
argv[3]=/some/testest/path
argv[4]=-A
argv[5]=-q
argv[6]=./tmain.sh
On bothe machines I use bash. Therefore my conclusion was that this was
probably a glibc problem.
Edin
----- Original Message -----
From: "J Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 10, 2002 12:36 AM
Subject: [PHP-DEV] Re: Bug #14930 Updated: CLI header suppression problems
> Ack, didn't mean to hit that send button yet!
>
> I wrote this while experimenting, and it seems that just when I thought I
> had it, I didn't, of course, but I sent this to the list anyways,
> accidentally.
>
> At first I thought I was golden, because my little fix did work... so long
> as you didn't have anything after your -c argument. Of course, try doing
> something like this:
>
> #!/usr/local/bin/php -c /some/path -q
>
> And your script dies, or at least it can't find the php.ini file, because
> it thinks that the path should be "-c /some/path -q". Argh.
>
> Let me get back on this in a bit, I'll fix it next time, really.
>
> J
>
>
>
> J Smith wrote:
>
> >
> > Here's what I can tell so far:
> >
> > the arguments do get passed to cgi_main.c's main() function just fine,
and
> > the arguments are even parsed okay. The problem seems to occur because
> > when the arguments are parsed from a script like so:
> >
> > #!/usr/bin/php -c /path/to/ini/file
> > <?php
> > ...
> > ?>
> >
> > it seems that there's at least one leading space in the argument to
the -c
> > option, i.e. in sapi/cgi/cgi_main.c,
cgi_sapi_module.php_ini_path_override
> > is set to " /path/to/ini/file" instead of "/path/to/ini/file". This in
> > turn ends up confusing php_init_config() in main/php_ini.c, and although
> > it will return SUCCESS (as the file isn't found thanks to the leading
> > spaces), which is okay because the defaults are used instead, and no
> > warning or error is given about not being able to find php.ini in "
> > /path/to/ini/file".
> >
> > I didn't catch this until about an hour ago, but all of my CLI PHP
scripts
> > were relying on default settings rather than the ones I had set in
> > "/usr/local/zend/etc/cli/php.ini", or as far as php_init_config() was
> > concerned, said file with a leading space.
> >
> > A quick fix for the problem would be to trim off those leading spaces to
> > the argument to -c, but I'm not sure if that wouldn't cause more
problems
> > in the long run. For instance, is it possible to have leading spaces in
> > directory names on some operating systems? It's not a problem for me,
and
> > it probably wouldn't be a huge problem overall, but if there's a chance
> > guaranteed it will affect somebody.
> >
> > Anyways, quick solution, very in-elegant and probably not very safe (but
> > it worked, so at least it proves I'm somewhat right on this) was to
stick
> > the following bit of code (my additions prefixed with >):
> >
> > if (php_ini_path_override) {
> > php_ini_search_path = php_ini_path_override;
> >> while (php_ini_search_path[0] == ' ') {
> >> for (i = 0; i < strlen(php_ini_search_path); i++) {
> >> php_ini_search_path[i] = php_ini_search_path[i + 1];
> >> }
> >> }
> > free_ini_search_path = 0;
> > }
> >
> > in main/php_ini.c. Strips out the leading spaces and lets my scripts
work
> > properly again, with the proper php.ini settings.
> >
> > Comments?
> >
> > J
> >
> >
> >
> >
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
