[24317] in Perl-Users-Digest
Perl-Users Digest, Issue: 6508 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 3 06:05:46 2004
Date: Mon, 3 May 2004 03:05:05 -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 Mon, 3 May 2004 Volume: 10 Number: 6508
Today's topics:
Re: Books online???? <tadmc@augustmail.com>
Re: Can perl be used for cookie setting? <Joe.Smith@inwap.com>
Re: Changing from C thought to Perl (Bryan Castillo)
Re: free source guestbook (finished) <robin @ infusedlight.net>
Re: free source search engine (simple) ## comments? <Joe.Smith@inwap.com>
Re: How to call another program <sbryce@scottbryce.com>
Re: How to call another program <David@Grey.con>
Re: How to call another program <sbryce@scottbryce.com>
Re: How to call another program <tadmc@augustmail.com>
Re: How to call another program <tadmc@augustmail.com>
Re: How to call another program <Joe.Smith@inwap.com>
Re: Improving Robin's blogger <robin @ infusedlight.net>
Re: need help with security (Anno Siegel)
Re: need help with security <Joe.Smith@inwap.com>
Re: Perl Embedding Question <usenet@morrow.me.uk>
Re: Problem with global variables <raslebol@duspam.fr>
Re: single-byte values (Don Stock)
Re: single-byte values <tassilo.parseval@rwth-aachen.de>
What happend to www.perldoc.com?? (Rex Gustavus Adolphus)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 3 May 2004 01:09:13 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Books online????
Message-Id: <slrnc9bog9.1rt.tadmc@magna.augustmail.com>
Henry Williams <> wrote:
>
>>>>They are out there and you should report them to O'Reilly.
>>>
>>>
>>> I was hoping you were going to! I already have a fulltime job.
>>>
>>Meaning what?
>
> It's just that this NG is a very very unfriendly place. You know..
> RTFM...
Assuming that reading the manual is unhelpful is silliness.
It depends on whether the manual answers the particular question or not.
If it answers the question then it is friendly, not unfriendly.
Without knowing the question and the recommended docs, nobody can
say what the friendliness polarity is.
> civility is a rare commodity here, as I've lurked I've noticed
> this. And while it may be true that there are those who post who
> should have done a little more research themselves, it profits little
> to berate them.
They reap what they sow, it is human nature.
(We _are_ humans here, I understand...)
> In the larger context, I find it amusing that there are those who
> would spend their time berating rather than ignoring.
So when someone takes cuts in line in front of you, you don't say anything?
You are a bigger man than I.
But I will take your suggestion, and have arranged to automatically
ignore some posts in this newsgroup.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 03 May 2004 08:42:46 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: Can perl be used for cookie setting?
Message-Id: <aCnlc.20551$kh4.1221606@attbi_s52>
Danny wrote:
> I cannot change the extensions of all of my html files.
> So I need something that gets called automatically as
> the html page is loaded.
> I also need to pass a variable to and from the cgi script.
> This needs to be done transparaently.
You could do like what Sun did back in the early days of the www.
Instead of having URLs like http://www.sun.com/products/solaris.html
they had http://www.sun.com/show/products/solaris.html where
"show" is actually a CGI with an aliased name. The "show" program
used $ENV{PATH_TRANSLATED} to locate the plain HTML file. It then
added HTTP headers and HTML for navigation to everything it output.
-Joe
------------------------------
Date: 2 May 2004 21:28:57 -0700
From: rook_5150@yahoo.com (Bryan Castillo)
Subject: Re: Changing from C thought to Perl
Message-Id: <1bff1830.0405022028.322ba1f5@posting.google.com>
Ala Qumsieh <xxala_qumsiehxx@xxyahooxx.com> wrote in message news:<_Ydfc.22513$9H1.5335@newssvr27.news.prodigy.com>...
> Rob Perkins wrote:
> > Brad Baxter <bmb@ginger.libs.uga.edu> wrote:
> >
> >
> >>Global variables are not a bad thing per se. Side effects are not a bad
> >>thing per se.
>
> > No, not a bad thing, per se. Unless you need/want to share your code.
>
> I agree with most of what you say, but sometimes you can't help it.
> There are programs that are very difficult to write without global vars,
> like GUIs for example. Here, a program sits waiting for the user to do
> something, and has to react accordingly. It is extremely difficult to
> bypass using global vars, and in fact global vars make the program much
> simpler and easier to maintain.
I completly disagree with that. With language like perl using Tk it
makes it very easy to attach methods to callback events, where you can
draw your variables out of objects, you can also use closures. I've
found myself writing gui apps very often, where I've said to myself "I
really wish this were some generic widget I could plug into a tabbed
pane or something in a larger GUI application". Staying away from
global variables and using objects with callbacks to methods has
helped me do that.
This is the style I tend to use (below). I find it easier to maintain
than GUI's based on global variables.
# just an example below of using a method callback for
# a button press, and using an object to access other widgets
# text entry.
package App;
use strict;
use warnings;
use Tk;
sub new {
my $self = bless {};
$self->{_nclicks} = 0;
$self->{win} = MainWindow->new;
$self->{win}->title("My Window");
$self->{txt} = $self->{win}->Entry(-width=>10)->pack;
$self->{btn} = $self->{win}->Button(
-command => [\&on_key_press, $self],
-text => 'Press Me'
)->pack;
return $self;
}
sub on_key_press {
my ($self) = @_;
$self->{_nclicks}++;
print "Button pressed $self->{_nclicks} times\n";
print "Text Entry: ", $self->getTxt(), "\n";
}
sub getTxt {
my ($self) = @_;
return $self->{txt}->get;
}
package main;
use strict;
use warnings;
use Tk;
App->new;
MainLoop();
------------------------------
Date: Sun, 2 May 2004 20:24:42 -0800
From: "Robin" <robin @ infusedlight.net>
Subject: Re: free source guestbook (finished)
Message-Id: <c74hm4$qb3$1@news.f.de.plusline.net>
"Juha Laiho" <Juha.Laiho@iki.fi> wrote in message
news:c6m988$21a$1@ichaos.ichaos-int...
> "Robin" <robin @ infusedlight.net> said:
> >> Ouch. First gethead just to determine whether or not the file exists,
> >> and if it did succeed, do it again to actually store the read contents.
> >> So, opening/locking/reading/unlocking/closing the file twice for each
> >> request (if using your original gethead code)? In addition there would
> >> of course be the possible race condition that the header file gets
> >> removed between the two gethead calls; the first call to gethead
telling
> >> that the file is there, and thus default content is not needed, and the
> >> second trying to read content from the file that no longer exists.
>
> >And how would I fix this race condition?
>
> By only opening/reading the file once -- returning either content or
> a failure status, instead of reading once for status and re-reading
> if the status was ok.
>
> Don't worry -- you're not the first one having done this; in Unix
> operating systems there's an "access" library call that is to be
> used for checking whether the current user has desired kind of access
> to a specified file. The problem of using this library call anyuwhere
> is exactly as with your code -- the information might be invalid at
> the time it reaches your code. Similarly, the solution there is to not
> make the "access" call at all, but to attempt to open the file with
> the desired access mode, and use the failure code from the "open"
> function. There, either the file open did succeed, or it did not -
> no time is provided for someone to change the file between checking
> and accessing it.
Thanks, my gethead and getfoot subs are going to be totally rewritten. So
Unix systems have a race condition with this libary call? Or did I
misunderstand you?
-Robin
------------------------------
Date: Mon, 03 May 2004 09:28:50 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: free source search engine (simple) ## comments?
Message-Id: <mholc.21436$I%1.1563579@attbi_s51>
gnari wrote:
> "Robin" <webmaster @ infusedlight . net> wrote in message
>>how can this one be used to hack my site? I'm curious...
>
> it is a consequence of your habit of keeping securty related files
> in your web directory. in the same directory where your
> 'search engine' is reading. do you see the implications of that ?
Yes, Robin, take gnari's advice.
When laying out a web site that will display text (possibly malicious text)
submitted by users, you should be using at least four distinct directories.
DOCUMENT_ROOT = Top level directory holding HTML files.
Files in it or below are accessable via URL.
cgi-bin = An alias pointing to a directory outside of DOCUMENT_ROOT.
Executables only: no HTML, no images, no password files.
config+auth = Passwords and such, in a directory outside of DOCUMENT_ROOT.
Updated by webmaster, and carefully written CGI programs.
Must not be accessable directly via URL.
upload+blogs = Place for data submitted by users. Having writable
files directly accessable via URL is not recommended.
Should be outside DOCUMENT_ROOT, preferrably stored as
as records in a database.
-Joe
------------------------------
Date: Sun, 02 May 2004 22:19:06 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: How to call another program
Message-Id: <109bi1h8t25gea8@corp.supernews.com>
David Grey wrote:
> # sleep 10
^
> sleep 10 gave me an 500 error.
The error was due to the missing semicolon. Do you test your scripts
locally before you post them? If not, you are going to be at this for a
long time before you get it working!
------------------------------
Date: Mon, 03 May 2004 04:53:04 GMT
From: David Grey <David@Grey.con>
Subject: Re: How to call another program
Message-Id: <4095C931.DDB549B5@Grey.con>
Scott Bryce wrote:
> David Grey wrote:
>
> > # sleep 10
> ^
> > sleep 10 gave me an 500 error.
>
> The error was due to the missing semicolon. Do you test your scripts
> locally before you post them? If not, you are going to be at this for a
> long time before you get it working!
Well, I don't have perl on my PC, thanks for the help, did you
happen to see why the request to http://www.domain.com/copyprog.pl
did not work?
------------------------------
Date: Sun, 02 May 2004 23:31:06 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: How to call another program
Message-Id: <109bm8hql23vtc3@corp.supernews.com>
David Grey wrote:
> Well, I don't have perl on my PC, thanks for the help, did you
> happen to see why the request to http://www.domain.com/copyprog.pl
> did not work?
I don't have much experience with LWP::UserAgent, so I won't be much
help there, I was only commenting on why the sleep command caused your
script to fail.
But I did try pointing my browser to http://www.domain.com/copyprog.pl
directly and got a 404 File Not Found error. I also noticed that you
don't check the value of $result to see if it is valid.
If you are sending a request to a URL that does not exist, asking
someone here to fix your script isn't going to help.
------------------------------
Date: Mon, 3 May 2004 00:52:54 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: How to call another program
Message-Id: <slrnc9bnhm.1rt.tadmc@magna.augustmail.com>
David Grey <David@Grey.con> wrote:
> but I am living in the real world
> and need this done yesterday, I don't have time for theory
> and a learning experience today, I need this fixed.
If you don't have time to learn it yourself, you might consider
hiring someone who has already taken the time to learn it.
http://jobs.perl.org
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 3 May 2004 00:59:46 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: How to call another program
Message-Id: <slrnc9bnui.1rt.tadmc@magna.augustmail.com>
David Grey <David@Grey.con> wrote:
> Well, I don't have perl on my PC,
Why not?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Mon, 03 May 2004 08:02:23 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: How to call another program
Message-Id: <j0nlc.15617$TD4.1991056@attbi_s01>
David Grey wrote:
> That is not what I want to do (from what I can tell) I want to :
>
> print "Location: http://www.domain.com/cgi-bin/copyprog.pl\n\n";
>
> run this script before running the rest of the script. When I run the
> above it goes off and does not run the rest of the script that this
> is in.
Unless you are using frames or <img src>, the browser processes one URL
at a time. If the original request is to cgi-bin/part-1.pl, you've
got two choices:
1) Let part-1.pl go to completion, and output the Location at the end.
2) Output the Location at beginning of part-1.pl, but then you've got
the problem that part-1.pl will be prematurely terminated when
the browser closes the connect as it switches to copyprog.pl.
You could have part-1.pl output HTML that runs two CGIs in parallel.
<frameset rows="100%,*">
<frame src="/cgi-bin/part-2.pl">
<frame src="http://www.domain.com/cgi-bin/copyprog.pl">
</frameset>
<noframes>
<body><img src="/cgi-bin/part-2.pl" width=1 height=1">
<img src="http://www.domain.com/cgi-bin/copyprog.pl" width=1 height=1>
</body>
</noframes>
-Joe
------------------------------
Date: Sun, 2 May 2004 20:26:27 -0800
From: "Robin" <robin @ infusedlight.net>
Subject: Re: Improving Robin's blogger
Message-Id: <c74hm7$qb3$2@news.f.de.plusline.net>
"Joe Smith" <Joe.Smith@inwap.com> wrote in message
news:fDIkc.6645$Ik.592430@attbi_s53...
> Robin wrote:
>
> > so, what would you do to the blogger.pl script to make it "work"? I
don't
> > need code, just some friendly advice
>
> There are many other free blogger scripts, why would anyone use yours?
>
> That is a serious question.
>
> Back in 1994, anything that "worked" in a CGI environment was snapped up
> as there was nothing else to compare with. This gave rise to code
> that appeared to work at first glance, but did not scale well when its
> database grew or the number of hits per second increased. (Matt Wright's
> deservedly critisized scripts being case in point.)
>
> But now you have things like the Slashcode running http://slashdot.org
> and fully functional blogging code like Moveable Type. A new programmer
> may be quite proud of his/her first working program, but that by itself
> does not make it worthwhile for anyone else to use.
>
> My advice is to investigate the competition. Document how your code
> compares to the others. In addition to listing the features your
> program has that the others don't, include the known limitations or
> deficiencies. "I'm giving away this code as an example for Perl
> beginners and non-programmers" belongs in the minus column.
>
> Create professional-quality user documenation. Accurately describe
> what the program is expected to do and what it is not expected to do.
> If the response time doubles after the one hundred and first username
> is added to the password file, document that.
>
> Tidy up the code. Imagine that your code was going to be presented
> as a case study near the end of the semester in an intermediate level
> Perl programming class. Picture 30 students, after having had several
> weeks exposure to good programming practices, nitpicking each line and
> giving ratings like "typical newbie mistake" or "great idiom!".
>
> I would also recommend taking the time to read a large number of the
> modules that come bundled with with Perl, to get a feel for how
> professional hobbyists and/or paid programmers write.
Joe, i really appreciate this post, it's saved, and there's no good reason
why someone would want to use my blogger, it's simply, you know, there, in
case you wanted to try it :-) I will re-read this a few times, it's good
moral support.
-Robin
------------------------------
Date: 3 May 2004 07:55:55 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: need help with security
Message-Id: <c74tub$sou$1@mamenchi.zrz.TU-Berlin.DE>
Robin <robin @ infusedlight.net> wrote in comp.lang.perl.misc:
> sorry to post a script that wouldn't compile, I actually posted the one in
> progress without checking if it would work,that was completely my mistake.
Yes, it is, and you're making too many of them. Dumping one sloppy
post after the other to the group is just rude. Stop it!
Anno
------------------------------
Date: Mon, 03 May 2004 08:57:23 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: need help with security
Message-Id: <TPnlc.20608$kh4.1222425@attbi_s52>
Robin wrote:
> well, I tend to use as few modules as possible so that someone can install
> the script on their server without having to download a lot of modules.
With that design, your script will not have much in terms of functionality.
The end result will be more of a toy than a production-quality program.
It probably doesn't matter much; I doubt that more than a handful of
people will ever be using it.
-Joe
------------------------------
Date: Mon, 3 May 2004 06:23:48 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Perl Embedding Question
Message-Id: <c74ohk$8dn$1@wisteria.csv.warwick.ac.uk>
Quoth "Steve Titus" <titus@nospam.com>:
> PROBLEM: the problem is that I just let ExtUtils::Embed spew out all the
> compile and link flags that I used for building, and when I run the
> executable on another machine,
Bad plan. In general, and especially when dealing with perl, you should
build an executable on the machine it is going to run on, using the
appropriate ExtUtils::Embed output on that machine. This does apply much
more generally than just embedding perl: I'm surprised you've not been
bitten by this before. The one exception is binary distros, which work
very hard to make machines clones of each other, at least insofar as
library locations/version/etc are concerned. If you want to go down that
route, you would definitely be best off making a rpm or whatever, and
finding out how to properly interface with the package management
system; this will be a big job, though.
> it barfs with different messages about
> shared libararies (depending on machine on which it is run), with 2
> representative error messages being:
>
> cperltest: error while loading shared libraries: libperl.so: cannot open
> shared object file: No such file or directory
libperl.so is essential... this means that *either* this machine hasn't
got one (it is possible, and common, to build perl without libperl.so:
everything that would have been in the lib is linked directly into
/usr/bin/perl) in which case you'll either have to rebuild perl with one
or you'll need the appropriate perl build tree for that machine, so it
can be statically linked; *or* that it is somewhere other than where the
program is looking for it (programs (can) have a search path for runtime
libraries built into them in addition to those in /etc/ld.so.conf).
> cperltest: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required
> by cperltest)
This is basically an insurmountable problem: the binary you have is
simply not compatible with that version of glibc.
> QUESTIONS:
>
> I have a basic understanding of what shared libraries are and how they
> work, but I am not knowledgable about GLIBC compatibilities, or about
> the "best" way to attain the following goal: I want someone to be able
> to write a C/C++ program that links against my Cperl library, and as far
> as they are concerned, it will just work.
>
> 1. Is this possible?
Yes. Your lib (.a or .so, it doesn't matter) will have to be either
compatible with the installed libperl.so, or statically linked to its
own copy of libperl.a.
> 2. Could someone please give me a short primer on the way that GCC build
> env, user environment (e.g. LD_LIBRARY_PATH), and Perl environment (how
> Perl was built, etc), all influence what the "right" answer is to
> solving this problem? All these issues have me confused!
If your perl is statically linked (no libperl.so) then so will your
libcperl.so need to be. This is wasteful (the libperl.so code is
duplicated), but can be easier. OTOH, there may then be issues with
@INC, depending on the differences between the installed perl and the
one built into you lib. You may be able to deal with these by giving
your library (or your program) its own set of perl modules, and setting
@INC inside your program.
Basically, it all depends on how perl was built: your library and any
programs that use it all have to be built in the same way as the copy of
perl your library uses (which may well not be the same as /usr/bin/perl
on that machine).
> 3. What approach should I take? The ground rules are that all the boxes
> I am working with will all have basically same O/S -- all Red Hat boxes
> that look pretty much like
>
> Linux 2.4.20-19.7smp #1 SMP Tue Jul 15 13:34:04 EDT 2003 i686 unknown
>
> but they may have slightly different Perl versions installed in slightly
> different places. SHould I compile everything statically so that my
> cperl.a essentially contains a stand-alone Perl? How would I go about
> doing this if it's possible?
>
> 4. How do you figure out what shared libraries an executable depends on?
Use ldd: you can do the same for shared libraries. This will tell you
which libs it needs and where the runtime linker will actually resolve
them to (if it can). You can use readelf -d to find out if an executable
specifies its own path for resolving shared libraries (entries of type
RPATH).
> 5. How do you statically compile an executable (gcc version 3.2.3) so
> that it depends on NOTHING?
-static. In your case, you would first need to build a static perl (pass
the appropriate option to Configure). Then build your library against
that copy of perl, and it will statically link in libperl.a.
> 6. Should I even try to compile statically, or can I somehow keep things
> the way they are, and just have everyone add a few things to their
> LD_LIBRARY_PATH on my behalf? Any philosophical and pratical help would
> be great...
I would be inclined not to compile things statically where you can avoid
it. By far the best answer, as I said, is to build the thing on the
machine it will run on. Otherwise you might try building a libcperl.so
with a statically linked perl; but you will still have problems with
differing libc versions.
---
Have you considered turning your problem inside-out, and writing the
main program in Perl, with XS or Inline modules written in C or C++
where you need to? You may have more luck that way.
Ben
--
Razors pain you / Rivers are damp
Acids stain you / And drugs cause cramp. [Dorothy Parker]
Guns aren't lawful / Nooses give
Gas smells awful / You might as well live. ben@morrow.me.uk
------------------------------
Date: Mon, 03 May 2004 10:07:48 +0200
From: Florence HENRY <raslebol@duspam.fr>
Subject: Re: Problem with global variables
Message-Id: <c74uk7$cqg$1@carbone.net.espci.fr>
Le vendredi 30 Avril 2004 21:37, Gunnar Hjalmarsson a déclaré:
> I didn't quite understand why you can't import those names to the
> modules where they need to be used, but an alternative way to access
> them is to use the fully qualified names, i.e.
> @pdsdb_var::columns_char and @pdsdb_var::columns_num.
Thanks ! that's exactly what I was looking for.
--
Florence Henry
florence point henry arobasse obspm point fr
------------------------------
Date: 2 May 2004 21:29:28 -0700
From: dbsx@yahoo.com (Don Stock)
Subject: Re: single-byte values
Message-Id: <8cf7ae36.0405022029.2ec963bd@posting.google.com>
> Well, this has very few to do with your post, but you *may* still be
> interested: just a few days ago I wanted to test a few CDRWs I have
> because they had given me a few errors, so I created a test directory
> with 699 1Mb random binary files[*] that I subsequently verified with
> the following script:
>
> #!/usr/bin/perl -l
>
> use strict;
> use warnings;
> use constant LEN => 0x100_000;
>
> die "Usage: $0 dir1 dir2\n" unless @ARGV==2;
> s|/$||,-d or
> die "`$_': doesn't exist or is not a directory\n"
> for @ARGV;
>
> undef $/;
> for ('001'..'699') {
> warn "Comparing $ARGV[0]/$_ and $ARGV[1]/$_\n";
> open my $fh1, '<:raw', "$ARGV[0]/$_" or die $!;
> open my $fh2, '<:raw', "$ARGV[1]/$_" or die $!;
> my $err=LEN - (my $tmp=<$fh1>^<$fh2>) =~ tr/\0//d;
> print "$_: $err errors" if $err;
> }
> __END__
I must say, the "<$fh1>^<$fh2>" totally threw me for a minute. But
now I'm hip. In fact, I was inspired to write my own slurping compare
that ignores bytes at certain offsets, and here it is:
use strict;
use warnings;
die "usage: need 2 files\n" unless $#ARGV==1;
open my $f1,"$ARGV[0]" or die "can't open ",$ARGV[0]; binmode $f1;
open my $f2,"$ARGV[1]" or die "can't open ",$ARGV[1]; binmode $f2;
undef $/;
my $x=<$f1>;
my $y=<$f2>;
my @ignore=(4,5,6,7,22,23,24,25);
for (@ignore) {substr($x,$_,1)=0}
for (@ignore) {substr($y,$_,1)=0}
if ($x eq $y) {printf "match\n"} else {printf "*** mismatch\n"}
substr insists on putting in an ascii '0' instead of a binary 0. To
get a binary 0 in there (not that it mattered) I had to do this:
for (@ignore) {$x =~ s/^(.{$_})./$1\x00/}
incidentally, here's a post from someone who has found "The absolute
fastest way to open and read a file into a string" using sysread:
http://groups.google.com/groups?q=read+byte+group:comp.lang.perl.*&start=20&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.lang.perl.*&selm=38E3C42F.23F470EB%40bms.com&rnum=22
I note that File::Compare:compare() does a yes/no diff of two binary
files (using the same tortured strcmp convention that 0 means yes).
don
------------------------------
Date: Mon, 3 May 2004 08:29:49 +0200
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: single-byte values
Message-Id: <c74ot2$i4edt$1@ID-231055.news.uni-berlin.de>
Also sprach Don Stock:
>> Well, this has very few to do with your post, but you *may* still be
>> interested: just a few days ago I wanted to test a few CDRWs I have
>> because they had given me a few errors, so I created a test directory
>> with 699 1Mb random binary files[*] that I subsequently verified with
>> the following script:
>>
>> #!/usr/bin/perl -l
>>
>> use strict;
>> use warnings;
>> use constant LEN => 0x100_000;
>>
>> die "Usage: $0 dir1 dir2\n" unless @ARGV==2;
>> s|/$||,-d or
>> die "`$_': doesn't exist or is not a directory\n"
>> for @ARGV;
>>
>> undef $/;
>> for ('001'..'699') {
>> warn "Comparing $ARGV[0]/$_ and $ARGV[1]/$_\n";
>> open my $fh1, '<:raw', "$ARGV[0]/$_" or die $!;
>> open my $fh2, '<:raw', "$ARGV[1]/$_" or die $!;
>> my $err=LEN - (my $tmp=<$fh1>^<$fh2>) =~ tr/\0//d;
>> print "$_: $err errors" if $err;
>> }
>> __END__
>
> I must say, the "<$fh1>^<$fh2>" totally threw me for a minute. But
> now I'm hip. In fact, I was inspired to write my own slurping compare
> that ignores bytes at certain offsets, and here it is:
>
> use strict;
> use warnings;
>
> die "usage: need 2 files\n" unless $#ARGV==1;
> open my $f1,"$ARGV[0]" or die "can't open ",$ARGV[0]; binmode $f1;
> open my $f2,"$ARGV[1]" or die "can't open ",$ARGV[1]; binmode $f2;
> undef $/;
> my $x=<$f1>;
> my $y=<$f2>;
> my @ignore=(4,5,6,7,22,23,24,25);
> for (@ignore) {substr($x,$_,1)=0}
> for (@ignore) {substr($y,$_,1)=0}
> if ($x eq $y) {printf "match\n"} else {printf "*** mismatch\n"}
>
> substr insists on putting in an ascii '0' instead of a binary 0. To
> get a binary 0 in there (not that it mattered) I had to do this:
>
> for (@ignore) {$x =~ s/^(.{$_})./$1\x00/}
Well, as you already noticed yourself, Perl is not C. If you want the
NULL character, then do
substr($x, $_, 1, "\0"), substr($y, $_, 1, "\0") for @ignore;
The trailing substitution after inserting a '0' is a red herring.
Also, I would probably use an appropriate unpack() pattern to handle the
bytes to be ignored. But that's mainly because I like unpack() a lot. It
can be generated dynamically [untested though]:
push @ignore, 0; # so that $ignore[-1] == 0
my $tmpl;
$tmpl .= "a" x ($ignore[$_] - $ignore[$_-1] - 1) . "x" for 0 .. $#ignore - 1;
$tmpl .= "a*";
# squeeze it for stylistic reasons
$tmpl =~ s/((.)\2+)/$2 . length($1)/ge;
undef $/;
my $x = join '', unpack $tmpl, <$f1>;
my $y = join '', unpack $tmpl, <$f2>;
print "match\n", exit if $x eq $y;
print "*** mismatch\n";
For the given @ignore, the unpack() template would be
aaaxxxxaaaaaaaaaaaaaaxxxxa*
which is
a3x4a14x4a*
after condensing it (not sure whether perl's pack/unpack engine can
handle those templates any quicker).
Finally, only use printf() when you actually make use of its
interpolation features. Again, Perl is not C.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 3 May 2004 02:35:54 -0700
From: uffesterner@spamhole.com (Rex Gustavus Adolphus)
Subject: What happend to www.perldoc.com??
Message-Id: <c70a85ff.0405030135.7a6504d5@posting.google.com>
Anyone knows what happend to the www.perldoc.com site since friday???
I get redirected to https://www.perldoc.com:19638/webhost/rollout/site
and has to install a certificate from dedicated.quantumfx.com,
and then all I get is a "Welcome User Administrator" loginform??
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 6508
***************************************
