Running PHP via CLI

I made a php script with a HTML form (POST) which takes many options
and based on the options, it connects to a database file and create
some files from the results. This works fine when using a browser.

Now, I am being asked if it can run via CLI. My first reaction was
"no", but that was before I even had looked into the matter.
Running via CLI is preferred instead of having to install a webserver
solution like WAMP. Also, the target machine which should run the PHP
script is a standalone (no network of any kind).

After reading some about PHP in CLI mode, and experiments have I come
to this conclusion:
* php.exe does not support GET, POST or HTML codes (it will displayed
as raw text)
* php-cgi.exe does support GET but still not POST or HTML codes.
This means you can parse parameters to your php script, like: <php-cgi
path> -n -f <php script> para1=value1 para2=value2 etc. Full access to
$_GET.

I still have not found a way to run this script via CLI.

Do I need to re-write the whole thing specially for CLI mode ?
Is there another way to parse parameters via CLI mode ?

Kim wrote:
> I made a php script with a HTML form (POST) which takes many options
> and based on the options, it connects to a database file and create
> some files from the results. This works fine when using a browser.
>
> Now, I am being asked if it can run via CLI. My first reaction was

I assume you mean you are being asked to run it from the command line

> "no", but that was before I even had looked into the matter.
> Running via CLI is preferred instead of having to install a webserver
> solution like WAMP. Also, the target machine which should run the PHP
> script is a standalone (no network of any kind).

as opposed to having a nice web interface for it on a
standalone machine. As you probably know, you can
configure your browsers so that putting in word like
phpadmin into the address bar will redirect it to a
local file (instead of the web at large).

> After reading some about PHP in CLI mode, and experiments have I come
> to this conclusion:
> * php.exe does not support GET, POST or HTML codes (it will displayed
> as raw text)

Unclear what you mean by this. PHP will print out whatever you tell
it to. But if it's CLI (command line interface), then that output
goes to the command window, where of course it is not interpreted
as HTML. If you are writing script to output to two different types
of media, you need to accommodate both types. Adding <pre>...</pre>
tags is often an easy quick fix during testing when varying output
between the command window and the browser.

> * php-cgi.exe does support GET but still not POST or HTML codes.
> This means you can parse parameters to your php script, like: <php-cgi
> path> -n -f <php script> para1=value1 para2=value2 etc. Full access to
> $_GET.

Are you looking for something like this?

if (!$_SERVER['REQUEST_METHOD'])
foreach ($argv as $arg)
if ($pos=strpos($arg, "="))
$_POST[strtolower(substr($arg,0,$pos))] =
substr($arg,$pos+1);

> I still have not found a way to run this script via CLI.
>
> Do I need to re-write the whole thing specially for CLI mode ?
> Is there another way to parse parameters via CLI mode ?

Just make the $_POST et al. variable yourself.
It's useful to always include operating system configuration,
especially when asking about CLI.
Above code tested on Win XP Pro / PHP 5.2.4

Csaba Gabor from Vienna

Kim wrote:
> I made a php script with a HTML form (POST) which takes many options
> and based on the options, it connects to a database file and create
> some files from the results. This works fine when using a browser.
>
> Now, I am being asked if it can run via CLI. My first reaction was
> "no", but that was before I even had looked into the matter.
> Running via CLI is preferred instead of having to install a webserver
> solution like WAMP. Also, the target machine which should run the PHP
> script is a standalone (no network of any kind).
>
> After reading some about PHP in CLI mode, and experiments have I come
> to this conclusion:
> * php.exe does not support GET, POST or HTML codes (it will displayed
> as raw text)
> * php-cgi.exe does support GET but still not POST or HTML codes.
> This means you can parse parameters to your php script, like: <php-cgi
> path> -n -f <php script> para1=value1 para2=value2 etc. Full access to
> $_GET.
>
> I still have not found a way to run this script via CLI.
>
> Do I need to re-write the whole thing specially for CLI mode ?
> Is there another way to parse parameters via CLI mode ?


Running PHP from the command line (terminal window) requires that you
use php.cli (not php.cgi or php.exe). Well, it doesn't require it but
the point is that you cannot use the standard HTML FORMS for your input
and output. Please follow this link and read the whole page...

http://us.php.net/manual/en/features.commandline.php


---
Norm

Kim wrote:
> I made a php script with a HTML form (POST) which takes many options
> and based on the options, it connects to a database file and create
> some files from the results. This works fine when using a browser.
>
> Now, I am being asked if it can run via CLI. My first reaction was
> "no", but that was before I even had looked into the matter.
> Running via CLI is preferred instead of having to install a webserver
> solution like WAMP. Also, the target machine which should run the PHP
> script is a standalone (no network of any kind).
>
> After reading some about PHP in CLI mode, and experiments have I come
> to this conclusion:
> * php.exe does not support GET, POST or HTML codes (it will displayed
> as raw text)
> * php-cgi.exe does support GET but still not POST or HTML codes.
> This means you can parse parameters to your php script, like: <php-cgi
> path> -n -f <php script> para1=value1 para2=value2 etc. Full access to
> $_GET.
>
> I still have not found a way to run this script via CLI.
>
> Do I need to re-write the whole thing specially for CLI mode ?
> Is there another way to parse parameters via CLI mode ?


....and as a follow-up, you want want to look at ncurses for display and
user input purposes. It'll give you the DOS like application view. I've
not used it but I believe if you area on Windows it can a bit of a bear
(or may not work at all) but on Linux it seems to work just fine (using
ubuntu and installing php5 and ncurses via the package manager it works
out of the box.

Norm

Following up on my questions, and concerns.

I did re-write the script, stripped all HTML parts out and used php-
cgi.exe due to its possibility of using $_GET.
I do know I could just as easily have used $argv and $argc with
php.exe. Not sure if this also allows loading non-compiled modules
(either via php.ini or dl() PHP function) - I didnt check.

Re-wrote the code so it uses more functions and less "free" code
parts.

So the script ended up with being able to run via CLI after a little
re-writing.
Script runs successfully on target machine. Windows Server 2003 and
PHP 5.1.4.

Kim wrote:
> Following up on my questions, and concerns.
>
> I did re-write the script, stripped all HTML parts out and used php-
> cgi.exe due to its possibility of using $_GET.
> I do know I could just as easily have used $argv and $argc with
> php.exe. Not sure if this also allows loading non-compiled modules
> (either via php.ini or dl() PHP function) - I didnt check.
>
> Re-wrote the code so it uses more functions and less "free" code
> parts.
>
> So the script ended up with being able to run via CLI after a little
> re-writing.
> Script runs successfully on target machine. Windows Server 2003 and
> PHP 5.1.4.

Excellent!

Norm

> as opposed to having a nice web interface for it on a
> standalone machine. As you probably know, you can
> configure your browsers so that putting in word like
> phpadmin into the address bar will redirect it to a
> local file (instead of the web at large).

??

On window? How do you do that?

This would permit to show a php file with IExplorer without
Apache or else?

Jean Pierre Daviau wrote:
>> as opposed to having a nice web interface for it on a
>> standalone machine. As you probably know, you can
>> configure your browsers so that putting in word like
>> phpadmin into the address bar will redirect it to a
>> local file (instead of the web at large).
>
> ??

That's actually two distinct question marks for
two distinct questions, I suppose.

> On window? How do you do that?

First question...
Look at the file:
C:\Windows\System32\drivers\etc\hosts
You can then make a line like:
127.0.0.1 phpadmin
When you type phpadmin into the address bar of any
browser (such as phpadmin/myscript.php, you'll get
directed to localhost, but then it's up to the web
server to figure out what to do (but it need not
be accessible from the web) with your request (ie.
you can have a virtual domain)

> This would permit to show a php file with IExplorer without
> Apache or else?

Now this is the harder question (in my opinion).
Good news, bad news. The good news is that it's
possible. The bad news is that the setup is
non trivial. Better to use apache locally.

However, if your religion prevented you from
installing a web server, then you might think to
create a local .htm file whose only job was to
run your php script through php-cgi.exe, say,
then collect the output and then blat it out
to web browser.

But this is not a nice solution because for every
php file you would have to create a separate
..htm file that called the .php file and then you
wouldn't be typing in c:\mypath\myscript.php
anymore, you'd be putting in c:\mypath\myscript.htm
Of course you could put everything into myscript.php
properly wrapped and escaped, but this is really
no longer a nice .php script file anymore.

There is a second approach which is more fruitful,
I think. Put a handler into a dummy page that you
start up with so that when you would navigate away
to another page, if that new page is a local .php
script, then the navigation is aborted, the .php
script is run, the output is collected, and then
the document is replaced. As far as I can figure,
however, you can't get to the url that you would be
navigating to through js, so a window.onbeforeunload
won't work.

However, the appropriate events can be hooked and
handled in ie itself, as opposed to the window or
document object, but the scope of that is beyond
this post. As I say, better to have the web
server run locally.

Csaba Gabor from Vienna