rhondabrabbin
Technical User
- Nov 11, 2002
- 87
I have a form on my site and I don't know how to make it work so when you hit submit it will send mail to me, I know this sounds really simple but I am struggling with it.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
I have a form on my site and I don'
- Thread starter rhondabrabbin
- Start date
- Status
- Thread starter
- #3
rhondabrabbin
Technical User
- Nov 11, 2002
- 87
By default is the a cgi script in the cgi bin and if so do I need to set up the cgi script? And if so how do I edit it to be assured it will work.
Thank you so much for your answers!
Thank you so much for your answers!
- Thread starter
- #5
rhondabrabbin
Technical User
- Nov 11, 2002
- 87
The company that hosts our website is
- Thread starter
- #6
thedude623
Programmer
There is one easier way, without using cgi scripts,
If you just want an email use:
<form method=post action="mailto:name@domain.com">
This will email you the field in ugly ascii,
you can get fancy and sepecify a subject
<form method=post action="mailto:name@domain.com?Subject=subjectHere">
and finally, to clean it up to make it more readable, and user-friendly to you:
<Form method=post action="mailto:name@domain.com" Enctype=text/plain>
If you just want an email use:
<form method=post action="mailto:name@domain.com">
This will email you the field in ugly ascii,
you can get fancy and sepecify a subject
<form method=post action="mailto:name@domain.com?Subject=subjectHere">
and finally, to clean it up to make it more readable, and user-friendly to you:
<Form method=post action="mailto:name@domain.com" Enctype=text/plain>
- Thread starter
- #9
rhondabrabbin
Technical User
- Nov 11, 2002
- 87
Thank you so very much, I have been trying to figure this out for 2 weeks and your simple script was all I needed, I used it and it worked and all is great, thank you
here is how I do it and it works:
#!/usr/bin/perl
print "</BODY></HTML>";
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
%FORM = ();
foreach $pair (@pairs) {
$pair =~ s/\+/ /g;
($name, $value) = split(/=/, $pair);
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("c", hex($1))/eg;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("c", hex($1))/eg;
$value =~ s/\n/ /g; # replace newlines with spaces
$value =~ s/\r//g; # remove hard returns
$value =~ s/\cM//g; # delete ^M's
$FORM{$name} = $value;
}
foreach $key (put your variable names in here that you are asking in your html program e.g. "name","address","city","state","email"
{
# to make sure that the variables are passed on to his program from your html keep this statement. It prints all the variable sent from HTML.
print "$key = $FORM{$key}<br>";
print "\n";
}
$mailprog ='/usr/lib/sendmail';
$sender =put your company email address here in quotes e.g. "sales\@company.com";
open (MAIL, "| $mailprog $FORM{'email'}" or die "Could not open Mailprogram:";
print MAIL "TO: $FORM{'email'}\n";
print MAIL "FROM: $recipient\n";
print MAIL "Subject : Thanks\n";
print MAIL "You have provided this information:\n";
print MAIL "Name : $FORM{'name'}. address: $FORM{'address'} city: $FORM{'city'}\n";
print MAIL "$FORM{'state'} $FORM{'zip-code'}\n";
print MAIL "phone : $FORM{'telephone'} to call you between $FORM{'time-to-call'} \n";
close (MAIL);
print <<EndHTML;
EndHTML
sub dienice {
my($msg) = @_;
print "<h2>Error</h2>\n";
print $msg;
exit;
Save this as myform.cgi program and store it in the CGI directory of your server. Then add this statement in the HTML program:
<form method="post" name="myform" action="/cgi-bin/myform.cgi">
Good luck.
#!/usr/bin/perl
print "</BODY></HTML>";
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
%FORM = ();
foreach $pair (@pairs) {
$pair =~ s/\+/ /g;
($name, $value) = split(/=/, $pair);
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("c", hex($1))/eg;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("c", hex($1))/eg;
$value =~ s/\n/ /g; # replace newlines with spaces
$value =~ s/\r//g; # remove hard returns
$value =~ s/\cM//g; # delete ^M's
$FORM{$name} = $value;
}
foreach $key (put your variable names in here that you are asking in your html program e.g. "name","address","city","state","email"
{
# to make sure that the variables are passed on to his program from your html keep this statement. It prints all the variable sent from HTML.
print "$key = $FORM{$key}<br>";
print "\n";
}
$mailprog ='/usr/lib/sendmail';
$sender =put your company email address here in quotes e.g. "sales\@company.com";
open (MAIL, "| $mailprog $FORM{'email'}"
or die "Could not open Mailprogram:";print MAIL "TO: $FORM{'email'}\n";
print MAIL "FROM: $recipient\n";
print MAIL "Subject : Thanks\n";
print MAIL "You have provided this information:\n";
print MAIL "Name : $FORM{'name'}. address: $FORM{'address'} city: $FORM{'city'}\n";
print MAIL "$FORM{'state'} $FORM{'zip-code'}\n";
print MAIL "phone : $FORM{'telephone'} to call you between $FORM{'time-to-call'} \n";
close (MAIL);
print <<EndHTML;
EndHTML
sub dienice {
my($msg) = @_;
print "<h2>Error</h2>\n";
print $msg;
exit;
Save this as myform.cgi program and store it in the CGI directory of your server. Then add this statement in the HTML program:
<form method="post" name="myform" action="/cgi-bin/myform.cgi">
Good luck.
Samsale, you really really really should use the CGI libraries rather then parsing your strings yourself. There are a ton of conditions that you are not catching and while it may work 'generally' there can be implications as you move towards more complex software.
Not trying to be a nag, just letting you know that you are reinventing the wheel parsing your CGI args manually.
Here is how you do it with CGI.pm
--
my $query = new CGI ;
--
Voila, done, now you can access your vars as
--
$query->param('FIELDNAME')
---
Not trying to be a nag, just letting you know that you are reinventing the wheel parsing your CGI args manually.
Here is how you do it with CGI.pm
--
my $query = new CGI ;
--
Voila, done, now you can access your vars as
--
$query->param('FIELDNAME')
---
thedude623
Programmer
But, from what rhondabrabbin said, it looks like he wants a good all-purpose, SIMPLE way to do it, and the easiest way is my previous example...
The mailto method is the easiest, I was just commenting on the code samesale posted, trying to help him learn how to do it a bit more 'correctly' , whatever that means.
I think the mailto: method may be highly client dependant. For example, if I do not have my 'default mail client' configured properly does it still work?
I think the mailto: method may be highly client dependant. For example, if I do not have my 'default mail client' configured properly does it still work?
On Libraries,
GI.pm seemed like the way to go, for a few projects, and now my ass is well roasted because of stricter implementations of CGI.pm (2.99, and 3.0) (coulda been the whiskey, mighta been the gin)
To have total faith in core modularity, flaws should be better thought out than just, "we feel you subjugatiung your site, so at least now it just won't work..."
I test my code, against what "I know". My suppliers put up patches, and they don't care coz they "read it in a security bulletin", My clients think I'm "taking the piss"
I now prefer to hand-roll code, and test against what I know works and what doesn't
It's a lot more work, but its been a lesson on interdependency, and where the pitfalls exist
Hope that "helps"
--Paul
The campaign for reusable, controllable by the end user code starts here
Sign Below
-X
-x
-XXX (I'm in the wrong news group)
--;P
It's important in life to always strike a happy medium, so if you see someone with a crystal ball, and a smile on their face ...
GI.pm seemed like the way to go, for a few projects, and now my ass is well roasted because of stricter implementations of CGI.pm (2.99, and 3.0) (coulda been the whiskey, mighta been the gin)
To have total faith in core modularity, flaws should be better thought out than just, "we feel you subjugatiung your site, so at least now it just won't work..."
I test my code, against what "I know". My suppliers put up patches, and they don't care coz they "read it in a security bulletin", My clients think I'm "taking the piss"
I now prefer to hand-roll code, and test against what I know works and what doesn't
It's a lot more work, but its been a lesson on interdependency, and where the pitfalls exist
Hope that "helps"
--Paul
The campaign for reusable, controllable by the end user code starts here
Sign Below
-X
-x
-XXX (I'm in the wrong news group)
--;P
It's important in life to always strike a happy medium, so if you see someone with a crystal ball, and a smile on their face ...
I'd blame the gin myself.
if you found a 'real' issue you NEED to report it to Lincoln ASAP. Sounds like user error to me. Can you detail the exact issues you found with the library (and not with your usage of it)? I'll report them to Lincoln for you!
I have seen people on this board and other forums (IRC etc) spin their wheels around and around and around 'rolling their own' CGI code. Those are HOURS wasted in the general case that could have been handled in a few minutes.
Everyone has a different situation but so far in all my years of helping folks I have never seen CGI.pm be at fault in a bad code run. I have seen people not understanding how to use it but I have not yet seen it cause a problem.
if you found a 'real' issue you NEED to report it to Lincoln ASAP. Sounds like user error to me. Can you detail the exact issues you found with the library (and not with your usage of it)? I'll report them to Lincoln for you!
I have seen people on this board and other forums (IRC etc) spin their wheels around and around and around 'rolling their own' CGI code. Those are HOURS wasted in the general case that could have been handled in a few minutes.
Everyone has a different situation but so far in all my years of helping folks I have never seen CGI.pm be at fault in a bad code run. I have seen people not understanding how to use it but I have not yet seen it cause a problem.
Ok, I'm cheating now, but here's an example from another guy at ExpertsExchange
Output from the code
CGI.pm 2.98:
Content-type: text/html
<h1>Software error:</h1>
<pre>i'm dead! at t.pl line 3.</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.
</p>
[Wed Nov 12 13:44:09 2003] t.pl: i'm dead! at t.pl line 3.
CGI.pm 2.99 and 3.0:
<h1>Software error:</h1>
<pre>i'm dead! at t.pl line 3.</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.
</p>
[Wed Nov 12 13:42:27 2003] t.pl: i'm dead! at t.pl line 3.
Here's the code used to generate it.
#!/usr/bin/perl -w
use CGI::Carp qw(fatalsToBrowser);
die "i'm dead!";
To be honest what really hacked me off with CGI.pm was a security patch that fixed cross site scripting attacks, but effectively broke all of my CGI scripts, because I was posting the content of the form back to itself. Since then I've had hand-roll all the form tags,because when I do it in CGI, it puts in the quoted printable for forward slash
My real whine is not at CGI.pm, but against my own hosters who put up the patch without really knowing why. Even looking for information on what it fixed and why doesn't really have me any the wiser as to why it was broke
--Paul
Output from the code
CGI.pm 2.98:
Content-type: text/html
<h1>Software error:</h1>
<pre>i'm dead! at t.pl line 3.</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.
</p>
[Wed Nov 12 13:44:09 2003] t.pl: i'm dead! at t.pl line 3.
CGI.pm 2.99 and 3.0:
<h1>Software error:</h1>
<pre>i'm dead! at t.pl line 3.</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.
</p>
[Wed Nov 12 13:42:27 2003] t.pl: i'm dead! at t.pl line 3.
Here's the code used to generate it.
#!/usr/bin/perl -w
use CGI::Carp qw(fatalsToBrowser);
die "i'm dead!";
To be honest what really hacked me off with CGI.pm was a security patch that fixed cross site scripting attacks, but effectively broke all of my CGI scripts, because I was posting the content of the form back to itself. Since then I've had hand-roll all the form tags,because when I do it in CGI, it puts in the quoted printable for forward slash
My real whine is not at CGI.pm, but against my own hosters who put up the patch without really knowing why. Even looking for information on what it fixed and why doesn't really have me any the wiser as to why it was broke
--Paul
Those special cases are a bummer. That cross-site scripting stuff beat up a lot of people, not just those using an upgraded CGI.pm.
I agree on the admin thing, I make it a point to maintain a constant library package across all my servers that I maintain in CVS. When I build a new box I install my standard lib package. This ensures a constant development environment. Changing things out on people is not fun for them or me!
I agree on the admin thing, I make it a point to maintain a constant library package across all my servers that I maintain in CVS. When I build a new box I install my standard lib package. This ensures a constant development environment. Changing things out on people is not fun for them or me!
- Status