Thank you Jason... really!
    Now I begun to let it work a little...
I found also, searching about the variables you said me in the sources, that
if I enable the configure option "--enable-discard-path", the variables are
not more needed, and the php begin to works!!!!! WOW!
So, I say it begins to work, because I've jumped into a well known bug, that
let alwasy displays "#!/usr/local/bin/php" at the beginning of the php
output... this can cause problems also with additional headers, that cannot
be sent...

is there a way to let this "#!/usr/local/bin/php" exit from php door...
isn't it ?!?
can be also this solved passing some variables ? Anyway, this
"#!/usr/local/bin/php"  is displayed both from command line and from a "not
too friendly" webmin environment...

thank you very much,
    prakash


> First off, you are correct in mailing this problem to php-dev, as the
> follow information is not documented.
>
> Your problem is most likey due to the fact, that webmin does set one of
> the following environment variables:
>
> SERVER_SOFTWARE
> SERVER_NAME
> GATEWAY_INTEFACE
> REQUEST_METHOD
>
> Currently the PHP CGI SAPI tries to determine if it is getting called by
> a webserver or by the command line. This is problematic, as you have
> seen. Due to these problems, a new CLI SAPI is being implemented, for
> all general purpose scripting, and I would highly recommend switching to
> such SAPI.
>
> Basicly, your problem is caused by the fact that the cgi sapi has
> detected that it is being called by a webserver by looking at the
> previously mentioned environment variables, and noticing that one of
> them haa a value.
>
> The UNIX shebang( #! ) just passses the script your are executing (in
> your case bbb.cgi) as an argument. When the CGI SAPI has detected it is
> being called by a webserver, it ignores all parameters.
>
> Instead, it determines which script to run by extracting it from the
> following environment variables (depending on your configuration):
>
> PATH_TRANSLATED
> SCRIPT_FILENAME
>
> You have three possible workarounds:
> 1. Unset the 4 defined env vars before executing bbb.cgi
> 2. Set PATH_TRANSLATED and SCRIPT_FILENAME to point to bbb.cgi
> 2. Create a wrapper script, as you have already done
>
> I Hope this clears up your problem.
>
> --
> Jason T. Greene
> Internet Software Engineer
>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
> Use PHP: http://www.php.net
>
>
>
> On Sat, 2002-01-26 at 04:04, Prakash wrote:
> > Hi,
> >     I'm trying to execute a Webmin script where I can use php as
scripting
> > language... (It will be good to work with a language as php in a remote
> > administration server, as root! potentially dangerous but good!)
> >
> > Now the STRANGE problem: (seems to be some env variables (maybe I'm
wrong)
> > when executing PHP as CGI...)
> >
> > When I execute a test.cgi program from Webmin, it's executed as root, as
it
> > was from command line... that's good. The problem is that Webmin execute
> > well _every_ program I tried , EXCEPT php !
> >
> > It seems that php needs some env variables to work well, and these
variables
> > aren't provided from the Webmin interface, so to solve the problem I've
> > first to understand WHY php does not work...
> >
> > ---------------------
> >
> > Maybe I can better explain with 2 samples:
> >
> > > file aaa.cgi
> > >
> > >     #!/bin/bash
> > >     echo "Content-type: text/plain"
> > >     echo
> > >     echo "aaa"
> > >     touch /home/test.txt
> >
> > > file bbb.cgi
> > >
> > >     #!/usr/local/bin/php -q
> > >     <?php
> > >         echo "Content-type: text/plain\n\n";
> > >         echo "aaa\n";
> > >         $fd = fopen("/home/test.txt","w");
> > >         fclose($fd);
> > >     ?>
> >
> > Now, the 2 programs are quite the same... (if test.txt does not
exist...)
> > But, the 2 programs behave the same way only if you execute them _from
> > command line_.
> > If you execute them from the Webmin interface (very good for remote
> > administration, that lets execute programs as user root), they behave
> > differently:
> > aaa.cgi is the same, displays "aaa" on the remote web-browser, and
creates
> > (well, if text.txt doesn't exist) a local file.
> > bbb.cgi does nothing, sends no http headers, no aaa, and does not create
the
> > file...
> >
> > It seems that PHP needs some env variables, and without them, it
suddenly
> > stops without parsing the file... am I right ?!?
> >
> > I've also tried to escape from this problem (until understood and
solved)
> > with a third program:
> >
> > > file ccc.cgi
> > >
> > >     #!/bin/bash
> > >     /usr/bin/at -f /path/bbb.cgi now+1minute
> > >     touch /home/test2.txt
> >
> > If I call ccc.cgi from Webmin and then from command line, the 2
executions
> > are scheduled properly, and look really the same (root user,same
> > program,...) but the task scheduled from Webmin is not executed
> > properly...
> > the php seems to stop with no output.
> >
> > Also with a file like this:
> >
> > > file ddd.cgi
> > >
> > >     #!/bin/bash
> > >     /path/bbb.cgi 2>&1 > test3.txt
> >
> > show that php really has no output on stdout or stderr (bbb.cgi is the
IInd
> > file, and test3.txt is created, but 0 bytes long when invoked from
Webmin!)
> >
> > So, the BIG problem is: if Webmin can execute all programs, running them
as
> > root, WHY doesn't work well with php scripts ?!?
> > I think that the PHP need something, and not having it it suddenly
stops...
> > but what ?!?
> >
> > Are there some developer that can help ?!?
> >
> > (Writing Webmin modules in perl is not good, if you work mainly with
php,
> > and webmin can be the best remote administration utility...)
> >
> > thanks to all,
> >      waiting for some news...
> > prakash
> >
> >
> >
> > --
> > 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]

Reply via email to