| Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172075] |
Sun, 30 January 2011 03:09  |
P E Schoen
Messages: 86
Registered: January 2011
Karma: 0
|
Member |
|
|
I have made much progress converting my working Perl script to the
equivalent in PHP. Mostly I used the -l lint switch from the command line
interface on my localhost Apache server, and I was able to pass the syntax
check. Then I ran the script using a batch file with command line arguments
as CGI variables, but they do not seem to be read into the $_POST array. My
batch file is as follows:
C:\xampp\php\php-cgi eventprocessor.php --
Full_Name="MyName";Email="MyEmail"; ...
I am attempting to read the variables as
$in = $_POST ; // Get the CGI input variables
echo("Name: " . $_POST["Full_Name"] . "\n");
echo("Name: " . $in[Full_Name] . "\n");
echo("Name: " . $argv[2] . "\n");
This is essentially what I used for the Perl script and it works fine. The
last line above echoes the entire set of CGI variables (since there are no
spaces), and #argv[1] is just "--". I also used the command line
eventprocessor.php < CGIVARS.txt, but that did not work.
This did not seem to help:
http://php.net/manual/en/features.commandline.options.php
I should be able to use an HTML form and use POST to run the script, but
there should be a way directly from the CLI as there was for Perl.
So far I have found PHP much easier to use than Perl, so if I can get past
this hurdle I will be well on my way to make a determination as to what
language I will use for scripting.
Thanks,
Paul
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172076 is a reply to message #172075] |
Sun, 30 January 2011 03:49  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/29/2011 10:09 PM, P E Schoen wrote:
> I have made much progress converting my working Perl script to the
> equivalent in PHP. Mostly I used the -l lint switch from the command
> line interface on my localhost Apache server, and I was able to pass the
> syntax check. Then I ran the script using a batch file with command line
> arguments as CGI variables, but they do not seem to be read into the
> $_POST array. My batch file is as follows:
>
> C:\xampp\php\php-cgi eventprocessor.php --
> Full_Name="MyName";Email="MyEmail"; ...
>
> I am attempting to read the variables as
>
> $in = $_POST ; // Get the CGI input variables
> echo("Name: " . $_POST["Full_Name"] . "\n");
> echo("Name: " . $in[Full_Name] . "\n");
> echo("Name: " . $argv[2] . "\n");
>
> This is essentially what I used for the Perl script and it works fine.
> The last line above echoes the entire set of CGI variables (since there
> are no spaces), and #argv[1] is just "--". I also used the command line
> eventprocessor.php < CGIVARS.txt, but that did not work.
>
> This did not seem to help:
> http://php.net/manual/en/features.commandline.options.php
>
> I should be able to use an HTML form and use POST to run the script, but
> there should be a way directly from the CLI as there was for Perl.
>
> So far I have found PHP much easier to use than Perl, so if I can get
> past this hurdle I will be well on my way to make a determination as to
> what language I will use for scripting.
>
> Thanks,
>
> Paul
Paul, unfortunately the $_POST array is set up by the php web interface,
not the CLI (and argv/argc are set up by the CLI and not the web
interface, by default).
I normally test on my local web server; you could do a quick test of the
code by wrapping it in a quick interface which fills in the value, but
that still won't show you the formatted output (or even determine if the
$_POST variables are set up properly.
Best is still to have a local development web site which closely mimics
that of your production server (i.e. similar versions of PHP, MySQL,
etc.) and test on it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172077 is a reply to message #172076] |
Sun, 30 January 2011 04:41 |
P E Schoen
Messages: 86
Registered: January 2011
Karma: 0
|
Member |
|
|
"Jerry Stuckle" wrote in message
news:ii2n55$rhu$1(at)news(dot)eternal-september(dot)org...
> Paul, unfortunately the $_POST array is set up by the php web
> interface, not the CLI (and argv/argc are set up by the CLI and
> not the web interface, by default).
> I normally test on my local web server; you could do a quick test
> of the code by wrapping it in a quick interface which fills in the
> value, but that still won't show you the formatted output (or even
> determine if the $_POST variables are set up properly.
> Best is still to have a local development web site which closely
> mimics that of your production server (i.e. similar versions of
> PHP, MySQL, etc.) and test on it.
I just made a simple HTML file as follows:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>
NEW Test for CLI CGI vars</title>
</head><body>
CGI test
<form id="Form1" action="http://localhost/cgi-bin/EventProcessor.php"
method="POST">
<input type="hidden" name="Full_Name" value="MyName">
<input type="hidden" name="Email" value="MyEmail">
<input type="hidden" name="Reference" value="MyPWD">
<script language = "Javascript">
Form1.submit();
</script></body></html>
But now I have a problem with SQLite3 (from
http://www.php.net/manual/en/sqlite3.open.php):
$dbfile = 'C:/xampp/cgi-bin/SCGBG_Data.db'; //I tried with the file
in place and deleted
class MyDB extends SQLite3
{
function __construct()
{
$this->open($dbfile); //This is line 184
}
}
$db = new MyDB();
I get this error:
Fatal error: Uncaught exception 'Exception' with message 'Unable to expand
filepath' in C:\xampp\cgi-bin\EventProcessor.php:184 Stack trace: #0
C:\xampp\cgi-bin\EventProcessor.php(184): SQLite3->open('') #1
C:\xampp\cgi-bin\EventProcessor.php(188): MyDB->__construct() #2 {main}
thrown in C:\xampp\cgi-bin\EventProcessor.php on line 184
I originally used the older SQLite functions but the database I was using in
Perl was SQLite3, and it worked OK, but with much different syntax.
my $dbfile = "../SCGBG/SCGBG_Data.db";
my $db = DBI->connect( # connect to your database, create if needed
"dbi:SQLite:dbname=$dbfile", # DSN: dbi, driver, database file
...
$db->do("CREATE TABLE tEntries (
eid INTEGER UNIQUE PRIMARY KEY, etype TEXT,
et TEXT, eurl TEXT,
sdt DATETIME KEY, sdow TEXT,
edt DATETIME, edow TEXT,
ed TEXT)");
Any ideas? Or should I switch to MySQL?
Thanks,
Paul
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172078 is a reply to message #172077] |
Sun, 30 January 2011 07:06 |
P E Schoen
Messages: 86
Registered: January 2011
Karma: 0
|
Member |
|
|
This is what I had:
$dbfile = 'C:/xampp/cgi-bin/SCGBG_Data.db';
class MyDB extends SQLite3
{
function __construct()
{
$this->open($dbfile); //This is line 184
}
}
$db = new MyDB();
I got this error:
Fatal error: Uncaught exception 'Exception' with message 'Unable to expand
filepath' in C:\xampp\cgi-bin\EventProcessor.php:184 Stack trace: #0
C:\xampp\cgi-bin\EventProcessor.php(184): SQLite3->open('') #1
C:\xampp\cgi-bin\EventProcessor.php(188): MyDB->__construct() #2 {main}
thrown in C:\xampp\cgi-bin\EventProcessor.php on line 184
So I changed it to use the literal filename:
$this->open('SCGBG_Data.db');
And that worked!
I think I'm almost there...
Paul
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172079 is a reply to message #172078] |
Sun, 30 January 2011 10:00 |
Felix Saphir
Messages: 8
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
P E Schoen <paul(at)pstech-inc(dot)com> wrote:
> This is what I had:
>
> $dbfile = 'C:/xampp/cgi-bin/SCGBG_Data.db';
> class MyDB extends SQLite3
> {
> function __construct()
> {
$dbfile is unknown to this function, it's not in scope. You could
declare it as global here, but your best choice is to pass the
filename as parameter to __construct(): Change the declaration to
public function __construct($filename)
{
> $this->open($dbfile); //This is line 184
$this->open($filename);
> }
> }
>
> $db = new MyDB();
$db = new MyDB($dbfile);
BTW it's all in the manual ...
Felix
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172092 is a reply to message #172079] |
Sun, 30 January 2011 19:13 |
P E Schoen
Messages: 86
Registered: January 2011
Karma: 0
|
Member |
|
|
"Felix Saphir" wrote in message news:ii3cse$1n2$02$1(at)news(dot)t-online(dot)com...
> $dbfile is unknown to this function, it's not in scope. You could
> declare it as global here, but your best choice is to pass the
> filename as parameter to __construct():
I changed it as you suggested:
$dbfile = 'SCGBG_Data.db'; // In global space
class MyDB extends SQLite3
{
public function __construct($filename)
{
$this->open($filename);
}
}
$db = new MyDB($dbfile);
It fails with the same error. I also tried:
$db = new SQLite3($dbFile);
But the following works OK:
$db = new SQLite3('SCGBG_Data.db');
or
$db = new MyDB('SCGBG_Data.db');
> BTW it's all in the manual ...
Could you please provide a URL for that? I used the example from:
http://www.php.net/manual/en/sqlite3.open.php
I am using SQLite version 3.7.2 and PHP 5.3.1.
I have almost everything working but I found some anomalies that I will
describe (later) for further discussion.
Thanks!
Paul
|
|
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172101 is a reply to message #172098] |
Sun, 30 January 2011 21:16 |
P E Schoen
Messages: 86
Registered: January 2011
Karma: 0
|
Member |
|
|
"Felix Saphir" wrote in message news:ii4fdo$1ui$02$1(at)news(dot)t-online(dot)com...
> That's virtually impossible, there shouldn't be a difference
> between using a variable and a string constant. Check your
> code for typos (e.g. you're using $dbFile and $dbfile). Are
> you sure about the value of $dbfile/$dbFile?
Ah, sorry, I just took a closer look and indeed (even in the code I posted)
I had a lower case "f". The fonts in my editor and for newsgroups do not
show much difference. That's where stronger type checking and variable
declaration are useful, and I'm also still used to Delphi which is
case-insensitive. Thanks for finding my stupid error!
> Oh, the manual is a good read in any case. Just a few
> starting points to what I was referring to:
> Variable scope:
<http://www.php.net/manual/en/language.variables.scope.php>
> Object member visibility:
<http://www.php.net/manual/en/language.oop5.visibility.php>
> Object constructors and inheritance:
<http://www.php.net/manual/en/language.oop5.decon.php>
Good points. I had read the Variable Scope and it seemed to me that a
function would see and be able to use the global variable, but apparently
not in this case within "class MyDB extends SQLite3". The public method is
default and the keyword is not needed, but certainly passing the database
filename in the function argument is much preferred, and the explicit public
declaration is better than relying on the default. However, the following is
even simpler and I don't see why I shouldn't use it:
$db = new SQLite3($dbFile);
Thanks!
Paul
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172104 is a reply to message #172101] |
Sun, 30 January 2011 22:06 |
Felix Saphir
Messages: 8
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
P E Schoen <paul(at)pstech-inc(dot)com> wrote:
> "Felix Saphir" wrote in message
> news:ii4fdo$1ui$02$1(at)news(dot)t-online(dot)com...
>
>> That's virtually impossible, there shouldn't be a difference
>> between using a variable and a string constant. Check your
>> code for typos (e.g. you're using $dbFile and $dbfile). Are
>> you sure about the value of $dbfile/$dbFile?
>
> Ah, sorry, I just took a closer look and indeed (even in the
> code I posted) I had a lower case "f". The fonts in my editor
> and for newsgroups do not show much difference. That's where
> stronger type checking and variable declaration are useful, and
PHP reports undefined variables, if you set error_reporting
appropriately. I usually go with the value -1 for debugging.
> I'm also still used to Delphi which is case-insensitive.
My Delphi sources don't compile from time to time. Guess why ...
>> Oh, the manual is a good read in any case. Just a few
>> starting points to what I was referring to:
>
>> Variable scope:
> <http://www.php.net/manual/en/language.variables.scope.php>
>
>> Object member visibility:
> <http://www.php.net/manual/en/language.oop5.visibility.php>
>
>> Object constructors and inheritance:
> <http://www.php.net/manual/en/language.oop5.decon.php>
>
> Good points. I had read the Variable Scope and it seemed to me
> that a function would see and be able to use the global
> variable, but apparently not in this case within "class MyDB
> extends SQLite3". The public method is default and the keyword
> is not needed, but certainly passing the database filename in
> the function argument is much preferred, and the explicit public
> declaration is better than relying on the default.
I guess you already found out, that Delphi has a much more relaxed
approach to protected and private declarations than PHP?
> However, the
> following is even simpler and I don't see why I shouldn't use
> it:
>
> $db = new SQLite3($dbFile);
Looks fine.
Felix
|
|
|
|
| Re: Converting Perl to PHP, testing CLI with $_POST (newbie) [message #172107 is a reply to message #172101] |
Sun, 30 January 2011 22:21 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <syk1p.6215$lO1(dot)920(at)newsfe11(dot)iad>,
"P E Schoen" <paul(at)pstech-inc(dot)com> wrote:
> Good points. I had read the Variable Scope and it seemed to me that a
> function would see and be able to use the global variable, but apparently
> not in this case within "class MyDB extends SQLite3".
If you have:
$myvar = 27;
somefunc (33);
function somefunc ($xyzzz)
{
echo $myvar . "\n"; // Undefined value
echo $xyzzz . "\n"; // echoes 33
}
You need to have:
$myvar = 27;
somefunc (33);
function somefunc ($xyzzz)
{
global $myvar; // Allows function to use global
echo $myvar . "\n"; // echoes 27
echo $xyzzz . "\n"; // echoes 33
}
> The public method is
> default and the keyword is not needed, but certainly passing the database
> filename in the function argument is much preferred, and the explicit public
> declaration is better than relying on the default. However, the following is
> even simpler and I don't see why I shouldn't use it:
>
> $db = new SQLite3($dbFile);
Here's my "myconnectdb" function that I use with SQLite3:
function myconnectdb ($db)
{
global $datarootpath;
$connstr = "sqlite:" . $datarootpath . $db;
$dbh = new PDO ($connstr);
$dbh->setAttribute (PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
return $dbh;
}
Then, because I very occasionally get false SQLite errors [1], I do
something like this:
function myquery ($dbh, $sql, $where)
{
try {
$res = $dbh->query ($sql);
return $res;
}
catch (Exception $e)
{
$earray = $dbh->errorInfo ();
$msg1 = " general code: " . $earray[0] . " error: " .
$earray[1] . ", " . $earray[2];
writeLog ("", "SQLite error: " . $msg1);
$msg2 = " at " . $where . ", sql: _ " . $sql . " _";
writeLog ("", $msg2);
tidyExit ();
}
}
(so my logfile shows what was being tried, what the SQL statement was,
and where it was being tried from)
Then in code doing a query I might have:
$dbh = myconnectdb ("Settings");
$res = myquery ($dbh, "select user,password from accounts where
account='$account'", "DM1");
$reg = $res->fetchAll (PDO::FETCH_ASSOC);
$user = $reg[0]["user"];
$pass = $reg[0]["password"];
$dbh = null;
Note I haven't bothered in this instance to check that I only get one
row back. To see how many rows, do:
$num = count ($reg);
I don't know whether what I have here is capable of improvement, but it
works fine for me.
[1] Usually it claims the db schema has changed which is poppycock.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]