[32658] in Perl-Users-Digest
Perl-Users Digest, Issue: 3934 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 26 11:09:38 2013
Date: Fri, 26 Apr 2013 08:09:08 -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 Fri, 26 Apr 2013 Volume: 11 Number: 3934
Today's topics:
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <Joey@still_Learning.invalid>
Re: Ascertaing uploaded file size <dave@invalid.invalid>
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <rweikusat@mssgmbh.com>
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <ben@morrow.me.uk>
Re: Ascertaing uploaded file size <rweikusat@mssgmbh.com>
CGI.pm file upload locations (was: Ascertaing uploaded <rweikusat@mssgmbh.com>
Re: HTML to MHT conversion programmatically <visphatesjava@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 26 Apr 2013 00:09:31 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <bmpo4a-3ej2.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
> On 2013-04-25 14:17, Joey@still_Learning.invalid
> <Joey@still_Learning.invalid> wrote:
> > Ben Morrow wrote:
>
> >>The actual upload is being done by the webserver, or CGI.pm, or
> >>something;
>
> Um, I'd quibble with your terminology here. The server doesn't upload
> anything. It's the client which does the uploading. The server just
> receives the uploaded data (and may pass it on to a CGI script or
> something).
Yeah, OK. 'The actual receipt of the upload is being done...'.
> >>since you still haven't explained properly how you are
> >>running this it's hard to tell. In fact, you almost certainly don't need
> >>to copy the file at all: since it's already been written out on the
> >>server you can probably just rename it to where you want it to live in
> >>the end.
>
> I don't think it's safe to assume that the temporary files and the final
> destination are on the same file system. (Of course File::Copy::move
> will take care of that detail).
I was going to get to that next, once we'd got to the point of
distinguishing between 'files on the server' and 'files on the client'.
In any case, you can usually arrange for the uploads to be spooled to a
directory of your choosing, so that a rename is sufficient. There's no
point copying the file from one filesystem to another if you don't need
to.
Ben
------------------------------
Date: Fri, 26 Apr 2013 00:39:09 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <tdro4a-70k2.ln1@anubis.morrow.me.uk>
Quoth "C.DeRykus" <derykus@gmail.com>:
>
> for (0 .. $imgCnt-1) {
>
> open my $upload_fh, '>', "$filePath/$uploadFiles[$_]"
There is, of course, no need for $imgCnt or the corresponding field to
exist at all. Perl arrays know how long they are, so
for (0..$#uploadFiles) {
is both cleaner and safer. (Safer because it doesn't rely on
client-provided consistency between the parameters.)
Ben
------------------------------
Date: Fri, 26 Apr 2013 00:35:35 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <77ro4a-70k2.ln1@anubis.morrow.me.uk>
Quoth "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>:
> Peter J. Holzer wrote:
> >
> >You haven't shown us any code which retrieves the parameters containing
> >those file sizes. Instead you have shown us this:
> >
> > for (my $j = 0; $j < $imgCnt; $j++) {
> > $filename = $uploadFiles[$j];
> > $filesize = -s $filename
>
> File names and pertinent information is contained in the [HTML5-created]
> array myFile0[] which is in a form input element submitted to the perl
> script.
The information submitted in that array does *not* include the size of
the file, except implicitly by counting the number of bytes submitted.
(Which is what you're trying to verify, of course.)
> perl:
> @uploadFiles = param('myFile0[]');
> @filesize = ();
> $filename = $uploadFiles[$i];
> $filesize = -s $filename;
> push(@filesize, $filesize);
There is an important point here which I think you are not
understanding: there are *three* copies of the file altogether. First
there is the copy on the client. The browser packs this up into an HTTP
request and sends it to the server. Then on the server CGI.pm
automatically unpacks this request into a temporary directory; this is
the second copy, and is the point at which the 'upload' actually occurs.
Then, finally, you are copying this copy again into a different
directory on the server.
The size returned by that -s operator is the size of the *second* copy;
that is, if the upload was corrupted, it is the size *after* the
corruption happens. You need to see the size of the *first* copy, which
you can only get from the client.
> Obviously, the filesize info could be separately submitted by using js to
> ascertain file size:
>
> files = e.dataTransfer.files;
> filesize = files.size
>
> But, there's no reason to do this, as submitted file size can be
> ascertained in perl (as I have done, and shown).
files is a FileList object, which doesn't have a .size property...
Assuming you meant to iterate over the FileList and return an array of
file sizes, this *is* what you need to do to verify the upload happened
correctly. This JavaScript is the only code which has access to the
original file on the client filesystem, before the upload happens.
> >At this point $filesize doesn't contain a size which was possibly
> >captured by some javascript code on the client and submitted to the
> >server. It contains the size of the file $uploadFiles[$j] ON THE SERVER.
>
> Which are the files submitted for upload, not the files that have been
> uploaded.
No, they aren't. *Think* about it, for goodness' sake: how on Earth is
the -s operator going to reach back over the Internet to the client
machine and find out what size the file was?
> >As far as I can see you haven't shown us how @uploadFiles is populated
> >either, so we don't know what's in that array either.
>
> Someone needs to learn HTML5 Forms.
Being rude to regulars is a very quick way to end up in everyone's
killfiles. Peter and I understand HTML perfectly well; you, on the other
hand, do not understand how CGI.pm works.
> >Yes, but not in the code you've shown us. Both uploading and receiving
> >the upload is happening in code you haven't shown us.
> >
> Exactly the code I've shown (today).
No. The actual upload, to a temporary spool directory, happens
implicitly when you create a CGI object, which isn't in code you've
shown us yet.
> >The purpose of your code is trying to detect an error during upload. You
> >don't know that your code works until you successfully detected such an
> >error (and even then you know only that you can detect that specific
> >error).
> >
> What part of I tested the code by hard-coding errors did you not grasp? I
> uploaded the files. I looked at the server folder, and by gosh, there they
> are. The filesize comparisons rely on the file size values pushed into the
> @filesize array BEFORE the upload.
No. Once you get as far as populating @filesize the upload has already
happened. It happened when you called CGI->new.
> Populating @filesize with hard-coded
> values in @filesize, which values are different from the file sizes on the
> server works. If the file sizes in the array are different than the
> filesizes of the same-named files on the server, the script detects the
> error. Yes, of course, I prevent uploading and populating @filesize with
> the originally submitted files.
Now try uploading a really big file over a really slow network, and
cancel the upload before it finishes. What happens? If your script runs,
does it detect that the file was truncated?
(I suspect either the webserver or CGI.pm will detect the request was
cancelled and your code will never even get invoked, but it might not.)
Ben
------------------------------
Date: Thu, 25 Apr 2013 18:04:14 -0700
From: "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>
Subject: Re: Ascertaing uploaded file size
Message-Id: <t6ijn85tppmvo1gas98h9ddkb7p9mjl5jg@4ax.com>
Ben Morrow wrote:
>Quoth "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>:
>> Peter J. Holzer wrote:
>> >
>> >You haven't shown us any code which retrieves the parameters containing
>> >those file sizes. Instead you have shown us this:
>> >
>> > for (my $j = 0; $j < $imgCnt; $j++) {
>> > $filename = $uploadFiles[$j];
>> > $filesize = -s $filename
>>
>> File names and pertinent information is contained in the [HTML5-created]
>> array myFile0[] which is in a form input element submitted to the perl
>> script.
>
>The information submitted in that array does *not* include the size of
>the file, except implicitly by counting the number of bytes submitted.
>(Which is what you're trying to verify, of course.)
>
>> perl:
>> @uploadFiles = param('myFile0[]');
>> @filesize = ();
>> $filename = $uploadFiles[$i];
>> $filesize = -s $filename;
>> push(@filesize, $filesize);
>
>There is an important point here which I think you are not
>understanding:
There's a lot to this exercise I don't seem to be understanding.
> there are *three* copies of the file altogether. First
>there is the copy on the client. The browser packs this up into an HTTP
>request and sends it to the server. Then on the server CGI.pm
>automatically unpacks this request into a temporary directory; this is
>the second copy, and is the point at which the 'upload' actually occurs.
>Then, finally, you are copying this copy again into a different
>directory on the server.
Isn't the upload being performed by the loop?
open (UPLOADFILE, ">$filePath/$filename") or die $!";
binmode UPLOADFILE;
while (<$upload_filehandle>) {
print UPLOADFILE;
}
close UPLOADFILE or die "Can't Close. $!";
[check file sizes here]
If I jump over this to the check file sizes code, am I not defeating the
upload? If I've ascertained file sizes before this loop, how could they
be the file sizes on the server?
If I hard-code @filesizes with incorrect sizes, defeat the upload, and
then check the file sizes of the files that were previously uploaded, and
it throws a filesize error, am I not comparing the correct files?
>
>The size returned by that -s operator is the size of the *second* copy;
>that is, if the upload was corrupted, it is the size *after* the
>corruption happens. You need to see the size of the *first* copy, which
>you can only get from the client.
Have I not effectively eliminated this possibility by defeating the
upload?
I understand that on the server CGI.pm does it's thing, but without an
upload, does CGI.pm ever see the files?
My testing code is basically:
chdir $filePath or die "Can't change dir to $filePath: $!";
@uploadFiles = param('myFile0[]');
@filesize = (n1, n2, n3);
#n1, n2, n3 are manually valued and do not resemble the file sizes of the
files already uploaded on the server.
$numImagesReceived = 0;
$uploadErrorFlag = 0;
opendir DH,$filePath or die
for (my $j = 0; $j < $imgCnt; $j++) {
$filename = $uploadFiles[$j];
$filesize = $filesize[$j];
while (my $serverFileName = readdir DH) {
$serverFileSize = -s $serverFileName;
if ($filesize == $serverFileSize) {$numImagesReceived++;}
}
if ($numImagesReceived != $imgCnt) {$uploadErrorFlag = 1;}
}
>files is a FileList object, which doesn't have a .size property...
If I grab one of the files and perform a '-s filename' am I not
ascertaining the length of the file?
>
>Assuming you meant to iterate over the FileList and return an array of
>file sizes, this *is* what you need to do to verify the upload happened
>correctly. This JavaScript is the only code which has access to the
>original file on the client filesystem, before the upload happens.
I can certainly do this in javascript (filesize = filename.size), but I
didn't see any reason to, as doing it as I have seems to work.
>
>> >At this point $filesize doesn't contain a size which was possibly
>> >captured by some javascript code on the client and submitted to the
>> >server. It contains the size of the file $uploadFiles[$j] ON THE SERVER.
>>
>> Which are the files submitted for upload, not the files that have been
>> uploaded.
>
>No, they aren't. *Think* about it, for goodness' sake: how on Earth is
>the -s operator going to reach back over the Internet to the client
>machine and find out what size the file was?
I'm pushing the sizes into an array before anything is uploaded. Why isn't
this correct?
>
>> Someone needs to learn HTML5 Forms.
>
>Being rude to regulars is a very quick way to end up in everyone's
>killfiles. Peter and I understand HTML perfectly well; you, on the other
>hand, do not understand how CGI.pm works.
Sorry for the outburst, but when I feel I've been insulted, I react.
>
>> >Yes, but not in the code you've shown us. Both uploading and receiving
>> >the upload is happening in code you haven't shown us.
>> >
>> Exactly the code I've shown (today).
>
>No. The actual upload, to a temporary spool directory, happens
>implicitly when you create a CGI object, which isn't in code you've
>shown us yet.
I have shown you every byte of code.
>
>> >The purpose of your code is trying to detect an error during upload. You
>> >don't know that your code works until you successfully detected such an
>> >error (and even then you know only that you can detect that specific
>> >error).
>> >
>> What part of I tested the code by hard-coding errors did you not grasp? I
>> uploaded the files. I looked at the server folder, and by gosh, there they
>> are. The filesize comparisons rely on the file size values pushed into the
>> @filesize array BEFORE the upload.
>
>No. Once you get as far as populating @filesize the upload has already
>happened. It happened when you called CGI->new.
CGI is mentioned at the start of the script as:
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);
my $query = new CGI;
And in the script once:
@upload_filehandles = $query->upload("myFile0[]");
Where does the CGI upload take place?
>
>Now try uploading a really big file over a really slow network, and
>cancel the upload before it finishes. What happens? If your script runs,
>does it detect that the file was truncated?
In my ignorance, I don't know how to do this.
>
>(I suspect either the webserver or CGI.pm will detect the request was
>cancelled and your code will never even get invoked, but it might not.)
>
Don't know, but I do know that if I fake the upload, as I did, I'm
throwing the appropriate result.
Again, I do greatly appreciate your and others' help on this. As my nym
says, I'm still learning...
--
Joey
------------------------------
Date: Fri, 26 Apr 2013 10:58:02 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Re: Ascertaing uploaded file size
Message-Id: <fV45K0OBJxbE-pn2-q62nMBNtqiyN@paddington.bear.den>
On Thu, 25 Apr 2013 23:09:31 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>
> I was going to get to that next, once we'd got to the point of
> distinguishing between 'files on the server' and 'files on the client'.
> In any case, you can usually arrange for the uploads to be spooled to a
> directory of your choosing, so that a rename is sufficient. There's no
> point copying the file from one filesystem to another if you don't need
> to.
Hi Ben
Please, how do you get it to spool where you want? I am troubled by
left overs sometimes. It seems to default to the directory the CGI
script is in.
--
Regards
Dave Saville
------------------------------
Date: Fri, 26 Apr 2013 13:07:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <q87q4a-eh03.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> On Thu, 25 Apr 2013 23:09:31 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > I was going to get to that next, once we'd got to the point of
> > distinguishing between 'files on the server' and 'files on the client'.
> > In any case, you can usually arrange for the uploads to be spooled to a
> > directory of your choosing, so that a rename is sufficient. There's no
> > point copying the file from one filesystem to another if you don't need
> > to.
>
> Please, how do you get it to spool where you want? I am troubled by
> left overs sometimes. It seems to default to the directory the CGI
> script is in.
You're using CGI.pm? You set $CGITempFile::TMPDIRECTORY. (Yes, CGI.pm
stomps on other random top-level namespaces, including Fh.)
Ben
------------------------------
Date: Fri, 26 Apr 2013 14:26:39 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Ascertaing uploaded file size
Message-Id: <87obd1zals.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Dave Saville" <dave@invalid.invalid>:
>> On Thu, 25 Apr 2013 23:09:31 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>> >
>> > I was going to get to that next, once we'd got to the point of
>> > distinguishing between 'files on the server' and 'files on the client'.
>> > In any case, you can usually arrange for the uploads to be spooled to a
>> > directory of your choosing, so that a rename is sufficient. There's no
>> > point copying the file from one filesystem to another if you don't need
>> > to.
>>
>> Please, how do you get it to spool where you want? I am troubled by
>> left overs sometimes. It seems to default to the directory the CGI
>> script is in.
>
> You're using CGI.pm? You set $CGITempFile::TMPDIRECTORY. (Yes, CGI.pm
> stomps on other random top-level namespaces, including Fh.)
The documented way to achieve this is to set the environment variable
TMPDIR to a suitable value.
------------------------------
Date: Fri, 26 Apr 2013 15:00:24 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <osdq4a-78.ln1@anubis.morrow.me.uk>
Quoth "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>:
> Ben Morrow wrote:
> >
> >There is an important point here which I think you are not
> >understanding:
>
> There's a lot to this exercise I don't seem to be understanding.
I think actually there's only one thing, which is that the Perl code is
running on the server, the Javascript is running on the client, and
these are separate machines with a very limited amount of communication
between them.
> > there are *three* copies of the file altogether. First
> >there is the copy on the client. The browser packs this up into an HTTP
> >request and sends it to the server. Then on the server CGI.pm
> >automatically unpacks this request into a temporary directory; this is
> >the second copy, and is the point at which the 'upload' actually occurs.
> >Then, finally, you are copying this copy again into a different
> >directory on the server.
>
> Isn't the upload being performed by the loop?
>
> open (UPLOADFILE, ">$filePath/$filename") or die $!";
> binmode UPLOADFILE;
> while (<$upload_filehandle>) {
> print UPLOADFILE;
> }
> close UPLOADFILE or die "Can't Close. $!";
> [check file sizes here]
*No*. How many times do I have to say this? The upload is performed by
CGI.pm, when you create the query object, and it spools the uploaded
files into a temporary directory.
> If I jump over this to the check file sizes code, am I not defeating the
> upload? If I've ascertained file sizes before this loop, how could they
> be the file sizes on the server?
If you've ascertained the file sizes *on the server*, how could they be
anything *other* than the sizes of files *already on the server*?
> If I hard-code @filesizes with incorrect sizes, defeat the upload, and
> then check the file sizes of the files that were previously uploaded, and
> it throws a filesize error, am I not comparing the correct files?
If you jump over that loop, the upload (done by CGI.pm to a temporary
directory) will still happen. Your code will then completely ignore the
uploaded files, and compare the random file sizes you gave it with the
sizes of some other random files on the server.
> >The size returned by that -s operator is the size of the *second* copy;
> >that is, if the upload was corrupted, it is the size *after* the
> >corruption happens. You need to see the size of the *first* copy, which
> >you can only get from the client.
>
> Have I not effectively eliminated this possibility by defeating the
> upload?
I don't understand what you mean. -s returns the size of a file on the
system the Perl code is running on. It doesn't magically do something
else. The original file is on the client's filesystem, so -s on the
server can't possibly return its size.
> I understand that on the server CGI.pm does it's thing, but without an
> upload, does CGI.pm ever see the files?
CGI.pm sees the uploaded files *before* you do. Try adding
$CGI::DISABLE_UPLOADS = 1;
right after the 'use CGI' line. You will find that your code no longer
sees any uploaded files at all, because CGI is no longer copying them
out to disk for you.
> My testing code is basically:
'Basically'? Why 'basically'? Why not 'exactly'?
I asked you before not to post any code you haven't actually run.
> chdir $filePath or die "Can't change dir to $filePath: $!";
> @uploadFiles = param('myFile0[]');
You are still not using 'strict'. If you won't make even a basic effort
to help yourself find problems I'm not particularly inclined to help
you any further.
> @filesize = (n1, n2, n3);
> #n1, n2, n3 are manually valued and do not resemble the file sizes of the
> files already uploaded on the server.
>
> $numImagesReceived = 0;
> $uploadErrorFlag = 0;
>
> opendir DH,$filePath or die
> for (my $j = 0; $j < $imgCnt; $j++) {
> $filename = $uploadFiles[$j];
> $filesize = $filesize[$j];
>
> while (my $serverFileName = readdir DH) {
> $serverFileSize = -s $serverFileName;
> if ($filesize == $serverFileSize) {$numImagesReceived++;}
> }
> if ($numImagesReceived != $imgCnt) {$uploadErrorFlag = 1;}
> }
This... is complete nonsense. The first time round the 'for' loop, you
read through the entire directory and count the number of files with a
size of n1. Then, if that number doesn't match $imgCnt (and why should
it?) you set $uploadErrorFlag. The second and subsequent times round the
'for' loop readdir will not return any entries, because you haven't
rewound the directory handle.
> >files is a FileList object, which doesn't have a .size property...
>
> If I grab one of the files and perform a '-s filename' am I not
> ascertaining the length of the file?
Javascript does not have a -s operator.
> >Assuming you meant to iterate over the FileList and return an array of
> >file sizes, this *is* what you need to do to verify the upload happened
> >correctly. This JavaScript is the only code which has access to the
> >original file on the client filesystem, before the upload happens.
>
> I can certainly do this in javascript (filesize = filename.size), but I
> didn't see any reason to, as doing it as I have seems to work.
It may 'seem to work' in that it doesn't give you any errors, but it
isn't actually verifying anything useful.
> >> Which are the files submitted for upload, not the files that have been
> >> uploaded.
> >
> >No, they aren't. *Think* about it, for goodness' sake: how on Earth is
> >the -s operator going to reach back over the Internet to the client
> >machine and find out what size the file was?
>
> I'm pushing the sizes into an array before anything is uploaded. Why isn't
> this correct?
*Everything* that runs on the server (that is, *everything* written in
Perl) runs *after* the upload has already happened.
Can you explain how you think the -s operator works? (This is a serious
question; trying to explain this will help you understand what's going
on.) How do you think it finds out the size of a file on the client's
filesystem?
> >No. The actual upload, to a temporary spool directory, happens
> >implicitly when you create a CGI object, which isn't in code you've
> >shown us yet.
>
> I have shown you every byte of code.
Up until now, you hadn't. You were missing...
[...]
> CGI is mentioned at the start of the script as:
> use CGI qw(:standard);
> use CGI::Carp qw(fatalsToBrowser);
> my $query = new CGI;
^^^^^^^^^^^^^^^^^^^
...this line...
> And in the script once:
>
> @upload_filehandles = $query->upload("myFile0[]");
>
> Where does the CGI upload take place?
...which is the line which actually does the upload.
This is why I keep asking you to post *complete programs* you have
*actually run*. Up until now we didn't even know for sure you were using
CGI.pm; we guessed you were, but since there are lots of other modules
which provide the same interface it was impossible to be sure.
> >Now try uploading a really big file over a really slow network, and
> >cancel the upload before it finishes. What happens? If your script runs,
> >does it detect that the file was truncated?
>
> In my ignorance, I don't know how to do this.
- Find a file big enough that it takes several seconds to upload.
- Upload it.
- Press the 'Stop' button before the upload finishes.
- See what happens.
Ben
------------------------------
Date: Fri, 26 Apr 2013 15:04:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Ascertaing uploaded file size
Message-Id: <65eq4a-78.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > You're using CGI.pm? You set $CGITempFile::TMPDIRECTORY. (Yes, CGI.pm
> > stomps on other random top-level namespaces, including Fh.)
>
> The documented way to achieve this is to set the environment variable
> TMPDIR to a suitable value.
That affects more than just CGI.pm. The CGI.pm documentation (version
3.59) says
| The temporary directory is selected using the following algorithm:
|
| 1. if $CGITempFile::TMPDIRECTORY is already set, use that
|
| 2. if the environment variable TMPDIR exists, use the location
| indicated.
|
| 3. Otherwise try the locations /usr/tmp, /var/tmp, C:\temp,
| /tmp, /temp, ::Temporary Items, and \WWW_ROOT.
|
| Each of these locations is checked that it is a directory and is
| writable. If not, the algorithm tries the next choice.
Ben
------------------------------
Date: Fri, 26 Apr 2013 15:35:50 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Ascertaing uploaded file size
Message-Id: <877gjpz7eh.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> >
>> > You're using CGI.pm? You set $CGITempFile::TMPDIRECTORY. (Yes, CGI.pm
>> > stomps on other random top-level namespaces, including Fh.)
>>
>> The documented way to achieve this is to set the environment variable
>> TMPDIR to a suitable value.
>
> That affects more than just CGI.pm. The CGI.pm documentation (version
> 3.59) says
>
> | The temporary directory is selected using the following algorithm:
> |
> | 1. if $CGITempFile::TMPDIRECTORY is already set, use that
> |
> | 2. if the environment variable TMPDIR exists, use the location
> | indicated.
> |
> | 3. Otherwise try the locations /usr/tmp, /var/tmp, C:\temp,
> | /tmp, /temp, ::Temporary Items, and \WWW_ROOT.
> |
> | Each of these locations is checked that it is a directory and is
> | writable. If not, the algorithm tries the next choice.
I quoted this from 3.43.
------------------------------
Date: Fri, 26 Apr 2013 14:43:01 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: CGI.pm file upload locations (was: Ascertaing uploaded file size)
Message-Id: <87haitz9ui.fsf_-_@sapphire.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
> On Thu, 25 Apr 2013 23:09:31 UTC, Ben Morrow <ben@morrow.me.uk> wrote:
>> I was going to get to that next, once we'd got to the point of
>> distinguishing between 'files on the server' and 'files on the client'.
>> In any case, you can usually arrange for the uploads to be spooled to a
>> directory of your choosing, so that a rename is sufficient. There's no
>> point copying the file from one filesystem to another if you don't need
>> to.
>
> Hi Ben
>
> Please, how do you get it to spool where you want? I am troubled by
> left overs sometimes. It seems to default to the directory the CGI
> script is in.
Quoting the CGI.pm documentation:
The temporary directory is selected using the following
algorithm:
1. if the current user (e.g. "nobody") has a directory named
"tmp" in its home directory, use that (Unix systems only).
2. if the environment variable TMPDIR exists, use the location
indicated.
3. Otherwise try the locations /usr/tmp, /var/tmp, C:\temp,
/tmp, /temp, ::Temporary Items, and \WWW_ROOT.
Each of these locations is checked that it is a directory and
is writable. If not, the algorithm tries the next choice.
Another option is to pass an 'upload hook' subroutine to the CGI.pm
constructor (or use the upload_hook function). This looks like this:
my $cgi = CGI->new(\&hook, undef, undef);
The 2nd argument is an optional 'data item' which will be passed to
the upload_hook routine. It is usually more convenient to use a
closure with direct access to any necessary 'data items' instead. The
3rd argument specifies whether CGI.pm should automatically create a
temporary file (default is 'yes'). If this is set to false, no
temporary file will be created. The 'upload hook' routine is going to
be invoked with the remote filename, a buffer containing a block of
file data, the amount of data in this buffer (someone had a serious
"Am I not writing C ATM?" problem here ...) and the 'data item' which
was specified when the hook as created. The 'upload hook' subroutine
can then process the file data in any desired way, including writing
it to a real file with any name and in any location the CGI process
can write to.
------------------------------
Date: Thu, 25 Apr 2013 16:02:03 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: HTML to MHT conversion programmatically
Message-Id: <058b2d5d-790c-4f9e-ba0e-81d237231303@googlegroups.com>
On Tuesday, April 23, 2013 11:24:10 PM UTC-7, Vincent Bela=EFche wrote:
> Hello,
>=20
>=20
>=20
> I am a newbie in Perl. I have written only a few simples scripts, but
>=20
> that could make me feel the power of the language.
>=20
>=20
>=20
> Now, I am looking for some way to convert an HTML file and the
>=20
> dependency thereof into an MHT archive. All the files are local on my
>=20
> hard drive. I looked for that on the internet, in vain.
>=20
>=20
>=20
> I thought that Perl is probably the best language to make it, and I
>=20
> wondered whether that already exists or not. I could not find anything
>=20
> such thing on the CPAN --- well there are Email::MIME or MIME::Entity
>=20
> and Email::Sender for MIME encoding, but I am not sure whether they are
>=20
> flexible enough to do an MHT archive, and I must admit that I am not
>=20
> expert in MHT archive format. Also I found quite a few HTML parsers, but
>=20
> I don't know which one is the most suited.
>=20
>=20
>=20
> In a nutshell, there seems to be already all the building blocks to make
>=20
> it in a few lines of code, however nothing ready to work off-the-shelf.
>=20
>=20
>=20
> Any feedback or help is welcome.
>=20
>=20
>=20
> Vincent.
downlaod opera
open html in opera
saev as mht
DONE
------------------------------
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 3934
***************************************
