[24029] in Perl-Users-Digest
Perl-Users Digest, Issue: 6226 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 6 11:05:40 2004
Date: Sat, 6 Mar 2004 08:05:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 6 Mar 2004 Volume: 10 Number: 6226
Today's topics:
Re: HOW TO CHECK URL?? <luke@program.com.tw>
Re: Operation not permitted <jwillmore@remove.adelphia.net>
Re: Perl program and database locked but alive <jwillmore@remove.adelphia.net>
Re: Replacing 1500 bytes at a variable offset (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 6 Mar 2004 23:14:19 +0800
From: "news.hinet.net" <luke@program.com.tw>
Subject: Re: HOW TO CHECK URL??
Message-Id: <c2cpp0$4ro@netnews.hinet.net>
i just want to using regular express to check url
"news.hinet.net" <luke@program.com.tw> ¦b¶l¥ó
news:c2cjuq$eeh@netnews.hinet.net ¤¤¼¶¼g...
> HTTP://123.22.1.33 TRUE
> HTTP://123.22.1.333 FAIL
> http://123.22.1 fail
>
> ftp://abc.efg.net true
> ftp://abc.efg.nnn fail
> http://abc.efg*.net fail
>
>
>
------------------------------
Date: Sat, 06 Mar 2004 09:39:46 -0500
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: Operation not permitted
Message-Id: <pan.2004.03.06.14.39.44.341320@remove.adelphia.net>
On Fri, 05 Mar 2004 11:49:33 -0800, Sam wrote:
> Thanks for all the input. A friend of mine took a look at the perl
> script and thought it might be a permissions problem, and sure enough,
> when I set the permissions higher, I no longer received the error
> message. For anyone who finds this while looking for the same
> solution, here's the relevant code change:
>
> die "Unable to chmod file in spooling area\n" .
> "chmod (0700, \"$TEMP/$temp2\"): $!"
> unless (chmod (0700, "$TEMP/$temp2"));
It's not wise to change permissions on a file when the file name is
derived from a variable. You have to make sure that the script isn't
changing permissions on a file it shouldn't. If you do want to do
something like this, you should run the script with taint mode enabled and
do some checking on the variables *before* executing a command or changing
permissions on a file. `perldoc perlsec` for more information.
> Change those two 0700's to something higher...if you're a lazy slacker
> like me, 777 will work. That piece of code sets the permissions on the
> data file, and if it is too strict then your html interface won't be
> able to submit them to hylafax.
You need to learn about permissions. Setting a file to 0777 is not wise
if the file is owned by root or runs setuid. 0755 is more than adequate
for, say, a Perl script.
> (The default location for this file is /usr/local/smbfax/smbfax, and it
> is a perl script.)
>
> Again, thanks to those who've given me their consideration, and forgive
> me if I've posted slightly off-topic for this group.
It's not uncommon for someone to use the builtin functions of Perl to do
things like deleting files or changing permissions. However, you need to
do so wisely and understand what you're doing. So, some understanding of
the OS and filesystem you're using is a requirement.
IMHO, this is one of those gray areas that should be addressed in part
here and in part in another newsgroup related to what you're doing. Taint
checking and specifics about the functions you're using are addressed here;
the OS and filesystem are better addressed in another newsgroup.
Good luck and HTH
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
Those of you who think you know everything are very annoying to
those of us who do.
------------------------------
Date: Sat, 06 Mar 2004 09:49:03 -0500
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: Perl program and database locked but alive
Message-Id: <pan.2004.03.06.14.49.01.913412@remove.adelphia.net>
On Fri, 05 Mar 2004 19:05:15 -0800, TF wrote:
> Is there any way to intervene with a program that is still running, but
> locked during database read/write subs, to see where the lockup is coming
> from?
> This problem cannot be repeated and is the result of web page data
> corruption, or storage of said data.
I'm thinking you're using the DBI module, but can't be sure ... because
you have posted no code related to your issue :-)
If you're using the DBI module and think that it's having trouble with the
database it's connecting to, use the 'trace' function to get more
information - `perldoc DBI` for more information.
Another way to do CGI script debugging is to run the script at the command
line to see what happens (again ... no code, no more specific help :-) ).
HTH
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
Common sense is the collection of prejudices acquired by age
eighteen. -- Albert Einstein
------------------------------
Date: 6 Mar 2004 14:32:15 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Replacing 1500 bytes at a variable offset
Message-Id: <c2cndf$9l4$1@mamenchi.zrz.TU-Berlin.DE>
John W. Krahn <krahnj@acm.org> wrote in comp.lang.perl.misc:
> "A. Farber" wrote:
> >
> > How could I replace 1500 bytes in a file, please?
> > They are not located at some fixed offset and also
> > the amount of replacing bytes could be bigger or
> > smaller than 1500. Here's what I am trying currently:
> >
> > my $SEARCH = pack 'C*', map { hex } qw(
> > 98 e6 52 ca db ce db 19 62 00 00 00
> > 69 b5 40 0c 91 dc 6b 43 cf 00 00 00
> > 5b 7d 92 c2 e1 ec f1 45 11 00 00 00
> > 92 45 a3 64 0b ff e4 d9 a6 00 00 00
> > 2e 0d cb 22 50 0e 92 5a 0f 00 00 00
> > 4e d5 78 59 ee 1c 8b c6 cc 00 00 00
> > .... );
> >
> > my $REPLACE = pack 'C*', map { hex } qw(
> > ff ff ff ff ff ff ff ff ff ff ff ff
> > 69 b5 40 0c 91 dc 6b 43 cf 00 00 00
> > 5b 7d 92 c2 e1 ec f1 45 11 00 00 00
> > 92 45 a3 64 0b ff e4 d9 a6 00 00 00
> > 2e 0d cb 22 50 0e 92 5a 0f 00 00 00
> > .... );
> >
> > use constant KEYSIZE => length $SEARCH;
To the OP:
Uh... Did you test this part? "use constant" happens at compile time,
the assignment to $SEARCH happens later at run time. That would make
KEYSIZE 0 and issue a warning.
Make SEARCH and REPLACE constants too, that would also justify the
caps.
> > while (sysread $upload, $chunk, KEYSIZE) {
> > $both = $prev . $chunk;
> > if ($both =~ s/$SEARCH/$REPLACE/o) {
> > die "syswrite failed: $!"
> > unless length $both == syswrite $fh, $both;
> > undef $prev;
> > } else {
> > die "syswrite failed: $!"
> > unless length $prev == syswrite $fh, $prev;
> > $prev = $chunk;
> > }
> > }
> > # don't forget to print the last line
> > die "syswrite failed: $!"
> > unless length $prev == syswrite $fh, $prev;
> >
> > Unfortunately the regex doesn't compile, probably
> > because it doesn't like the binary data I feed to it!
>
> It is not that the data is binary, it is because some of the characters
> are special to regular expressions. Use the quotemeta escape to fix it.
>
> s/\Q$SEARCH/$REPLACE/o
That should do it, but with a fixed binary string that size I'd prefer
an index/substr based solution over s///. Something like (untested)
$_ >= 0 and substr( $both, $_, KEYSIZE) = REPLACE for index $both, SEARCH;
Anno
------------------------------
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 6226
***************************************
