Simple question

P

PF

I have a web page that posts its form data to a cgi script.
I have a request to modify the perl script to BCC the raw form data to
a separate email address. I thought I could just BCC the data as shown
below but the email that gets sent is parsed out into field names and
values. I do not need to change that part. I just need the raw form
data from the HTML post to get emailed to a second email address. I
know this should be easy but I have never programmed PERL and haven't
a clue.
Any resources that show how to do this.

Paul

There is a send mail function like this:
sub send_mail {
# Localize variables used in this subroutine.
#
local($print_config,$key,$sort_order,$sorted_field,$env_report);

# Open The Mail Program
open(MAIL,"|$mailprog -t");

print MAIL "To: webleads\@MyDomain.com\n";
print MAIL "From: $Config{'email'} ($Config{'Name'})\n";
print MAIL "cc: \n";
print MAIL "Bcc: demorequest\@MyDomain.net\n";

# Check for Message Subject
if ($Config{'subject'}) { print MAIL "Subject:
$Config{'subject'}\n\n" }
else { print MAIL "Subject: WWW Form
Submission\n\n" }


print MAIL "Demo Request\n";
print MAIL "$date at $time\n";
print MAIL "Host: $ENV{'REMOTE_ADDR'}\n";
print MAIL "-" x 55 . "\n\n";
print MAIL "Name: $Config{'Name'}\n\n";
print MAIL "Email: $Config{'email'}\n\n";

if (@Print_Config) {
foreach $print_config (@Print_Config) {
if ($Config{$print_config}) {
print MAIL "$print_config:
$Config{$print_config}\n\n";
}
}
}

# Sort alphabetically if specified:
#
if ($Config{'sort'} eq 'alphabetic') {
foreach $field (sort keys %Form) {

# If the field has a value or the print blank fields
option #
# is turned on, print out the form field and value.
#
if ($Config{'print_blank_fields'} || $Form{$field} ||
$Form{$field} eq '0') {
print MAIL "$field: $Form{$field}\n\n";
}
}
}

# If a sort order is specified, sort the form fields based on
that. #
elsif ($Config{'sort'} =~ /^order:.*,.*/) {

# Remove extraneous line breaks and spaces, remove the order:
#
# directive and split the sort fields into an array.
#
$Config{'sort'} =~ s/(\s+|\n)?,(\s+|\n)?/,/g;
$Config{'sort'} =~ s/(\s+)?\n+(\s+)?//g;
$Config{'sort'} =~ s/order://;
@sorted_fields = split(/,/, $Config{'sort'});

# For each sorted field, if it has a value or the print blank
#
# fields option is turned on print the form field and value.
#
foreach $sorted_field (@sorted_fields) {
if ($Config{'print_blank_fields'} || $Form{$sorted_field}
||
$Form{$sorted_field} eq '0') {
print MAIL "$sorted_field: $Form{$sorted_field}\n\n";
}
}
}

# Otherwise, default to the order in which the fields were sent.
#
else {

# For each form field, if it has a value or the print blank
#
# fields option is turned on print the form field and value.
#
foreach $field (@Field_Order) {
if ($Config{'print_blank_fields'} || $Form{$field} ||
$Form{$field} eq '0') {
print MAIL "$field: $Form{$field}\n\n";
}
}
}

print MAIL "-" x 65 . "\n\n";

# Send any specified Environment Variables to recipient.
#
foreach $env_report (@Env_Report) {
if ($ENV{$env_report}) {
print MAIL "$env_report: $ENV{$env_report}\n";
}
}

close (MAIL);
}
 
T

Tad McClellan

PF said:
# Localize variables used in this subroutine.
#
local($print_config,$key,$sort_order,$sorted_field,$env_report);


You are NOT localizing variables there.

You are localizing values (of variables) there.

You should always prefer lexical (my) variables over package (our)
variables, except when you can't.


If you really want local variables, then you want lexical variables:

my($print_config,$key,$sort_order,$sorted_field,$env_report);

open(MAIL,"|$mailprog -t");


You should always, yes *always*, check the return value from open:

open(MAIL,"|$mailprog -t") or die "could not run '$mailprog' $!";
 
T

Tad McClellan

PF said:
I have a request to modify the perl script
I have never programmed PERL and haven't
a clue.


Step 1) Learn some Perl

Step 2) modify the Perl program

Post here if you get stuck on Step 2, or

Step 1) contact the original author of the program for support

or

Step 1) hire somebody who already knows Perl to modify it for you
 
Z

Zebee Johnstone

In comp.lang.perl.misc on Thu, 2 Sep 2004 23:57:12 -0500
Tad McClellan said:
You should always, yes *always*, check the return value from open:

open(MAIL,"|$mailprog -t") or die "could not run '$mailprog' $!";


although it may not Do The Right Thing:

here is z.pl:

#!/usr/bin/perl -w
use strict;
my $file = shift;
open (DATA,"zcat $file|") || die "can't open $file for reading $!\n";
print "end of prog\n";

[zebee@clone maillog]$ ls fred.gz
ls: fred.gz: No such file or directory
[zebee@clone maillog]$ perl z.pl fred.gz
Name "main::DATA" used only once: possible typo at z.pl line 4.
zcat: fred.gz: No such file or directory
end of prog


as you can see, it *didnt* die when told but went on to do the print
statement.

This is, I think, because the open opened a pipe, presumably that
stuffed up whatever open uses to decide if the open worked. Or else it
did work for open's purposes, just not for mine!

Either way, while open or die is ingrained for me, it doesn't always
work. If pipes are involved, I now do an explicit file test to be sure
the file exists.

Zebee
 
U

Uri Guttman

ZJ> although it may not Do The Right Thing:

ZJ> #!/usr/bin/perl -w
ZJ> use strict;
ZJ> my $file = shift;
ZJ> open (DATA,"zcat $file|") || die "can't open $file for reading $!\n";
ZJ> print "end of prog\n";

ZJ> zcat: fred.gz: No such file or directory
ZJ> end of prog


ZJ> as you can see, it *didnt* die when told but went on to do the print
ZJ> statement.

that is because the open didn't fail. open of a piped prog will fail
only if the prog itself doesn't exist (the exec fails). or if the fork
itself fails. in this case zcat is execed so it doesn't die. when you
close the handle that is where the failure of zcat to open fred.gz is
found. this is well documented.

ZJ> This is, I think, because the open opened a pipe, presumably that
ZJ> stuffed up whatever open uses to decide if the open worked. Or else it
ZJ> did work for open's purposes, just not for mine!

it is much simpler than all that and very logical if you understand how
pipes, fork and exec work.

ZJ> Either way, while open or die is ingrained for me, it doesn't always
ZJ> work. If pipes are involved, I now do an explicit file test to be sure
ZJ> the file exists.

it does always work. you need to understand what you are opening and
what the result of open means. in this case it means the fork/exec
worked. try it with open( FH, 'foobar|' ).

uri
 
Z

Zebee Johnstone

In comp.lang.perl.misc on Fri, 03 Sep 2004 06:06:28 GMT
Uri Guttman said:
ZJ> This is, I think, because the open opened a pipe, presumably that
ZJ> stuffed up whatever open uses to decide if the open worked. Or else it
ZJ> did work for open's purposes, just not for mine!

it is much simpler than all that and very logical if you understand how
pipes, fork and exec work.

yes. Worked for open's purposes, just not for mine.

and so when doing a pipe, the return value of open is perhaps not going
to do what you expect. hence saying "aways deal with the return value"
is true, but it's not always helpful.

Zebee
 
U

Uri Guttman

ZJ> In comp.lang.perl.misc on Fri, 03 Sep 2004 06:06:28 GMT
ZJ> This is, I think, because the open opened a pipe, presumably that
ZJ> stuffed up whatever open uses to decide if the open worked. Or else it
ZJ> did work for open's purposes, just not for mine!
ZJ> yes. Worked for open's purposes, just not for mine.

ZJ> and so when doing a pipe, the return value of open is perhaps not going
ZJ> to do what you expect. hence saying "aways deal with the return value"
ZJ> is true, but it's not always helpful.

again, you miss the point. open's value reflects what it knows about the
result of the operation. so it can detect a fork/exec fail. until the
forked program runs (you read/write to it) or is reaped (close) you
can't tell how it behaves. so it is up to YOU and not the open call to
know it is a piped program and deal with that accordingly. open on a
pipe does what it is supposed to do and you should ALWAYS check the
results (you just have to know how to interpret them differently when
piping). close is rarely checked for its result (though some do). close
is rarely even needed to be called as handles going out of scope or
being reopened will do a close. but if you do a open pipe it is on YOUR
head to do a real close and check the results. also if your piped
program fails to run (it exits early before any i/o) you can also detect
that by reading the undef (EOF) value instead of a line or
whatever. then you should immediately do a close and report the error.

so stop your gibbering about how open's return is not always helpful. it
is ALWAYS helpful. it is your code that may not be taking proper
advantage of that offered help.

and this is all well documented in perldoc -f open and perlopentut.

uri
 
T

Tad McClellan

Zebee Johnstone said:
and so when doing a pipe, the return value of open is perhaps not going
to do what you expect.


This is a Frequently Asked Question.

perldoc -q pipe

Why doesn't open() return an error when a pipe open fails?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top