Re: CGI.pm
On Sep 28, 2007, at 8:17 AM, Michael Barto wrote: This seems like a flame, but I will try and answer your question. The reason why we are doing the HTML subroutines and so many others with key at the start (e.g. JSCript, DB, make, get). is mostly to support long term maintenance and parse out pieces of the code for a very large project (divide and conquer) The modules libraries are maintained in a consistent manner. The variables $new_page and $from_page also are significant in this large code. It just helps the many people that have to touch this code have an easier path getting though any maintenance. The main program is nothing more than large set subroutine calls broken down in sections. The subroutine calls are shared by many modules of the large project. The "best practices" procedure is to use MVC. (Model, View, Control) - this provides separation of logic and presentation and significantly aids in the long term maintenance of your code. Look at Damian Conway's book; Perl Best Practices. By not following best practices you run the risk of making your code write only. An experienced perl programmer would have a hard time reading it and re-factor it according to best practices. Following best practices will significantly increase readability, maintenance, and quality of your code. Jeremiah
Re: CGI.pm
This seems like a flame, but I will try and answer your question. The
reason why we are doing the HTML subroutines and so many others with
key at the start (e.g. JSCript, DB, make, get). is mostly to support
long term maintenance and parse out pieces of the code for a very large
project (divide and conquer). The modules libraries are maintained in a
consistent manner. The variables $new_page and $from_page also are
significant in this large code. It just helps the many people that have
to touch this code have an easier path getting though any maintenance.
The main program is nothing more than large set subroutine calls broken
down in sections. The subroutine calls are shared by many modules of
the large project.
Also, I really appreciate "[EMAIL PROTECTED]" response as it did
clarify the issue and was very helpful.
Jeremiah Foster wrote:
On Sep 27, 2007, at 6:41 PM, Michael Barto wrote:
Perl snippet question:
-
#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
my $new_page = new CGI("");
sub HTMLendFORM ($) {
my $new_page = $_[0];
print $new_page->end_form;
}
HTMLendFORM ($new_page);
print "\n\n";
-
This above code produces "". This
ti me is odd, since i only really want . Does anyone have
an explanation or another way to use the CGI.pm library and produce
only . Yes I could just use a print statement. But I am
kind of curious to why?
Why are you doing it this way? You do not need a sub and it is best to
use $q (or the functional interface) since if anyone has to read your
code they will recognize $q immediately but wonder what $new_page is
for. And why are you printing two new lines? New lines do not show up
in HTML.
Try this:
print $q->end_form();
That usually produces
--
Michael Barto
Software Architect
LogiQwest
Inc.
16458 Bolsa Chica Street, # 15
Huntington Beach, CA 92649
http://www.logiqwest.com/
[EMAIL PROTECTED]
Tel: 714 377 3705
Fax: 714 840 3937
Cell: 714 883 1949
'tis a gift to be
simple
This e-mail may contain
LogiQwest
proprietary information and should be treated as confidential.
Re: CGI.pm
On Sep 27, 10:41 am, [EMAIL PROTECTED] (Michael Barto) wrote: > Perl snippet question: > [snip] > > This above code produces "". This ti me is odd, since > i only really want . Does anyone have an explanation or another > way to use the CGI.pm library and produce only . Yes I could just > use a print statement. But I am kind of curious to why? You also see this with $ perl -MCGI -le'print CGI::end_form' $ According to the CGI.pm ChangeLog, this is a bug that was fixed in 3.12. I think it has something to to with CGI.pm's sticky fields. OSX 10.4 comes with CGI 3.05. My Linux box with CGI 3.15 doesn't have this problem.
Re: CGI.pm
From perldoc CGI:
A Lurking Trap! Some of the form-element generating methods
return multiple tags. In a scalar context, the tags will be
concatenated together with spaces, or whatever is the current value
of the $" global. In a list context, the methods will return a list
of elements, allowing you to modify them if you wish. Usually you
will not notice this behavior, but beware of this:
printf("%s\n",end_form())
end_form() produces several tags, and only the first of them
will be printed because the format only expects one value.
On Sep 27, 2007, at 6:41 PM, Michael Barto wrote:
Perl snippet question:
-
#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
my $new_page = new CGI("");
sub HTMLendFORM ($) {
my $new_page = $_[0];
print $new_page->end_form;
}
HTMLendFORM ($new_page);
print "\n\n";
-
This above code produces "". This ti me is odd,
since i only really want . Does anyone have an explanation
or another way to use the CGI.pm library and produce only .
Yes I could just use a print statement. But I am kind of curious to
why?
--
Michael Barto
Software Architect
LogiQwest Inc.
16458 Bolsa Chica Street, # 15
Huntington Beach, CA 92649
http://www.logiqwest.com/
[EMAIL PROTECTED]
Tel: 714 377 3705
Fax: 714 840 3937
Cell: 714 883 1949
'tis a gift to be simple
This e-mail may contain LogiQwest proprietary information and
should be treated as confidential.
Re: CGI.pm
On Sep 27, 2007, at 6:41 PM, Michael Barto wrote:
Perl snippet question:
-
#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
my $new_page = new CGI("");
sub HTMLendFORM ($) {
my $new_page = $_[0];
print $new_page->end_form;
}
HTMLendFORM ($new_page);
print "\n\n";
-
This above code produces "". This ti me is odd,
since i only really want . Does anyone have an explanation
or another way to use the CGI.pm library and produce only .
Yes I could just use a print statement. But I am kind of curious to
why?
Why are you doing it this way? You do not need a sub and it is best
to use $q (or the functional interface) since if anyone has to read
your code they will recognize $q immediately but wonder what
$new_page is for. And why are you printing two new lines? New lines
do not show up in HTML.
Try this:
print $q->end_form();
That usually produces
CGI.pm
Perl snippet question:
-
#!/usr/bin/perl -w
use strict;
use CGI;
use CGI::Carp 'fatalsToBrowser';
my $new_page = new CGI("");
sub HTMLendFORM ($) {
my $new_page = $_[0];
print $new_page->end_form;
}
HTMLendFORM ($new_page);
print "\n\n";
-
This above code produces "". This
ti me is odd, since i only really want . Does anyone have
an explanation or another way to use the CGI.pm library and produce
only . Yes I could just use a print statement. But I am
kind of curious to why?
--
Michael Barto
Software Architect
LogiQwest
Inc.
16458 Bolsa Chica Street, # 15
Huntington Beach, CA 92649
http://www.logiqwest.com/
[EMAIL PROTECTED]
Tel: 714 377 3705
Fax: 714 840 3937
Cell: 714 883 1949
'tis a gift to be
simple
This e-mail may contain
LogiQwest
proprietary information and should be treated as confidential.
Re: file uploads using CGI.pm
At 2:55 PM -0700 2002-05-24, Chris Angelli wrote:
>difficulty doing something very simple. For some
>reason I can't get file uploads to work. I am doing
>nothing fancy, but my uploads just don't work.
I moved the rest of Chris's post to the end, in case someone wants to
look at it.
I've had several file upload sites going for a few years. The code
you quoted seems slightly different from what I'm now using. I
started from Lincoln Stein's book, but I know my stuff has evolved
over the years to handle various contingencies.
Below is an excerpt that covers the basics. It's taken from a
subroutine that is in my standard library for dispatch via a CGI
script's state machine, but I've tried to simplify it down to what's
important.
A few other comments, if I may:
1. Your comment that 'use constant' isn't working is of concern. Do
you have other CGIs working on this setup?
2. My development site is a vanilla OS X 10.1.4 w/ developer tools
(Perl 5.6.0, CGI.pm 2.56) installed. I'm not running mod_perl on it,
and mod_perl affects the persistence of variables, so there might be
something the look for there.
3. We get the handy computing experience of the Mac interface using
BBEdit, one of whose benefits is direct Perl syntax checking.
However, in a web context, there is really no way to avoid checking
your webserver error log, if you're serious about your work. (Even
using strict.pm and the '-w' switch won't tell you everything.) In
this modern age, one may simply open a Terminal window, and type in
the command
% tail -f -n20 /private/var/log/httpd/error_log
and get the last 20 lines of their ht error log, continuously
updating itself as a script is tested on their server.
Ain't it the OS X life?
If at first you are dismayed to see MANY lines of error messages
scroll by every time you call your script, just remember that
mistakes are our friends. For hardcore logic poets, watching an
eventless error log during testing has a certain satisfaction...
4. Here's my example:
## File upload example
# Excerpted from a production script
# deployed on Solaris, Mac OS X, NT, & Win 2000 servers
# Utilize 'for' loop for control flow
# In this case there is only one file upload field in the HTML form.
# It's named 'img_file' -- the user has uploaded an image file.
# The hash %input_vals holds cleaned-up input obtained via CGI.pm
# For clarity, methods from CGI.pm are shown in the form CGI::method()
# Other methods here are from my modules, but their names suggest what they do
# Sorry about the outermost 'if' structure -- it's a vestige.
for my $file_fld ('img_file') {
if ($input_vals{$file_fld} ne '') {
# Get the file upload object directly from CGI.pm
my $image_file = CGI::param($file_fld);
## Check file type and generate a conforming file suffix
my $type= CGI::uploadInfo($image_file)->{'Content-Type'};
my $suf = '';
{
local $_ = $type;
$suf = /gif/i ? 'gif' :
/jpeg/i ? 'jpg' :
/png/i ? 'png' :
''; # $suf ends up blank if no match
}
## Not a desired file type? Ask the user again
unless ($suf) {
oops('wrong_file_type', $type) # script exits here
}
## Check file size
# set maximum file upload size, in kB.
my $max = 100;
# start a counter
my $length = 0;
# puff a buffer
my $buf = '';
# read through the tmp file, chunking 1 k at a time
while (read($image_file, $buf, 1024)) {
$length++;
}
## File too large? Ask the user again
if ($length > $max) {
oops('file_too_large', $length) # script exits here
}
## OK. Save the file
# Rewind
seek $image_file, 0, 0;
# Make up a name for the permanent file, using suffix from above.
# For security and glitch-avoidance,
# don't accept user input for a filename
my $img_file_name = "/path/images/$user_id.$suf";
# Open the permanent file
open IMAGE, ">$img_file_name" or oops('file_write_failed', $!);
# Write to the permanent file from the tmp file
while (read($image_file, $buf, 1024)) {
print IMAGE $buf;
}
close IMAGE;
$input_vals{$file_fld} = "$user_id.$suf"; # non-tainted filename
} else {
# This prevents overwriting existing filename if nothing new submitted;
# only needed for file uploads because other types of inpu
file uploads using CGI.pm
Forgive me if this is not appropriate for this list,
but I'm not sure where else to turn. I am having
difficulty doing something very simple. For some
reason I can't get file uploads to work. I am doing
nothing fancy, but my uploads just don't work.
here's the stolen code snippet: (It might look
familiar to readers of 'CGI programming with perl')
my $file = $q->param ("file") || error ($q, "No
file received.");
my $filename = $q->param ("filename") || error ($q,
"No filename entered.");
my $fh = $q->upload($file);
my $buffer = "";
while (read ($fh, $buffer, $BUFFER_SIZE)) {
print OUTPUT $buffer;
}
close OUTPUT;
When I try to read from $fh, I get nothing. Also, I
tried to see where/what was going on with the temp
file that CGI.pm creates, but
my $tmpfile = $q->tmpFileName($file);
returns nothing.
and so does
my $info = $q->uploadInfo($assetParamName);
my $ctype = $info->{'Content-Type'};
Has anyone seen this type of behavior before? Is
there anything obvious that I should/shouldn't be
doing?
I should note that for some (probably unrelated
reason) use constant doesn't work either.
My environment:
OSX 10.1.4
APACHE Apache/1.3.20 (Darwin)
mod_perl 1.26
CGI.pm 2.752
Any ideas or suggestions would be greatly appreciated.
Thank you for your patience and help.
-chris
"I am a bear of little brain."
-pooh
__
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
Re: CGI.pm and mod_perl don't co-exist
Hi Ken, Thanks for your reply. Here are some more specifics, and some questions... > Any time you upgrade Perl, you need to also upgrade some of the XS > modules that you've got installed. In this case, you need to > re-install DBD::mysql. ok. However, I can't figure out for the life of me how to re-install. If I ask information on the module, CPAN tells me it is up-to-date. If I ask it to install it anyway, CPAN says it is up-to-date! And I don't know anyway to uninstall a module via CPAN. So, what do I do? > As for the CGI problem, the 'redefined' warning isn't a problem in > itself. You can ignore it if you like. I'm not sure what to make of > the "locking up" problem, though. Some more data is probably in order. well, really, this is about all I have... for example, I just now turned on my iBook (I am writing this email from it). But, Apache has not started. It is off... although it should have started by itself. If I try to start it from the Web Sharing System Prefs doohickey, it says that its starting up, but that's it, it really doesn't start... it just continues to say that it is starting up. So, I typed "sudo apachectl start" (or restart) at the command line, it says that it is going through my httpd.conf and then even says that it started. However, it has not. Here's the message I got -- Processing config directory: /private/etc/httpd/users Processing config file: /private/etc/httpd/users/pkishor.conf /usr/sbin/apachectl start: httpd started However, it hasn't started, and there is no error in the error_log. In fact, there is no entry for today. So, I type "sudo apachectl configtest" and it told me that the syntax is ok. So I said, "httpd -v" and I got the following -- Server version: Apache/1.3.22 (Darwin) Server built: 11/13/01 03:40:24 Then I said "httpd -V" and I got the following additional junk -- Server's Module Magic Number: 19990320:10 Server compiled with -D EAPI -D HAVE_MMAP -D USE_MMAP_SCOREBOARD -D USE_MMAP_FILES -D HAVE_FCNTL_SERIALIZED_ACCEPT -D HAVE_FLOCK_SERIALIZED_ACCEPT -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D HTTPD_ROOT="/usr" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="/var/run/httpd.pid" -D DEFAULT_SCOREBOARD="/var/run/httpd.scoreboard" -D DEFAULT_LOCKFILE="/var/run/httpd.lock" -D DEFAULT_XFERLOG="/var/log/httpd/access_log" -D DEFAULT_ERRORLOG="/var/log/httpd/error_log" -D TYPES_CONFIG_FILE="/etc/httpd/mime.types" -D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf" -D ACCESS_CONFIG_FILE="/etc/httpd/access.conf" -D RESOURCE_CONFIG_FILE="/etc/httpd/srm.conf" Then, I commented out the following lines -- LoadModule perl_modulelibexec/httpd/libperl.so AddModule mod_perl.c and then did "sudo apachectl restart." This time Apache started just fine and %ENV showed me that I am running -- SERVER_SOFTWARE Apache/1.3.22 (Darwin) Then I went back to httpd.conf and uncommented the above two line and redid the "sudo apachectl restart" and it started just fine. Now %ENV tells me I am running -- SERVER_SOFTWARE Apache/1.3.22 (Darwin) mod_perl/1.26 The error_log is clean... here are the last few entries from a few mins ago -- Processing config directory: /private/etc/httpd/users Processing config file: /private/etc/httpd/users/pkishor.conf [Mon Apr 1 20:38:15 2002] [notice] Apache/1.3.22 (Darwin) configured -- resuming normal operations [Mon Apr 1 20:38:15 2002] [notice] Accept mutex: flock (Default: flock) [Mon Apr 1 20:41:07 2002] [notice] SIGHUP received. Attempting to restart Processing config directory: /private/etc/httpd/users Processing config file: /private/etc/httpd/users/pkishor.conf [Mon Apr 1 20:41:08 2002] [notice] Apache/1.3.22 (Darwin) mod_perl/1.26 configured -- resuming normal operations [Mon Apr 1 20:41:08 2002] [notice] Accept mutex: flock (Default: flock) Go figure. Puneet. > > > On Tuesday, April 2, 2002, at 05:33 AM, PK Eidesis wrote: >> Ever since I built and installed Perl561 and installed mod_perl using >> CPAN, >> I have just not had anything work for me predictably. The web server >> locks >> up and doesn't start. It will start only if I comment out the mod_perl >> lines >> in httpd.conf. Then it starts. After that if I uncomment the mod_perl >> lines, >> then it will restart. Go figure. >> >> I always get messages to the effect of... >> >> Subroutine ??? redefined in CGI.pm at line ??? (replace ??? with >> various >> values). >> >> Googling on the above error message actually lead me to the above >> quote. >> >> Now, DBD::mysql has stopped working... no error messages, no results... >> nothing. > > > -Ken >
Re: CGI.pm and mod_perl don't co-exist
PK, Any time you upgrade Perl, you need to also upgrade some of the XS modules that you've got installed. In this case, you need to re-install DBD::mysql. As for the CGI problem, the 'redefined' warning isn't a problem in itself. You can ignore it if you like. I'm not sure what to make of the "locking up" problem, though. Some more data is probably in order. On Tuesday, April 2, 2002, at 05:33 AM, PK Eidesis wrote: > Ever since I built and installed Perl561 and installed mod_perl using > CPAN, > I have just not had anything work for me predictably. The web server > locks > up and doesn't start. It will start only if I comment out the mod_perl > lines > in httpd.conf. Then it starts. After that if I uncomment the mod_perl > lines, > then it will restart. Go figure. > > I always get messages to the effect of... > > Subroutine ??? redefined in CGI.pm at line ??? (replace ??? with various > values). > > Googling on the above error message actually lead me to the above quote. > > Now, DBD::mysql has stopped working... no error messages, no results... > nothing. -Ken
Re: CGI.pm and mod_perl don't co-exist
On 4/1/02 2:50 PM, "Bill -Sx- Jones" <[EMAIL PROTECTED]> wrote: >> http://www.bitmechanic.com/mail-archives/modperl/Feb1997/0100.html > I think Doug;s best quote would be - "What's most important is patience, don't let yourself get frusterated." I am guilty of that more often than not :/ Cheers! -Sx- :]
Re: CGI.pm and mod_perl don't co-exist
On Mon, 1 Apr 2002, PK Eidesis wrote:
> Ever since I built and installed Perl561 and installed mod_perl using CPAN,
> I have just not had anything work for me predictably. The web server locks
> up and doesn't start. It will start only if I comment out the mod_perl lines
> in httpd.conf. Then it starts. After that if I uncomment the mod_perl lines,
> then it will restart. Go figure.
I built mod_perl/apache by hand (ignoring the apache apple gives you),
using perl 5.6.1. I haven't had any problems. The sub redifinition
problem might be a case off CGI.pm's autoloading. (CGI.pm delays loading
of most of it's subs till they are called at run time. This makes things
faster for a simple CGI.) You might want to add something like:
use CGI;
CGI->compile(':all');
to your mod_perl configuration (you can just put it in a section,
or setup a startup.pl if you don't already have one).
--
Chris Reinhardt
[EMAIL PROTECTED]
Systems Architect
Dynamic DNS Network Services
http://www.dyndns.org/
Re: CGI.pm and mod_perl don't co-exist
> http://www.bitmechanic.com/mail-archives/modperl/Feb1997/0100.html May have been true in 1997, but not today :) Cheers; -Sx- :]
Re: CGI.pm and mod_perl don't co-exist
>>seems like CGI.pm and mod_perl can't work together. Man, I wish I had >> figured that out earlier. According to Doug MacEachern... >> >> >>> Lincoln's CGI.pm does not work under mod_perl, at least it did not >>> last time we checked > > >This is news to me. I've used CGI.pm under mod_perl many times. Heck, >the O'Reilly mod_perl book is filled with CGI.pm examples. Under the >hood, CGI.pm jumps though a fair number of hoops to make things work right >under mod_perl. Where did you find that quote? Well, Chris, I might have mis-spoke, but, the above quote can be seen here... http://www.bitmechanic.com/mail-archives/modperl/Feb1997/0100.html however, then I realize that is from aeons ago, so maybe CGI.pm and/or mod_perl might have been re-engineered since then to co-exist. The fact is that I have found Perl to be more than frustrating on my iBook, and as much as I want to believe, I am finding it tiring. Ever since I built and installed Perl561 and installed mod_perl using CPAN, I have just not had anything work for me predictably. The web server locks up and doesn't start. It will start only if I comment out the mod_perl lines in httpd.conf. Then it starts. After that if I uncomment the mod_perl lines, then it will restart. Go figure. I always get messages to the effect of... Subroutine ??? redefined in CGI.pm at line ??? (replace ??? with various values). Googling on the above error message actually lead me to the above quote. Now, DBD::mysql has stopped working... no error messages, no results... nothing. I am spending way tooo much time trying to make it work, instead of spending time trying to figure out neat ways to write a program. Almost makes me wanna believe in Micro$oft (shudder). pk/ -- Puneet Kishor
Re: CGI.pm and mod_perl don't co-exist
On Mon, 1 Apr 2002, Puneet Kishor wrote: > seems like CGI.pm and mod_perl can't work together. Man, I wish I had > figured that out earlier. According to Doug MacEachern... > > > Lincoln's CGI.pm does not work under mod_perl, at least it did not > > last time we checked This is news to me. I've used CGI.pm under mod_perl many times. Heck, the O'Reilly mod_perl book is filled with CGI.pm examples. Under the hood, CGI.pm jumps though a fair number of hoops to make things work right under mod_perl. Where did you find that quote? -- Chris Reinhardt [EMAIL PROTECTED] Systems Architect Dynamic DNS Network Services http://www.dyndns.org/
CGI.pm and mod_perl don't co-exist
So, all this continuing problem I was having with CGI.pm of the
following kind...
> Subroutine ??? redefined in CGI.pm at line ???
seems like CGI.pm and mod_perl can't work together. Man, I wish I had
figured that out earlier. According to Doug MacEachern...
> Lincoln's CGI.pm does not work under mod_perl, at least it did not
> last time we checked
Oh well.
Now I am onto another problem. My DBD::mysql refuses to do anything with
the databases on my computer. It just runs and quits silently... no
errors, nothing, even for a simple test like so...
> #!/usr/bin/perl -w
>
> use diagnostics;
> use DBI;
> use strict;
>
>
> my $host = "localhost";
> my $port = 3306;
>
> my $drh = DBI->install_driver("mysql");
> my @databases = $drh->func($host, $port, '_ListDBs');
>
> print "$_\n" foreach (@databases);
needless to say, this very same script was working fine on the same
computer.
Any guidance will be much appreciated.
pk/
a new one... seems like I am doing something to affect CGI.pm
this after I manage to have Apache run with mod_perl 1.26... usually the honeymoon lasts a few hours. But I get the above error always (along with many others). 'Tsup? pk/
