[16733] in Perl-Users-Digest
Perl-Users Digest, Issue: 4145 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 27 18:06:14 2000
Date: Sun, 27 Aug 2000 15:05:13 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <967413912-v9-i4145@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Sun, 27 Aug 2000 Volume: 9 Number: 4145
Today's topics:
Re: @_ as array (brian d foy)
Can't get rid of perl warnings.. <marius@kjeldahl.net>
Re: Can't get rid of perl warnings.. (Daniel Chetlin)
Re: clearing a file <mikecook@cigarpool.com>
Re: Closures? (brian d foy)
Re: Combining Strings <jpalley@jps.net>
Re: Counting across multiple lines? <elephant@squirrelgroup.com>
Re: Counting across multiple lines? (Keith Calvert Ivey)
Re: Global symbol "$dbh" requires explicit package name <jeff@vpservices.com>
Re: Global symbol "$dbh" requires explicit package name <elephant@squirrelgroup.com>
Re: Global symbol "$dbh" requires explicit package name <jeff@vpservices.com>
Re: Global symbol "$dbh" requires explicit package name <jeff@vpservices.com>
Re: guestbook & file-upload under NT <ddorward@hotmail.com>
Re: How can I find an images size?? (Clay Irving)
Re: How can I find an images size?? <bart.lateur@skynet.be>
How to Unzip a .tar.gz file (BUCK NAKED1)
Re: Internet Protocol was(Re: stupid question probably) (Hasanuddin Tamir)
Re: Just another silly post. (brian d foy)
Re: Kill Me! (Hasanuddin Tamir)
Re: Kill Me! (brian d foy)
Managing Temporary Directories/Files <brock_johnson@my-deja.com>
Re: Managing Temporary Directories/Files <timewarp@shentel.net>
Re: Managing Temporary Directories/Files (brian d foy)
Re: No Server Logs <godzilla@stomp.stomp.tokyo>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 27 Aug 2000 16:53:10 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: @_ as array
Message-Id: <brian-ya02408000R2708001653100001@news.panix.com>
In article <m11yzdtlsj.fsf@halfdome.holdit.com>, merlyn@stonehenge.com (Randal L. Schwartz) posted:
> I'm always puzzled by people that think there's no rhyme or reason to
> this stuff. Context is completely deterministic, and doesn't take a
> rocket scientist. Just ask... "is it looking for a list or a scalar
> here" and if you got the wrong one, throw in the scalar or the
> (...)[0] tricks. And don't over use those. I see this all the time:
>
> $n = scalar @a;
>
> Bleh! That's a bit like strapping training wheels onto your training
> wheels.
it's sometimes nice to say "yes, i mean to do that", though :)
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: Sun, 27 Aug 2000 21:54:58 +0200
From: Marius Kjeldahl <marius@kjeldahl.net>
Subject: Can't get rid of perl warnings..
Message-Id: <39A97211.BAB869C5@kjeldahl.net>
I've isolated it to the following testcase:
root@faze /root]# perl -e 'use warnings; { no warnings; eval "123ad3";
}'
Bareword found where operator expected at (eval 1) line 1, near "123ad3"
(Missing operator before ad3?)
Any ideas on how to get rid of that warning, and warnings in general?
I've done man warnings and man perllexwarn but I am none the wiser.
Marius
------------------------------
Date: Sun, 27 Aug 2000 20:23:18 GMT
From: daniel@chetlin.com (Daniel Chetlin)
Subject: Re: Can't get rid of perl warnings..
Message-Id: <WMeq5.13447$C7.460838@news-west.usenetserver.com>
On Sun, 27 Aug 2000 21:54:58 +0200, Marius Kjeldahl <marius@kjeldahl.net> wrote:
>I've isolated it to the following testcase:
>
>root@faze /root]# perl -e 'use warnings; { no warnings; eval "123ad3";}'
>Bareword found where operator expected at (eval 1) line 1, near "123ad3"
> (Missing operator before ad3?)
>
>Any ideas on how to get rid of that warning, and warnings in general?
>I've done man warnings and man perllexwarn but I am none the wiser.
perldoc perldiag is your best bet. In particular:
=item %s found where operator expected
(S) The Perl lexer knows whether to expect a term or an operator. If it
sees what it knows to be a term when it was expecting to see an
operator, it gives you this warning. Usually it indicates that an
operator or delimiter was omitted, such as a semicolon.
If that warning (it's a severe warning, as indicated by the 'S') were
controllable by the warnings pragma, it'd specify what subpragma to turn
on/off to control it. For example:
=item Operator or semicolon missing before %s
(S ambiguous) You used a variable or subroutine call where the parser
was expecting an operator. The parser has assumed you really meant to
use an operator, but this is highly likely to be incorrect. For
example, if you say "*foo *foo" it will be interpreted as if you said
"*foo * 'foo'".
In this case, you could turn off that severe warning with
C<no warnings 'ambiguous'>. But since there's no subpragma listed for your
particular warning, it ain't going away.
If you've really gotta get rid of it, set $SIG{__WARN__}. Either to a blank
sub, if you don't want to see any warnings, or so something that checks the
warning if you only want to catch that one.
-dlc
------------------------------
Date: Sun, 27 Aug 2000 12:27:27 -0700
From: "Michael Cook" <mikecook@cigarpool.com>
Subject: Re: clearing a file
Message-Id: <LYdq5.571$NR6.193270@news.uswest.net>
Thanks for all the help!!!
Michael
"Craig Berry" <cberry@cinenet.net> wrote in message
news:sqiij4tct91183@corp.supernews.com...
> Michael Cook (mikecook@cigarpool.com) wrote:
> : open (TEMP, ">db/members.tmp") || die("Unable to open
db/members.tmp");
> : flock(TEMP, $LOCK_EX);
> : print TEMP $null;
> : flock(TEMP, $LOCK_UN);
> : close (TEMP);
> :
> : to clear a file - is there a better way (I would like results similar to
> : using cat /dev/null > file) at the command line?
>
> First, you should almost never explicitly unlock a file. close() does
> that automatically, and handles synchronization issues like flushing
> better.
>
> As for zero-lengthing the file, just opening it for write and then closing
> it should do the trick. No need to actually write something (well,
> nothing) to the file.
>
> --
> | Craig Berry - http://www.cinenet.net/~cberry/
> --*-- "Every force evolves a form."
> | - Shriekback
------------------------------
Date: Sun, 27 Aug 2000 17:36:59 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: Closures?
Message-Id: <brian-ya02408000R2708001736590001@news.panix.com>
In article <39A68A1D.F1EC4738@shentel.net>, Albert Dewey <timewarp@shentel.net> posted:
> foreach $perl(@knit)
why use foreach when you do nothing with the array
elements?
and, since you never use the array elements, why
clutter up the program with another variable?
> {
> if(knit_1)
> {
> perl_2;
> }
> }
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: Sun, 27 Aug 2000 11:16:10 -0700
From: Jonathan Palley <jpalley@jps.net>
Subject: Re: Combining Strings
Message-Id: <39A95AEA.DE21D0A2@jps.net>
That's why i said correct me if i'm wrong! ;)
THANX, thought there were other ways
JP
Gwyn Judd wrote:
> I was shocked! How could Jonathan Palley <jpalley@jps.net>
> say such a terrible thing:
> >Just as I speak, i figure it out.......you use a . (dot)
> >$S1 = $S2 . $S3;
> >
> >someone correct me if i'm wrong!
>
> That is one way, however, as in all things Perl, There Is More Than One
> Way To Do It :)
>
> 1)
>
> $s1 = "$s2$s3";
>
> 2)
>
> $s1 = join '', $s2, $s3;
>
> 3)
>
> $s1 = sprintf "%s%s", $s2, $s3;
>
> 4)
>
> $s1 = <<END_OF_STRING;
> $s2$s3
> END_OF_STRING
>
> chomp $s1;
>
> Which method you choose to use will depend on your situation.
>
> --
> Gwyn Judd (print `echo 'tjla@guvfybir.qlaqaf.bet' | rot13`)
> Fortune's real live weird band names #670:
>
> Stiff Richards
------------------------------
Date: Sun, 27 Aug 2000 18:49:28 GMT
From: jason <elephant@squirrelgroup.com>
Subject: Re: Counting across multiple lines?
Message-Id: <MPG.14140029b8b95be598970b@localhost>
Mike Stok <mike@stok.co.uk> wrote ..
>In article <MPG.1413d62be205292698970a@localhost>,
>jason <elephant@squirrelgroup.com> wrote:
>>Mike Stok <mike@stok.co.uk> wrote ..
>
>[...]
>
>>>If you count the newline at the end of the lines as a character and you
>>>are using an operating system which represents the newline with a single
>>>character then you might be able to use the -s file test operator to get
>>>the size of the file without having to read it at all.
>>
>>this would be a good solution *IF* you've got a known fixed number of
>>chars per line in the file - otherwise you're going to have to open it
>>to find out how many lines it has - so you know how many line-endings
>>there are
>
>Yes, this code fragment was tossed out with the condition "If you count
>the newline at the end of the lines as a character..." There wasn't
>enough information in the question to provide any complete and reliable
>solution, so I just tossed out a few ideas which might help the original
>poster get on track.
I understand .. I just think that if a provided answer has a caveat as
big as "as long as the lines are all a known fixed length" then it's
worth stating it explicitly
>>>If you don't want the newlines counted then you might be able to do
>>>something like:
>>>
>>> # assume FH is opened for reading
>>>
>>> $length = 0;
>>>
>>> while (<FH>) {
>>> chomp;
>>> $length += length;
>>> }
>>>
>>>If you want to get the whole file into memory then you might say something
>>>like:
>>>
>>> # assume FH is opened for reading
>>>
>>> {
>>> local $/;
>>> $data = <FH>;
>>> }
>>>
>>> $data =~ tr/\n//d;
>>>
>>> $length = length( $data );
>>
>>neither of the above would work if - as the originator seemed to suggest
>>- there was a header (or some other non-protein-sequence data) within
>>that file
>
>The comments above the code fragments both state the assumption that the
>file is opened for reading. In neither case did I say "and you mustn't
>have read anything from it yet - maybe the original poster has enough
>imagination to see that he might be able to read the header and then use
>the ideas in the presented fragments to deal with the rest of the
>file. I didn't think that the jump from the presented fragments to some
>useful code would be that hard.
judging by the problem that the originator was having which seemed to
indicate a lack of understanding of the diamond operator and how line
mode reading works .. I just thought that your suggestions needed more
detail (before the originator went off and actually tried any of them)
in any case .. while you might not have said "you mustn't have read
anything from it yet" you did say "get the whole file into memory" which
would certainly suggest that you overlooked the header complication
>I lurk somewhere between the "teach a man to fish" and "give him a
>fish" camps ... I usually endeavour to leave enough clues that someone can
>get to a working solution in a reasonable time, but not without thinking
>about the suggestions. Sometimes just tossing ous some of the other ways
>to do it in perl can help people see the problem in a differnt light.
I agree .. it was mainly the first answer which required but made no
mention of the known fixed line lengths that set off the alarm bells ..
because .. especially if (for instance) most lines are of similar length
.. but the last is shorter .. or there are some that are shorter .. a
close - but never accurate - answer can be difficult to debug for a self
confessed Perl and programming novice
>In general I believe that people are smart and imaginative, but I'm always
>grateful to have reconsider my views. I realise that old-timers in a
>group like this have a duty to keep neophyte posters like me in line,
>especially if I don't fully qualify and disclaim everything in my post.
"smart and imaginative" .. are we reading the same newsgroup ?
my post was done purely to state some assumptions that were missing from
yours that I think might not occur to someone new to Perl and to
programming
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: Sun, 27 Aug 2000 19:32:01 GMT
From: kcivey@cpcug.org (Keith Calvert Ivey)
Subject: Re: Counting across multiple lines?
Message-Id: <39a96c20.1666064@news.newsguy.com>
jason <elephant@squirrelgroup.com> wrote:
>Sudhan <someone@somewhere.com> provided the reason not to killfile all
>jeopardists by writing the appauling example code ..
>>"Pedro A Navarro" <pnavarro@uswest.net> wrote
>>> $count=tr/A-Z//;
>>> print "$count\n";
>>>
>>> I get the number of characters for each line, instead of for the whole
>>> thing. I have tried to get rid of the newline character with
>
>as Tina's second shot mentioned - this will work perfectly as long as
>you have all the file in $count when you do the tr .. which you almost
>certainly do not
You meant $_ there, not $count, of course.
--
Keith C. Ivey <kcivey@cpcug.org>
Washington, DC
------------------------------
Date: Sun, 27 Aug 2000 12:35:36 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: Global symbol "$dbh" requires explicit package name at d:\...\Behzad.pl line 17.
Message-Id: <39A96D88.6A9EA3DB@vpservices.com>
jason wrote:
>
> Jeff Zucker <jeff@vpservices.com> wrote ..
> >>
> >> jason wrote:
> >> >
> >> > change the above to
> >>
> >> > my $dbh; # separate declaration
> >>
> >> > $dbh = DBI->connect($data_source, $username, $password)
> >> > or die "cant connect to $data_source : $dbh->errstr\n";
> >>
> >
> >Well, personally, I don't think putting the declaration separate does
> >anything.
>
> thanks for your opinion .. perl - however - agrees with me .. of course
> - if you were testing without the $dbh in the die clause then you would
> not have seen the error
Yes, perl agrees with you if one uses $dbh->errstr and you're entirely
correct that it needs to be separate in that case. My posting was
ambiguous about that, thanks for clarifying. But, OTOH, perl agrees
with me if you use $DBI->errstr and this is still the one I'd recommend:
my $dbh = DBI->connect($data_source,$user,$pswd,{RaiseError=>1})
or die $DBI::errstr;
--
Jeff
------------------------------
Date: Sun, 27 Aug 2000 19:00:29 GMT
From: jason <elephant@squirrelgroup.com>
Subject: Re: Global symbol "$dbh" requires explicit package name at d:\...\Behzad.pl line 17.
Message-Id: <MPG.141402c4474ce80598970c@localhost>
Jeff Zucker <jeff@vpservices.com> wrote ..
>Tina Mueller wrote:
>>
>> hi,
>> jason <elephant@squirrelgroup.com> wrote:
>> > bjg <bGhassemlou@home.com> wrote ..
>> >>I am trying to write a small program to use DBI and I get "Global symbol
>> >>require...." error
>>
>> >>my $dbh = DBI->connect($data_source, $username, $password) or die "cant
>> >>connect to $data_source : $dbh->errstr\n";
>>
>> > see how you use $dbh within the die call ? .. well what if the
>> > DBI::connect DOES fail .. then $dbh will not have been declared .. so
>> > strict will complain (and it will complain a number of other times as
>> > well)
>>
>> > change the above to
>>
>> > my $dbh; # separate declaration
>>
>> > $dbh = DBI->connect($data_source, $username, $password)
>> > or die "cant connect to $data_source : $dbh->errstr\n";
>>
>> another thing: $dbh->errstr won't be interpolated
>> as you might expect.
>
>
>Well, personally, I don't think putting the declaration separate does
>anything.
thanks for your opinion .. perl - however - agrees with me .. of course
- if you were testing without the $dbh in the die clause then you would
not have seen the error
> And Tina is right that the object won't get interpolated
>correctly in the string.
I just want to clear this up .. Tina snipped the following lines from my
response
jason> THEN have another look at the DBI documentation .. the above die
jason> message will almost certainly not be what you expect
which I would still recommend to the originator .. go to the
documentation - it shows clear examples of how to connect and capture
errors on connection failures
> But I would recommend using $DBI::errstr
>instead of $dbh->errstr on the connect. And really, you should set
>RaiseError so you'll know about other problems later:
all well covered in the cited documentation
--
jason -- elephant@squirrelgroup.com --
------------------------------
Date: Sun, 27 Aug 2000 11:08:35 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: Global symbol "$dbh" requires explicit package name at d:\...\Behzad.pl line 17.
Message-Id: <39A95923.B72B5BD0@vpservices.com>
Tina Mueller wrote:
>
> hi,
> jason <elephant@squirrelgroup.com> wrote:
> > bjg <bGhassemlou@home.com> wrote ..
> >>I am trying to write a small program to use DBI and I get "Global symbol
> >>require...." error
>
> >>my $dbh = DBI->connect($data_source, $username, $password) or die "cant
> >>connect to $data_source : $dbh->errstr\n";
>
> > see how you use $dbh within the die call ? .. well what if the
> > DBI::connect DOES fail .. then $dbh will not have been declared .. so
> > strict will complain (and it will complain a number of other times as
> > well)
>
> > change the above to
>
> > my $dbh; # separate declaration
>
> > $dbh = DBI->connect($data_source, $username, $password)
> > or die "cant connect to $data_source : $dbh->errstr\n";
>
> another thing: $dbh->errstr won't be interpolated
> as you might expect.
Well, personally, I don't think putting the declaration separate does
anything. And Tina is right that the object won't get interpolated
correctly in the string. But I would recommend using $DBI::errstr
instead of $dbh->errstr on the connect. And really, you should set
RaiseError so you'll know about other problems later:
my $dbh = DBI->connect($data_source,$user,$pswd,{RaiseError=>1})
or die $DBI->errstr;
But of course, as we all know, the real root of the problem is in your
subject line: if you are having problems on line 17 you might as well
give up. Unless you can afford to hire Abigail, it's totally impossible
for mere mortals to deal with problems on line 17. (sorry, in-joke)
--
Jeff
------------------------------
Date: Sun, 27 Aug 2000 11:11:43 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: Global symbol "$dbh" requires explicit package name at d:\...\Behzad.pl line 17.
Message-Id: <39A959DF.A038E075@vpservices.com>
bjg wrote:
>
> my $data_source = "DBI:mySQL:$database";
Oops, just noticed another problem and this one is no joke: the
capitalization is wrong. You must use the same capitalization as the
DBD module which in this case is all lower case.
my $data_source = "dbi:mysql:$database";
You can get away with uper-casing dbi though it isn't recommended, but
the "mysql" *must* be lower case. It doesn't matter what the database
itself uses (MySQL, I think), it's the DBD that counts in this case and
the DBD is definitely DBD::mysql.pm.
--
Jeff
------------------------------
Date: Sun, 27 Aug 2000 21:59:55 +0100
From: David Dorward <ddorward@hotmail.com>
To: Dark <darklord@libero.it>
Subject: Re: guestbook & file-upload under NT
Message-Id: <39A9814B.7695A15@hotmail.com>
Dark wrote:
>
> Can anyone tell me where to find a script for file-uploading and a script
> for a guestbook, both working under a win NT server?
> Thanks!
http://www.cgi-resources.com
--
David Dorward
http://www.dorward.co.uk/
------------------------------
Date: 27 Aug 2000 18:18:34 GMT
From: clay@panix.com (Clay Irving)
Subject: Re: How can I find an images size??
Message-Id: <slrn8qimrq.60u.clay@panix3.panix.com>
On Sun, 27 Aug 2000 14:56:01 +0100, Speed Demon <speed.demon9999@virgin.net>
wrote:
>Cheers m8, I tried Deja, only came up with useless junk...
>
>I can't open the tar.gz files as im on windows, can someone send the files
>in either a .zip or uncompressed format to me so I can upload to my UNIX
>host?
This function will also return the size of a GIF image:
sub sizegif {
my $filename = @_;
open GIF, "$filename" or die "Error $file: $!\n";
sysread(GIF, $header, 13) or die "sysread header: $!";
($gif, $width, $height) = unpack('a3x3vv', $header);
};
--
Clay Irving <clay@panix.com>
I got a new shadow. I had to get rid of the other one...it wasn't doing what I
was doing. - Steven Wright
------------------------------
Date: Sun, 27 Aug 2000 19:24:10 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: How can I find an images size??
Message-Id: <tfqiqskvhcocp0093ru700434l5tj3m98p@4ax.com>
Speed Demon wrote:
>So I feed the script the image and it out outs the dimensions, (eg 40 x 60)
>etc..
>
>Is this possible? Images are all .GIF files but I hope this shouldn't be a
>problem
Image::Size.
As you appear to be on Windows, get Image::Size from Activestate's site:
<http://www.activestate.com/PPMPackages/5.6/zips/Image-Size.zip>.
Replace "5.6" with "5.005" if you're using a slightly older Perl.
p.s. Winzip can open tar.gz. So can the standard (? -- It is on Win32)
module Archive::Tar.
--
Bart.
------------------------------
Date: Sun, 27 Aug 2000 13:53:57 -0500 (CDT)
From: dennis100@webtv.net (BUCK NAKED1)
Subject: How to Unzip a .tar.gz file
Message-Id: <9201-39A963C5-46@storefull-243.iap.bryant.webtv.net>
Can someone please help me out with a perl script(not command line
input) for unzipping a .tar.gz file from my Unix/Apache webserver. I've
tried
do gunzip xvf filename.tar.gz -tar
etc., and it gives an internal 500 error and won't run. I tried to use
the module Compress::Zlib which is installed on my server, but all the
error log says when using that module is that inflate() failed.
Thanks.
--Dennis
------------------------------
Date: Mon, 28 Aug 2000 09:27:06 GMT
From: hasant@trabas.co.id (Hasanuddin Tamir)
Subject: Re: Internet Protocol was(Re: stupid question probably)
Message-Id: <slrn8qiabs.vf.hasant@borg.intern.trabas.co.id>
On Sat, 26 Aug 2000 11:35:56 -0400, timewarp@shentel.net wrote:
[all snipped, I know your concern, partly at least :]
Well, it's up to you to choose your NR. But you could have
one that has a capability to skip quoted text, or even to
not display it at all, with a single stroke.
san
--
trabasLabs * hasant@trabas.com * http://www.trabas.com
Zero Point * hasant@zp.f2s.com * http://www.zp.f2s.com
------------------------------
Date: Sun, 27 Aug 2000 16:58:48 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: Just another silly post.
Message-Id: <brian-ya02408000R2708001658480001@news.panix.com>
In article <8o762q$grl$1@provolone.cs.utexas.edu>, logan@cs.utexas.edu (Logan Shaw) posted:
> In article <8o740r$ib8$1@news.doit.wisc.edu>,
> Steve Mading <madings@baladi.bmrb.wisc.edu> wrote:
> >Plus the grammer is not truly orthogonal:
>
> That's by design. I haven't personally asked him, but I have assumed
> that it was Larry Wall's contention that orthogonal grammars are
> unnatural.
see Larry's State of the Onion keynote addresses at www.perl.com.
it's a messy world requiring a messy solution. ;)
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: Mon, 28 Aug 2000 09:27:10 GMT
From: hasant@trabas.co.id (Hasanuddin Tamir)
Subject: Re: Kill Me!
Message-Id: <slrn8qic4c.vf.hasant@borg.intern.trabas.co.id>
On Sat, 26 Aug 2000 13:39:34 -0400, timewarp@shentel.net wrote:
## To all the self proclaimed 'News Group Gods' out there -
##
## You are hereby instructed to add me to your 'Kill List' as an annoying
## poster for the following reasons :
Naa, I don't think you're so special to add you to such a list.
Besides, you don't have any right to instruct anybody (at least
me) to add anyone to any list.
san
--
trabasLabs * hasant@trabas.com * http://www.trabas.com
Zero Point * hasant@zp.f2s.com * http://www.zp.f2s.com
------------------------------
Date: Sun, 27 Aug 2000 17:08:21 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: Kill Me!
Message-Id: <brian-ya02408000R2708001708210001@news.panix.com>
In article <39A800D6.83CEA245@shentel.net>, Albert Dewey <timewarp@shentel.net> posted:
> At least I made an effort in my prior post regarding the Jeopardy issue
> as to why I do this and supported it with logic. Every post I have read
> criticizing the jeopardy poster has had no rhyme or reason other than
> some really weak argument referring to the 'natural flow of time'.
it's the sequence of ideas, not time. it just happens that time is
related to sequence.
> Keep
> in mind that the 'natural flow of time' also dictates that lemmings will
> run off of cliffs on a regular basis.
another myth.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: Sun, 27 Aug 2000 18:35:40 GMT
From: Brock <brock_johnson@my-deja.com>
Subject: Managing Temporary Directories/Files
Message-Id: <8obn1s$roj$1@nnrp1.deja.com>
I am trying to initiate a form that anyone visiting my website may use that
will allow them to unzip a zip file. I need help managing temporary unzipped
directories and files for those that need to unzip files, but may not have
access to a program like WinZip.Since zip files can extract to one or more
files or directories, I need my script to automatically extract to the amount
of folders(directories) and files needed.I want this all to be done inside of
a directory named "tmp," and each time it is used to make a unique name for
the sub file(s)/directory(s)... or new un-zipped file(s)/directory(s) under
the "tmp" directory.Additionally, I need the script, when done, to
automatically display the unzipped URL's to the user for their immediate
uploading to their own server (or downloading to their PC).The unzipped
file/directory needs to automatically remove itself after a certain amount of
time, say 30 minutes. (I'm doing it this way to prevent including a file
upload feature in the script.)Further, I would like for my perl script to die
if my "tmp" directory fills to more than 5 megabtyes, to keep anyone from
overrunning my disk space.And lastly, I want to limit the program to not
accept zip file sizes over 300K.Complicated? Maybe I should've made this a
challenge as another poster attempted? LOLAny suggestions or help is greatly
appreciated. (I've already researched this extensively in the perl
documentation, but I need more help than is offered there).-- The Best to
all!Brock Johnson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Sun, 27 Aug 2000 16:13:36 -0400
From: Albert Dewey <timewarp@shentel.net>
Subject: Re: Managing Temporary Directories/Files
Message-Id: <39A97670.3D983F37@shentel.net>
Brock wrote:
> I am trying to initiate a form that anyone visiting my website may use that
> will allow them to unzip a zip file. I need help managing temporary unzipped
> directories and files for those that need to unzip files, but may not have
> access to a program like WinZip.
No Brock - I will not flame you for posting this. In fact I find the idea quite
intreguing and unique. With so many people using the internet for functionality,
it is refreshing to come across a new concept as most people are out there
reinventing the wheel. Not sure if you will make any $$$ from this one but I do
see its purpose. However, my help will be limited at best but read on anyway.
> Since zip files can extract to one or more
> files or directories, I need my script to automatically extract to the amount
> of folders(directories) and files needed.I want this all to be done inside of
> a directory named "tmp," and each time it is used to make a unique name for
> the sub file(s)/directory(s)... or new un-zipped file(s)/directory(s) under
> the "tmp" directory.
Basically you are going to have to create a server side utility in Perl that will
manage the session that you wish the user to interact with. This is actually
pretty easy to do, cookies and all. I would not attempt a write of unique
directory names for each of these zipped directories. Instead, I would do just
the opposite as what you have stated, I would create a 'session' directory that
the zipped file will utilize and within this directory create the actual
directory structures - names and all - that the zip/tar file contains. Actually,
I would just go ahead and unzip/untar the file in this created 'session'
directory as the directory structures will automatically be created by doing
this. Perl does have routines or available modules that you can access that will
unzip/untar the file as needed, all you really need to do is to manage the
creation and removal of the 'session' directory as becomes necessary. As to these
routines, I am sure that some of the Perl coders out there can point you in the
direction of the correct module that will make this job of unzipping a file
relatively pain free.
> Additionally, I need the script, when done, to
> automatically display the unzipped URL's to the user for their immediate
> uploading to their own server (or downloading to their PC).The unzipped
> file/directory needs to automatically remove itself after a certain amount of
> time, say 30 minutes. (I'm doing it this way to prevent including a file upload
> feature in the script.)
I would manage this (again, this is just me) by presenting something of a
scrolling list of the extracted files to the user so he could download them and
put them in the proper location. As part of this list I would include an
'extracted to folder' description so the user can create the same directory
structure on the side. Then again if you are a Java coder, you could create a
simple applet that will do this automatically on the client's machine and handle
the download of the requested files without further interaction on the part of
the user. This is how I would handle it because making them manually create the
proper directories and download the files into each proper one will handicap the
user quite a bit if they had to deal with a compressed file with hundreds of
individual files within it. The applet method would involve have a Perl routine
on the server receiving instructions from the Java applet on the client, ftp
style. Would be real sweet if you get it set up properly.
After the session is done, you can use a script that will easily remove the
entire 'session' directory in one easy act. There will be others who will scream
at me for suggesting this but this is how I personally would deal with this -
## Remove the session directory and all its contents where $Session is the
name/path of the 'session' directory.
system ("rm -fr $Session");
Since it is you who will be creating this directory and not the user, I believe
that this is a relatively safe procedure to undertake. If you were to allow the
user to decide upon the directory name that their session will reside in then,
this system call is very dangerous. Again, so long as you are exclusively in
control of the directory creation process, this call is basically harmless. To
run this system command, you would setup a crontab script that would call your
Perl maintenance script every hour or so that manages the removal of old
sessions. As part of this process, you would use Perl to build a simple flatfile
database of session entries in it to record things like the time of the session
and the session folder that the session lives in, then your maintenance routine
would read this datafile to manage the old sessions accordingly.
> Further, I would like for my perl script to die
> if my "tmp" directory fills to more than 5 megabtyes, to keep anyone from
> overrunning my disk space.
Read the next part for a rely to this -
> And lastly, I want to limit the program to not
> accept zip file sizes over 300K.
Simply put this into your Perl script that accepts the uploaded file -
$CGI::POST_MAX=1024 * 300;
This will limit file sizes to a total of 300K per session. I would assume that
300K won't overfill your hard drive too much when unzipped so limiting the upload
to this amount should suffice to control the hard drive space required for the
process as a whole.
> Complicated?
Yes, this is going to be a challenge but when you are done, you will have learned
a hell of a lot about Perl coding as well as other languages/disciplines in the
process. I personally would like to hear of your progress as you get it more
operational. For those who love to flame people, I will argue that I mentioned
Perl as a viable solution to this posters query several times so IMHO this is not
an off topic post. Instead, how about telling this guy where he might find an
unzipping/untarring module so he can get on with his project. Alternative
solutions you might have should be posted as well as my opinion is not the only
one that counts here and I, for one, would like to see other's ideas on how to
accomplish what the poster is attempting to do.
Regards and good luck with it -
Albert Dewey
> Maybe I should've made this a
> challenge as another poster attempted? LOLAny suggestions or help is greatly
> appreciated. (I've already researched this extensively in the perl
> documentation, but I need more help than is offered there).-- The Best to
> all!Brock Johnson
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: Sun, 27 Aug 2000 17:40:40 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: Managing Temporary Directories/Files
Message-Id: <brian-ya02408000R2708001740400001@news.panix.com>
In article <39A97670.3D983F37@shentel.net>, Albert Dewey <timewarp@shentel.net> posted:
> system ("rm -fr $Session");
use system in the list form. things in $Session can cause problems.
--
brian d foy
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>
------------------------------
Date: Sun, 27 Aug 2000 12:17:47 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: No Server Logs
Message-Id: <39A9695B.5B1A4CB2@stomp.stomp.tokyo>
Brock wrote:
> I do not have access to my webserver's logs to see my perl
> coding errors. Is there a better way to show errors to my
> browser than using CGI::Carp('FatalsToBrowser')... or using
> R. Schwartz's script that only shows errors from die or warn?
Why would you expect answers of expertise without
stating your problem concepts and your parameters?
Do you expect people here to guess or to read your mind?
Post those snippets of your script which are
giving you problems along with clear and concise
parameters and an equally clear and concise
explanation of your problem concepts.
Godzilla!
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 4145
**************************************
