Re: Slightly OT question about email receiving...
On Thu, 21 Feb 2002, Morse, Richard E. wrote: Hi! I realize that this question is OT -- if anybody knows where I should post it, please let me know... I need to develop a perl script to deploy on a *nix box which accepts input from sendmail (ie, it is called via a sendmail alias), parses the received email, extracts an attachment, and then processes it. I know how to do the processing after I've got the email, but what I'm wondering is if there is a module somewhere that will accept the email coming in from STDIN, parse it, and allow me to get the attachment. Or do I need to do something like a POP3 connection, or something AFAIK, there is no module to do what you want, however there are modules that you could use from code that you write to do this kind of thing. I've never used an e-mail alias to get an e-mail to be sent to a perl script however I have used a procmail receipe to send an e-mail (with attachments) to a perl script. The perl script detaches the attachments and decodes the attachments (if necessary) to create the original files. The script will decode an attachment if the attachment header for content-transfer-encoding: specifies base64 or quoted-printable. I used the MIME::Base64 and MIME::Quotedprint modules for this. This script is used to maintain the content of web pages so it has to allow both text-oriented attachments, e.g. .html files as well as binary-oriented files such as .gif, .jpg, .ppt, .pdf, etc. [EMAIL PROTECTED] Carl Jolley All opinions are my own and not necessarily those of my employer ___ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Paypal Integration Once Again
Hi, Is it compulsory that we register this information in our paypal account like : 1. item id 2. item name for our shopping cart? because right now my requirement is - I have all this info item name, amount etc in my flat file and I am displaying this in my shopping cart and when they click the buy button it should take them to paypal credit card page [offcourse I want to send this info as a hidden variable to paypal site so that I can get it back once again ] and once they fill up their billing information and credit card number I want to capture all the info[ not credit card info offcourse] they filled up in my web site and based on the success or failure I want to take some action with the info I have (like based on success I want to send mail to client thanking them as well to admin stating you got order. On failure I want to say Invalid Credit Card). How do I accomplish this. Paypal have something called PIN, it seems that I can use that for capturing the data and do some action but what about sending item id, item name without registering those info in my account because this is how I do for Authorize.net. Regards, karthikeyan. - Original Message - From: Johan Lindstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 20, 2002 2:32 PM Subject: Re: Paypal Integration At 00:12 2002-02-20 +0530, karthikeyan wrote: I would like to know how should I integrate my site with paypal. What are all the information I need to pass and what are the information I can capture back and display to the client. If anyone could give me some sample script which is used in real time would be greatly appreciated. An ultra simplistic script is included in the PayPal technical documentation. I could outline the procedure but they have documentation doing that too. Just note that a solid, working solution is a _lot_ more code than their example indicates. The Perl modules you need are: use CGI; use LWP::UserAgent; use HTTP::Request::Common qw(POST); use Crypt::SSLeay; The last one isn't needed unless you want to use HTTPS when verifying the requests coming from PayPal (which is a good idea). /J -- --- -- -- -- -- - - - Johan LindströmSourcerer @ Boss Casinos [EMAIL PROTECTED] Latest bookmark: O'Reilly Network Top Ten FAQs for Web Services http://www.oreillynet.com/lpt/a//webservices/2002/02/12/webservicefaqs.html ___ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs ___ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: pack
Hi, Carl--
Using the input record separator for fixed length records does work,
just as the the fine manual says. However I left out one critical
character in the code I sent last night-- the magic happens when $/ is
assigned a _reference_ to an integer value, as below.
use strict;
{
local $/;
$/ = \4; # must be reference
open IN, test.dbx or die bad open: $!\n;
binmode IN;
my $i = 0;
my $n = 0;
while(IN) {
$n = unpack(I, $_);
printf %02d. %08X\n, $., $n;
$i++;
last if $i 10;
}
close IN;
}
This behavior is documented in Wall, et al: _Programming perl, third
ed_, pg 666 (so I guess its sort of black magic). The above bit also
shows that $. does work in this mode.
--Will
Carl Jolley wrote on Thursday, February 21, 2002 1:35 PM
Subject: Re: pack
On Thu, 21 Feb 2002, Will W wrote:
Sisyphus wrote on Wednesday, February 20, 2002 5:16 PM
Subject: Re: pack
Thanks Will . now for a replacement for '$.' ?? :-))
(Of course it's dead easy to craft one's own incremental counter.)
snip
while (1) {
sysread(READ, $ret, 4);
snip
Everyone's fascination with sysread() got me to poking around in the
camel and cookbook a bit-- and I still can't see the advantage here
of
doing a low-level system call over using read(), which is generally
buffered for optimal efficiency on whatever system your using.
sysread()
makes a lot of sense on a port, but on a disk file I'm not seeing
the
why of it-- maybe someone will enlighten me.
Anyway while poking around I ran yet another way to do the job which
really looks kind of interesting:
[untested-- too much chianti on board to try it tonight]
open IN, $somefile or die gasp! $somefile! Uh! $!\n;
binmode IN;
{ # closure for local
local $/;
$/ = 4; # see the camel
while (IN) { # Should work, but wait there's more
$n = unpack(I, $_); # may have mangled the syntax
$line = $.;# Yep, you get this too!
} # endwhile
} # end localizing closure
Now its time for bed. Spent the day developing a single subroutine
I'm
calling recurse_the_kids because its so dang descriptive of my
feelings
about its convolutions. And I'm out of chianti anyway.
By doing a: $/ = 4; all you've done is to set the input record
seperator
character to a character 4. That will mean that if your file
contained
the characters 0123456789 that doing a on that file would result
in two records being read. The first one would contain 01234 and the
second (and last) one would contain 56789. By default, $/ is the
new-line character. Changing it tells perl that a different character
should be used to separate records. If you set $/ to undefined, then
the first operation on the filehandle will read all the characters
it contains. Setting $/ has no effect if you are using read() or
sysread() to access the data since those function read a specified
number of characters not a record.
[EMAIL PROTECTED] Carl Jolley
All opinions are my own and not necessarily those of my employer
k
___
Perl-Win32-Users mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: pack
- Original Message -
From: Will W [EMAIL PROTECTED]
Everyone's fascination with sysread() got me to poking around in the
camel and cookbook a bit-- and I still can't see the advantage here of
doing a low-level system call over using read(), which is generally
buffered for optimal efficiency on whatever system your using. sysread()
makes a lot of sense on a port, but on a disk file I'm not seeing the
why of it-- maybe someone will enlighten me.
To have a closer look at 'read' versus 'sysread' I did a benchmark test.
I found that 'sysread' took (almost exactly) twice as long as 'read'.
So that was a pretty pertinent point you raised, Will.
Guess I'd have to agree that I, too, don't see the advantage of using
sysread in preference to read.
I also ran the same code using the trick with '$/' (which is also mentioned
in perlvar, btw). Not surprisingly it's pretty much the same speed as
'read'.
Here's a cut'n'paste of both the code I ran and the result I got. Sorry if
it gets wrapped inconveniently.
use Benchmark;
timethese (1, {
'sysread' = 'open (READ, d:/pscrpt/tab.new)
or die Cannot open READ: $!;
binmode READ;
while (sysread(READ, $read, 4) == 4) {
$mod = unpack(I, $read);
}
print $mod\n;
close (READ) or die Cannot close READ: $!;',
'read' = 'open (READ, d:/pscrpt/tab.new)
or die Cannot open READ: $!;
binmode READ;
while (read(READ, $read, 4) == 4) {
$mod = unpack(I, $read);
}
print $mod\n;
close (READ) or die Cannot close READ: $!;',
'local' = '{
local $/;
$/ = \4;
open (READ, d:/pscrpt/tab.new)
or die Cannot open READ: $!;
binmode READ;
while (READ) {
$mod = unpack(I, $_);
}
print $mod\n;
close (READ) or die Cannot close READ: $!;
}',
});
##
Benchmark: timing 1 iterations of local, read, sysread...
27112421
local: 25 wallclock secs (24.90 usr + 0.09 sys = 24.98 CPU) @ 0.04/s
(n=1)
(warning: too few iterations for a reliable count)
27112421
read: 26 wallclock secs (26.42 usr + 0.10 sys = 26.52 CPU) @ 0.04/s
(n=1)
(warning: too few iterations for a reliable count)
27112421
sysread: 53 wallclock secs (34.20 usr + 17.39 sys = 51.59 CPU) @ 0.02/s
(n=1)
(warning: too few iterations for a reliable count)
Cheers,
Rob
___
Perl-Win32-Users mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
Re: pack
Sisyphus wrote: - Original Message - From: Will W [EMAIL PROTECTED] Everyone's fascination with sysread() got me to poking around in the camel and cookbook a bit-- and I still can't see the advantage here of doing a low-level system call over using read(), which is generally buffered for optimal efficiency on whatever system your using. sysread() makes a lot of sense on a port, but on a disk file I'm not seeing the why of it-- maybe someone will enlighten me. To have a closer look at 'read' versus 'sysread' I did a benchmark test. I found that 'sysread' took (almost exactly) twice as long as 'read'. So that was a pretty pertinent point you raised, Will. Guess I'd have to agree that I, too, don't see the advantage of using sysread in preference to read. I also ran the same code using the trick with '$/' (which is also mentioned in perlvar, btw). Not surprisingly it's pretty much the same speed as 'read'. sysread is unbuffered. To get the same kind of results, you would need to read a block of data and then feed the data 4 bytes at a time from a subroutine that holds the buffered data and do another read when you run out of data in that block. -- ,-/- __ _ _ $Bill Luebkert ICQ=14439852 (_/ / )// // DBE Collectibles Mailto:[EMAIL PROTECTED] / ) /-- o // // http://dbecoll.tripod.com/ (Free site for Perl) -/-' /___/__/_/_ Castle of Medieval Myth Magic http://www.todbe.com/ ___ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
