[32707] in Perl-Users-Digest
Perl-Users Digest, Issue: 3971 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jun 23 05:17:19 2013
Date: Sun, 23 Jun 2013 02:17:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 23 Jun 2013 Volume: 11 Number: 3971
Today's topics:
Re: Perl script to exe <jismagic@gmail.com>
Re: Perl script to exe <news@lawshouse.org>
Re: Perl script to exe <jurgenex@hotmail.com>
Re: regex question <jimsgibson@gmail.com>
Re: regex question <jblack@nospam.com>
Re: regex question <ben@morrow.me.uk>
Re: regex question <derykus@gmail.com>
Re: WWW::Mechanize install problem <ben@morrow.me.uk>
Re: WWW::Mechanize install problem <dave@invalid.invalid>
Re: WWW::Mechanize install problem <ben@morrow.me.uk>
Re: WWW::Mechanize install problem <dave@invalid.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 21 Jun 2013 10:20:05 -0700 (PDT)
From: jis <jismagic@gmail.com>
Subject: Re: Perl script to exe
Message-Id: <ee3df3f7-5e73-4e00-8bc3-f1c2a6bedef3@googlegroups.com>
On Thursday, June 20, 2013 2:23:42 PM UTC+5:30, Peter Arnhold wrote:
> Am 17.06.2013 09:26, schrieb jis:
>
> > On Saturday, June 15, 2013 3:16:56 PM UTC+5:30, jis wrote:
>
> >> I have used perl2exe on windows xp platform to convert perl script to exe.
>
> >>
>
> >>
>
> >>
>
> >> But since windows 7, it has not been dependable.
>
> >>
>
> >>
>
> >>
>
> >> par pp also do not look like it works on all windows 7 machines.
>
> >>
>
> >>
>
> >>
>
> >> I have googled it and didnt find anyting significant.
>
> >>
>
> >>
>
> >>
>
> >> Please let me know what you guys use on windows 7 platform to get it working..
>
> >>
>
> >>
>
> >>
>
> >>
>
> >>
>
> >> thanks
>
> >>
>
> >> jis
>
> >
>
> > Hi,
>
> >
>
> > Since nobody replied to message yet, I have to ask for another help.
>
> >
>
> > How do i run a standalone created on 64 bit wndows 7 run on a 32 bit windows 7.
>
> >
>
> > I get an incompatibility errror when i do this..
>
> >
>
> > thanks,
>
> > jis
>
> >
>
>
>
> Use Windows 64-bit, perl 32-bit and perl2exe 32-bit. Created files are
>
> running on Win7 32-bit. I do it almost every day.
>
>
>
> Peter
Peter,
Can you try to convert the following script for 32 bit platform from window 7 64 bit please??
use strict;
use Net::SFTP::Foreign;
use Net::SFTP::Foreign::Constants qw (:flags);
use Net::SMTP;
use File::Basename;
use Sys::Hostname;
use File::Compare;
my $temp="temp.txt";
my $file = $ARGV[1];
my $remote = $ARGV[2];
my $remoteIpAddress=$ARGV[0] ;
my $SFTP_user="user";
my $SFTP_password="pwd";
my $SFTP_host=$remoteIpAddress;
my %args = (backend => 'Net_SSH2',
username => $SFTP_user,
password => $SFTP_password);
$Net::SFTP::Foreign::debug = 0;
my $sftp = Net::SFTP::Foreign->new($SFTP_host,%args) or
die "Unable to connect to $SFTP_host : $!\n";
while(1)
{
open(INF,"<".$file);
binmode INF;
$sftp->put(\*INF,$remote);
die "Error transferring $file to $SFTP_host::$remote\n".$sftp->status() if $sftp->error;
close(INF);
print "$file transfered to $SFTP_host\n";
sleep(1);
$sftp->get($remote,$temp, numbered => 1) or die "file transfer failed: " . $sftp->error;
if (compare($file,$temp) == 0)
{
print "File read back- found equal\n";
}
else
{
print "File read back- found NOTequal\n";
}
unlink $temp;
print "Removing file: $remote\n";
$sftp->remove($remote);
die "Error removing file from $remote\n".$sftp->status() if $sftp->error;
sleep(1);
}
$sftp = undef;
------------------------------
Date: Fri, 21 Jun 2013 18:42:45 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Perl script to exe
Message-Id: <ieidnRSZINQIDVnMnZ2dnUVZ8gydnZ2d@giganews.com>
On 21/06/13 18:20, jis wrote:
> Can you try to convert the following script for 32 bit platform from window 7 64 bit please??
>
> use strict;
> useNet::SFTP::Foreign;
> useNet::SFTP::Foreign::Constants qw (:flags);
> useNet::SMTP;
> use File::Basename;
> use Sys::Hostname;
> use File::Compare;
> my $temp="temp.txt";
>
> my $file = $ARGV[1];
... etc
Where is the architecture-dependent code in this program?
--
Henry Law Manchester, England
------------------------------
Date: Fri, 21 Jun 2013 10:56:39 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl script to exe
Message-Id: <9l49s8ptsq7jelrvsv0eijub2t2i7p5651@4ax.com>
jis <jismagic@gmail.com> wrote:
>On Thursday, June 20, 2013 2:23:42 PM UTC+5:30, Peter Arnhold wrote:
>> Am 17.06.2013 09:26, schrieb jis:
>>
>> > On Saturday, June 15, 2013 3:16:56 PM UTC+5:30, jis wrote:
>>
>> >> I have used perl2exe on windows xp platform to convert perl script to exe.
>>
>> >>
>>
>> >>
>>
>> >>
>>
Is there a specific reason why you have 7 empty lines here?
>> >> But since windows 7, it has not been dependable.
>>
>> >>
>>
>> >>
>>
>> >>
>>
Is there a specific reason why you have 7 empty lines here?
>> >> par pp also do not look like it works on all windows 7 machines.
>>
>> >>
>>
>> >>
>>
>> >>
>>
Is there a specific reason why you have 7 empty lines here?
>> >> I have googled it and didnt find anyting significant.
>>
>> >>
>>
>> >>
>>
>> >>
>>
Is there a specific reason why you have 7 empty lines here?
>> >> Please let me know what you guys use on windows 7 platform to get it working..
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >>
>>
Is there a specific reason why you have 11 empty lines here?
Over 30 quoted blank lines with 5 lines of quoted text interspersed.
Is there a specific reason for that madness?
jue
------------------------------
Date: Fri, 21 Jun 2013 08:50:37 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: regex question
Message-Id: <210620130850374203%jimsgibson@gmail.com>
In article <87ip18pm7x.fsf@sapphire.mobileactivedefense.com>, Rainer
Weikusat <rweikusat@mssgmbh.com> wrote:
> John Black <jblack@nospam.com> writes:
> > How do I write a regex that will match on
> >
> > string
> >
> > but not
> >
> > string_
> >
> > I want it to match if it detects string followed by anything but an
> > underscore including if
> > string is at the end of the line or if its followed by a space or
> > whatever.
>
> /string(?!_)/
To elucidate: that is a "zero-width negative look-ahead assertion". For
more information, see 'perldoc perlre' and search or scroll to the
section on "Extended Patterns", specifically the subsection on
"Look-Around Assertions".
--
Jim Gibson
------------------------------
Date: Fri, 21 Jun 2013 14:45:59 -0500
From: John Black <jblack@nospam.com>
Subject: Re: regex question
Message-Id: <MPG.2c2e6975854fe8c198977d@news.eternal-september.org>
In article <210620130850374203%jimsgibson@gmail.com>, jimsgibson@gmail.com says...
>
> In article <87ip18pm7x.fsf@sapphire.mobileactivedefense.com>, Rainer
> Weikusat <rweikusat@mssgmbh.com> wrote:
>
> > John Black <jblack@nospam.com> writes:
> > > How do I write a regex that will match on
> > >
> > > string
> > >
> > > but not
> > >
> > > string_
> > >
> > > I want it to match if it detects string followed by anything but an
> > > underscore including if
> > > string is at the end of the line or if its followed by a space or
> > > whatever.
> >
> > /string(?!_)/
>
> To elucidate: that is a "zero-width negative look-ahead assertion". For
> more information, see 'perldoc perlre' and search or scroll to the
> section on "Extended Patterns", specifically the subsection on
> "Look-Around Assertions".
This is great. Thanks to both of you. It does work for my example but I tried to apply it
to a different example and its not working. I want to match on some pattern that is not
followed by some other string later but not necessarily immediately following like my
original example.
I tried /pattern1.*(?!string)/
but this seems to match pattern1 even if "string" comes later somewhere on the line.
John Black
------------------------------
Date: Fri, 21 Jun 2013 23:41:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: regex question
Message-Id: <id1f9a-vp62.ln1@anubis.morrow.me.uk>
Quoth John Black <jblack@nospam.com>:
>
> This is great. Thanks to both of you. It does work for my example but
> I tried to apply it
> to a different example and its not working. I want to match on some
> pattern that is not
> followed by some other string later but not necessarily immediately
> following like my
> original example.
>
> I tried /pattern1.*(?!string)/
>
> but this seems to match pattern1 even if "string" comes later somewhere
> on the line.
Yes. Think a bit about how it matches. If you match (say)
"foo bar" =~ /foo.*(?!bar)/
then first the 'foo' matches the 'foo', then the .* matches the ' bar',
then perl tries to match /bar/ at that point. It doesn't match (we're at
the end of the string), so the (?!) succeeds, and the whole match
succeeds.
Running a match under 'use re "debug";' might help you to understand
what's going on, though it tends to produce so much output it takes a
bit of practice to sort through it.
You want to assert 'starting immediately after the 'foo', it must not be
possible to match any amount of text followed by 'bar''. That is,
/foo(?!.*bar)/
with the .* inside the (?!). (You may also want /s.)
Ben
------------------------------
Date: Sat, 22 Jun 2013 02:28:22 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: regex question
Message-Id: <kq3qnu$8m0$1@speranza.aioe.org>
On 6/21/2013 12:45 PM, John Black wrote:
> In article <210620130850374203%jimsgibson@gmail.com>, jimsgibson@gmail.com says...
>>
>> [...]
>
> This is great. Thanks to both of you. It does work for my example but I tried to apply it
> to a different example and its not working. I want to match on some pattern that is not
> followed by some other string later but not necessarily immediately following like my
> original example.
>
> I tried /pattern1.*(?!string)/
>
> but this seems to match pattern1 even if "string" comes later somewhere on the line.
>
Another alternative to lookaheads is the /p switch which effectively
partitions a successful match into pre-match, match, and post-match:
if ( "foo bar" =~ /foo/p and ${^POSTMATCH} !~ /bar/ ) ...
So, ${^PREMATCH} is "", ${^MATCH} is"foo", and ${^POSTMATCH} is " bar"
P.S. ( "p" in /p doesn't mean "partition" but it's still an easy way to
remember what happens. See perlre ).
--
Charles DeRykus
------------------------------
Date: Fri, 21 Jun 2013 18:46:38 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: WWW::Mechanize install problem
Message-Id: <u4ge9a-6742.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> Noticed a mention of this on the NG yesterday. Looked useful so I
> tried to install it. Now it might be my ancient OS/2 system but, using
> perl 5.16.0 ...
[...]
>
> Checksum for
> t:/CPAN/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz ok
> tar.exe: Skipping to next header
> tar.exe: A lone zero block at 770
>
> tar.exe: Error
> exit delayed from previous errors
This output is rather confusing: CPAN is actually trying to untar this
file twice, because the first time failed. The first attempt was with
gzip -dc < "WWW-...tar.gz" | tar xf -
(except that both tar and gzip are the entries in your CPAN config,
which are probably full paths). It's using an explicit pipeline (rather
than -xzf) because many tars don't support -z.
This command is failing with the error above; I don't know why; but it
seems to have successfully extracted at least something, given the
output below.
> Uncompressed
> t:/CPAN/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz
> successfully
Now CPAN is trying again: it's assuming the invocation above failed
because your tar can't read from a pipe (apparently this is a thing that
happens), so it's manually decompressing the file. Probably it used
Compress::Zlib for that, since it was core in 5.16, but otherwise it
used gzip -dc.
> Using Tar:d:/usr/bin/tar.exe xf "WWW-Mechanize-1.72.tar":
> tar.exe: Skipping to next header
> tar.exe: A lone zero block at 790
>
> tar.exe: Error
> exit delayed from previous errors
It then ran the tar command above, which failed again for what looks
like the same reason as before.
> Couldn't untar WWW-Mechanize-1.72.tar
> Package contains both files[WWW-Mechanize-1.72.tar] and
> directories[WWW-Mechanize-1.72]; not recognized as a perl package,
> giving up
This, I presume, is because something was successfully extracted, but
the decompressed tar was not removed; CPAN.pm is just being stupid.
Do you have prefer_external_tar set in your CPAN config? If you do you
might try un-setting it, which will use Archive::Tar instead of tar(1).
> If I manually fetch the gz file from
> http://search.cpan.org/CPAN/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.t
> ar.gz and either use tar to uncompress/untar or use gzip to uncompress
> and then exract the tar I get no errors. The gz file CPAN downloaded
> and the one I downloaded from the above URL are the same file - They
> diff clean. But the extracted tar file differs in size. The CPAN one
> comes out at 404713 bytes whilst the manually extracted one comes out
> at 394752 bytes.
Hmm, this is interesting, though it doesn't explain why the first
attempt (with gzip(1)) failed. I find it hard to believe, but it looks
to me as though this bit of code in CPAN::Tarzip
sub gunzip {
my($self,$write) = @_;
my $read = $self->{FILE};
if ($CPAN::META->has_inst("Compress::Zlib")) {
my($buffer,$fhw);
$fhw = FileHandle->new(">$write")
or $CPAN::Frontend->mydie("Could not open >$write: $!");
my $gz = Compress::Zlib::gzopen($read, "rb")
or $CPAN::Frontend->mydie("Cannot gzopen $read: $!\n");
$fhw->print($buffer)
while $gz->gzread($buffer) > 0 ;
$CPAN::Frontend->mydie("Error reading from $read: $!\n")
if $gz->gzerror != Compress::Zlib::Z_STREAM_END();
$gz->gzclose() ;
$fhw->close;
return 1;
is rather notably missing a binmode() on the output file. (I find this
hard to believe because presumably Win32 also needs binmode, and it
seems really unlikely noone would have noticed this.) You could try
putting in
binmode($fhw);
after the FileHandle->new statement, and see if it makes a difference.
Ben
------------------------------
Date: Sat, 22 Jun 2013 13:34:32 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: WWW::Mechanize install problem
Message-Id: <fV45K0OBJxbE-pn2-dsBMVcwIRZ5c@paddington.bear.den>
On Fri, 21 Jun 2013 17:46:38 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
Hi Ben
>
> Quoth "Dave Saville" <dave@invalid.invalid>:
> > Noticed a mention of this on the NG yesterday. Looked useful so I
> > tried to install it. Now it might be my ancient OS/2 system but, using
> > perl 5.16.0 ...
> [...]
> >
> > Checksum for
> > t:/CPAN/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz ok
> > tar.exe: Skipping to next header
> > tar.exe: A lone zero block at 770
> >
> > tar.exe: Error
> > exit delayed from previous errors
>
> This output is rather confusing: CPAN is actually trying to untar this
> file twice, because the first time failed. The first attempt was with
>
> gzip -dc < "WWW-...tar.gz" | tar xf -
>
> (except that both tar and gzip are the entries in your CPAN config,
> which are probably full paths). It's using an explicit pipeline (rather
> than -xzf) because many tars don't support -z.
>
> This command is failing with the error above; I don't know why; but it
> seems to have successfully extracted at least something, given the
> output below.
>
> > Uncompressed
> > t:/CPAN/sources/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.tar.gz
> > successfully
>
> Now CPAN is trying again: it's assuming the invocation above failed
> because your tar can't read from a pipe (apparently this is a thing that
> happens), so it's manually decompressing the file. Probably it used
> Compress::Zlib for that, since it was core in 5.16, but otherwise it
> used gzip -dc.
Now this I don't understand. My tar understands z and I frequenty move
stuff like so:
tar -C foo -xf - | tar -xvpf -
Later ... It seem that gzip/gunzip is adding crud, or at least a hex
zero, on the end of stdout:
gzip -dc < WWW-Mechanize-1.72.tar.gz | tar -xvf -
WWW-Mechanize-1.72/
WWW-Mechanize-1.72/bin/
WWW-Mechanize-1.72/Changes
.......
WWW-Mechanize-1.72/t/frames.html
tar: Skipping to next header
tar: A lone zero block at 770
tar: Error exit delayed from previous errors
> > Using Tar:d:/usr/bin/tar.exe xf "WWW-Mechanize-1.72.tar":
> > tar.exe: Skipping to next header
> > tar.exe: A lone zero block at 790
> >
> > tar.exe: Error
> > exit delayed from previous errors
>
> It then ran the tar command above, which failed again for what looks
> like the same reason as before.
>
> > Couldn't untar WWW-Mechanize-1.72.tar
> > Package contains both files[WWW-Mechanize-1.72.tar] and
> > directories[WWW-Mechanize-1.72]; not recognized as a perl package,
> > giving up
>
> This, I presume, is because something was successfully extracted, but
> the decompressed tar was not removed; CPAN.pm is just being stupid.
>
> Do you have prefer_external_tar set in your CPAN config? If you do you
> might try un-setting it, which will use Archive::Tar instead of tar(1).
>
Ah, set to 1. Changed to 0 and plus the binmode fix below and all
seems well - Apart from the usual problem with CPAN and tests which we
have yet to solve.
> > If I manually fetch the gz file from
> > http://search.cpan.org/CPAN/authors/id/J/JE/JESSE/WWW-Mechanize-1.72.t
> > ar.gz and either use tar to uncompress/untar or use gzip to uncompress
> > and then exract the tar I get no errors. The gz file CPAN downloaded
> > and the one I downloaded from the above URL are the same file - They
> > diff clean. But the extracted tar file differs in size. The CPAN one
> > comes out at 404713 bytes whilst the manually extracted one comes out
> > at 394752 bytes.
>
> Hmm, this is interesting, though it doesn't explain why the first
> attempt (with gzip(1)) failed. I find it hard to believe, but it looks
> to me as though this bit of code in CPAN::Tarzip
>
> sub gunzip {
> my($self,$write) = @_;
> my $read = $self->{FILE};
> if ($CPAN::META->has_inst("Compress::Zlib")) {
> my($buffer,$fhw);
> $fhw = FileHandle->new(">$write")
> or $CPAN::Frontend->mydie("Could not open >$write: $!");
> my $gz = Compress::Zlib::gzopen($read, "rb")
> or $CPAN::Frontend->mydie("Cannot gzopen $read: $!\n");
> $fhw->print($buffer)
> while $gz->gzread($buffer) > 0 ;
> $CPAN::Frontend->mydie("Error reading from $read: $!\n")
> if $gz->gzerror != Compress::Zlib::Z_STREAM_END();
> $gz->gzclose() ;
> $fhw->close;
> return 1;
>
> is rather notably missing a binmode() on the output file. (I find this
> hard to believe because presumably Win32 also needs binmode, and it
> seems really unlikely noone would have noticed this.) You could try
> putting in
>
> binmode($fhw);
>
> after the FileHandle->new statement, and see if it makes a difference.
Bingo - that gets the file size correct.
--
Regards
Dave Saville
------------------------------
Date: Sat, 22 Jun 2013 17:34:32 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: WWW::Mechanize install problem
Message-Id: <o90h9a-frl2.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Fri, 21 Jun 2013 17:46:38 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > Hmm, this is interesting, though it doesn't explain why the first
> > attempt (with gzip(1)) failed. I find it hard to believe, but it looks
> > to me as though this bit of code in CPAN::Tarzip
> >
> > sub gunzip {
> > my($self,$write) = @_;
> > my $read = $self->{FILE};
> > if ($CPAN::META->has_inst("Compress::Zlib")) {
> > my($buffer,$fhw);
> > $fhw = FileHandle->new(">$write")
> > or $CPAN::Frontend->mydie("Could not open >$write: $!");
> > my $gz = Compress::Zlib::gzopen($read, "rb")
> > or $CPAN::Frontend->mydie("Cannot gzopen $read: $!\n");
> > $fhw->print($buffer)
> > while $gz->gzread($buffer) > 0 ;
> > $CPAN::Frontend->mydie("Error reading from $read: $!\n")
> > if $gz->gzerror != Compress::Zlib::Z_STREAM_END();
> > $gz->gzclose() ;
> > $fhw->close;
> > return 1;
> >
> > is rather notably missing a binmode() on the output file. (I find this
> > hard to believe because presumably Win32 also needs binmode, and it
> > seems really unlikely noone would have noticed this.) You could try
> > putting in
> >
> > binmode($fhw);
> >
> > after the FileHandle->new statement, and see if it makes a difference.
>
> Bingo - that gets the file size correct.
You should definitely report this as a bug, though I still can't see how
anyone has failed to notice it on Win32.
Ben
------------------------------
Date: Sat, 22 Jun 2013 17:30:49 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: WWW::Mechanize install problem
Message-Id: <fV45K0OBJxbE-pn2-Eo8ezjW3RTWW@paddington.bear.den>
On Sat, 22 Jun 2013 16:34:32 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> You should definitely report this as a bug, though I still can't see how
> anyone has failed to notice it on Win32.
>
> Ben
>
Done
--
Regards
Dave Saville
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3971
***************************************
