[32305] in Perl-Users-Digest
Perl-Users Digest, Issue: 3572 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Dec 21 16:09:25 2011
Date: Wed, 21 Dec 2011 13:09:08 -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 Wed, 21 Dec 2011 Volume: 11 Number: 3572
Today's topics:
Re: CGI alternatives/replacements <justin.1111@purestblue.com>
Re: CGI alternatives/replacements <tzz@lifelogs.com>
Re: CGI alternatives/replacements <justin.1111@purestblue.com>
Re: CGI alternatives/replacements <rweikusat@mssgmbh.com>
Re: CGI alternatives/replacements <tzz@lifelogs.com>
Filter for mail attachment size ? (to be used from Proc <damjensen@gmail.com>
Re: Filter for mail attachment size ? (to be used from <ben@morrow.me.uk>
Re: Filter for mail attachment size ? (to be used from <nospam@lisse.NA>
Re: IO::Socket::INET hostname restrictions? <ben@morrow.me.uk>
Re: IO::Socket::INET hostname restrictions? <ben@morrow.me.uk>
Paging David Canzi (Seymour J.)
Re: Paging David Canzi <dmcanzi@uwaterloo.ca>
Session termination using use CGI::Session; redirection <r.ted.byers@gmail.com>
Re: vi regex to preserve interior commas in CSV string <rui.maciel@gmail.com>
Re: vi regex to preserve interior commas in CSV string <cwilbur@chromatico.net>
Re: vi regex to preserve interior commas in CSV string <cartercc@gmail.com>
Why doesn't this work? <Joey@still_Learning.invalid>
Re: Why doesn't this work? <willem@toad.stack.nl>
Re: Why doesn't this work? <rweikusat@mssgmbh.com>
Re: Why doesn't this work? <Joey@still_Learning.invalid>
Re: Why doesn't this work? <jimsgibson@gmail.com>
Re: Why doesn't this work? <Joey@still_Learning.invalid>
Re: Why doesn't this work? <Joey@still_Learning.invalid>
Re: Why doesn't this work? <stevem_@nogood.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 19 Dec 2011 15:15:06 +0000
From: Justin C <justin.1111@purestblue.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <q014s8-mjl.ln1@zem.masonsmusic.co.uk>
Thank you Ben, and everyone for the interesting posts. I'll do some
reading up on PSGI, Plack and Catalyst.
I do know that every time I review code I've written more than about 6
months ago I realise that I've learnt a better way to do a whole bunch
of it, and often re-write. Maybe the next time I rewrite any of the
intranet pages I'll consider a migration and do one part at a time.
It's been very interesting reading your replies, thank you again.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Mon, 19 Dec 2011 13:02:01 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <87wr9sfnja.fsf@lifelogs.com>
On 17 Dec 2011 03:13:53 GMT xhoster@gmail.com wrote:
x> If you want your forms to look like they were designed by a
x> professional graphics artist with a lot of time on their hands (and
x> are actually willing to hire one to spend that time!) then I
x> certainly wouldn't CGI.pm, although I don't exactly what to recommend
x> instead.
If you want nice forms and HTML in general with minimum effort, use
Blueprint CSS (from Twitter). It does all the visuals in CSS so you can
concentrate on the data handling. There are some Javascript plugins but
they are not required. That will let you put off hiring a graphics
designer for a bit longer :)
Ted
------------------------------
Date: Tue, 20 Dec 2011 09:45:03 +0000
From: Justin C <justin.1111@purestblue.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <v126s8-ru2.ln1@zem.masonsmusic.co.uk>
On 2011-12-19, Ted Zlatanov <tzz@lifelogs.com> wrote:
>
> If you want nice forms and HTML in general with minimum effort, use
> Blueprint CSS (from Twitter). It does all the visuals in CSS so you can
> concentrate on the data handling. There are some Javascript plugins but
> they are not required. That will let you put off hiring a graphics
> designer for a bit longer :)
Thank you for the pointer. Interesting stuff. Our site is already quite
tightly designed, but I have a use for this outside work.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Tue, 20 Dec 2011 14:37:56 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <8762hbux4r.fsf@sapphire.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On 17 Dec 2011 03:13:53 GMT xhoster@gmail.com wrote:
>
> x> If you want your forms to look like they were designed by a
> x> professional graphics artist with a lot of time on their hands (and
> x> are actually willing to hire one to spend that time!) then I
> x> certainly wouldn't CGI.pm, although I don't exactly what to recommend
> x> instead.
>
> If you want nice forms and HTML in general with minimum effort, use
> Blueprint CSS (from Twitter). It does all the visuals in CSS so you can
> concentrate on the data handling. There are some Javascript plugins but
> they are not required.
... provided that compatibility with existing client software, aka
'Javascript browser detection' in order to work around the fact that
no software on this planet supports anything the W3C specified in the
last 20 years completely, not the least because the W3C usually comes
up with five different way to solve the same problem in half as many
years, is also 'not required' ...
------------------------------
Date: Tue, 20 Dec 2011 17:20:33 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: CGI alternatives/replacements
Message-Id: <8762hac2by.fsf@lifelogs.com>
On Tue, 20 Dec 2011 14:37:56 +0000 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
RW> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On 17 Dec 2011 03:13:53 GMT xhoster@gmail.com wrote:
>>
x> If you want your forms to look like they were designed by a
x> professional graphics artist with a lot of time on their hands (and
x> are actually willing to hire one to spend that time!) then I
x> certainly wouldn't CGI.pm, although I don't exactly what to recommend
x> instead.
>>
>> If you want nice forms and HTML in general with minimum effort, use
>> Blueprint CSS (from Twitter). It does all the visuals in CSS so you can
>> concentrate on the data handling. There are some Javascript plugins but
>> they are not required.
RW> ... provided that compatibility with existing client software, aka
RW> 'Javascript browser detection' in order to work around the fact that
RW> no software on this planet supports anything the W3C specified in the
RW> last 20 years completely, not the least because the W3C usually comes
RW> up with five different way to solve the same problem in half as many
RW> years, is also 'not required' ...
Right. Exactly. You read my mind. It's like we're twins.
Ted
------------------------------
Date: Tue, 20 Dec 2011 01:38:11 -0800 (PST)
From: Horst Lemminger <damjensen@gmail.com>
Subject: Filter for mail attachment size ? (to be used from Procmail or similar)
Message-Id: <bbd92806-9674-4237-853f-28991ec62879@o14g2000vbo.googlegroups.com>
I have been looking for a long time for a filter on attachment size in
emails.
At the mailserver, which is running Postfix and Procmail, there
already is a an auto-reply filter in Perl that checks a DB for status,
so filtering with Perl in general works.
Here is what I would like to do:
* check mail if there is any attached files
* if attachment is above (xxx) bytes - this can be read from a
database per user - remove the attachment and send a reply back to
sender that they need to use an upload service.
* then forward rest of mail (main body) to recipient
I have studied the docs on Mail::Simple etc, but have not been able to
understand how.
So, anyone with a completed script or points on how to get started on
this ?
Ultimate goal is to get rid of people that mail 10Mb+ screenshots to
explain a simple thing.
PS: if anyone has a pointer on how to do this in Procmail or other
scripting languages, fine with me..
Thanks
------------------------------
Date: Tue, 20 Dec 2011 15:13:42 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Filter for mail attachment size ? (to be used from Procmail or similar)
Message-Id: <6al6s8-3qf.ln1@anubis.morrow.me.uk>
Quoth Horst Lemminger <damjensen@gmail.com>:
> I have been looking for a long time for a filter on attachment size in
> emails.
>
> At the mailserver, which is running Postfix and Procmail, there
> already is a an auto-reply filter in Perl that checks a DB for status,
> so filtering with Perl in general works.
>
> Here is what I would like to do:
>
> * check mail if there is any attached files
> * if attachment is above (xxx) bytes - this can be read from a
> database per user - remove the attachment and send a reply back to
> sender that they need to use an upload service.
> * then forward rest of mail (main body) to recipient
>
> I have studied the docs on Mail::Simple etc, but have not been able to
> understand how.
I would recommend setting Postfix's message_size_limit parameter
instead. This won't do exactly what you want: it will bounce any message
which is over the limit, regardless of whether the overrun is in an
attachment or not, and it will not attempt to remove the oversized
section and forward the rest. This may be unacceptable to you: the
advantage is it will be much more efficient.
If you are going to be auto-replying to emails yourself (rather than
letting Postfix do it), you need to *be* *very* *careful*. This sort of
application often ends up doing more harm than good. At the very least
you need to read and understand RFC 3834.
That said, there are (AFAIK) two basic options for extracting
attachments in Perl: Email::MIME and MIME::Parser. Email::MIME is much
simpler and faster, but requires that you hold the whole message (and
all the extracted parts) in memory. If you're potentially dealing with
very large messages, this might be a problem (certainly, you would need
to set Postfix's message_size_limit to something sensible in this case).
MIME::Parser will extract the attachments to temporary files if it needs
to, so it can deal with arbitrary-sized messages without a problem. The
disadvantage is that every time a mail delivery touches the disk it
slows things down horribly. (Of course, if you're already invoking a
fresh instance of perl from procmail for every delivery, you maybe don't
care about that.)
> So, anyone with a completed script or points on how to get started on
> this ?
Pick one of those modules, read the docs carefully, and see how far you
can get. Post what you end up with, and people might help you improve
it.
Ben
------------------------------
Date: Tue, 20 Dec 2011 12:14:50 +0200
From: Dr Eberhard Lisse <nospam@lisse.NA>
Subject: Re: Filter for mail attachment size ? (to be used from Procmail or similar)
Message-Id: <4EF0601A.4040607@lisse.NA>
Me three, four, five :-)-O
I am more interested from the perspective of doing really weird
stuff in developing countries, which involve cutting off of
attachments, batching and gzipping, and perhaps even uucp again :-)-O
Of course at the same time one would need to check for the message
size so that one catches uu/mime-encoded stuff in the text, which
doesn't gzip nice and as such could just be bounced altogether...
el
on 2011-12-20 11:38 Horst Lemminger said the following:
> I have been looking for a long time for a filter on attachment
> size in emails.
>
> At the mailserver, which is running Postfix and Procmail, there
> already is a an auto-reply filter in Perl that checks a DB for
> status, so filtering with Perl in general works.
>
> Here is what I would like to do:
>
> * check mail if there is any attached files
> * if attachment is above (xxx) bytes - this can be read from a
> database per user - remove the attachment and send a reply back to
> sender that they need to use an upload service.
> * then forward rest of mail (main body) to recipient
>
> I have studied the docs on Mail::Simple etc, but have not been
> able to understand how.
>
> So, anyone with a completed script or points on how to get started
> on this ?
>
> Ultimate goal is to get rid of people that mail 10Mb+ screenshots
> to explain a simple thing. PS: if anyone has a pointer on how to
> do this in Procmail or other scripting languages, fine with me..
>
> Thanks
--
Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar)
el@lisse.NA el108-ARIN / * | Telephone: +264 81 124 6733 (cell)
PO Box 8421 \ / Please do NOT email to this address
Bachbrecht, Namibia ;____/ if it is DNS related in ANY way
------------------------------
Date: Tue, 20 Dec 2011 17:21:13 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IO::Socket::INET hostname restrictions?
Message-Id: <9ps6s8-glc2.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <2io7r8-1si.ln1@anubis.morrow.me.uk>, on 12/08/2011
> at 09:58 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> > patch -p1 < saved-patch-file
> > perl Makefile.PL
> > make test
> > perl -Mblib -MIO::Socket::INET -e"IO::Socket::INET->new(
> > PeerAddr => 'whois.nic.mn', PeerPort => 43,
> > Timeout => 5) or die $@"
>
> I.e, do I need a make before the make test?
Either should work (make test implicitly performs make if it hasn't been
done yet).
> I've already installed IO-1.25; I'll test your patch but probably will
> wait for an updated version on CPAN before installing it. Thanks.
OK. Thank you.
Ben
------------------------------
Date: Tue, 20 Dec 2011 23:43:20 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IO::Socket::INET hostname restrictions?
Message-Id: <o5j7s8-ohi2.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <9ps6s8-glc2.ln1@anubis.morrow.me.uk>, on 12/20/2011
> at 05:21 PM, Ben Morrow <ben@morrow.me.uk> said:
>
> >Either should work (make test implicitly performs make if it hasn't
> >been done yet).
>
> In this case I had alread done make, make test and make install. Would
> make have recognized that I ran the patch had it hit code that needed
> to be recompiled? That's not, of course, an issue for Socket.pm.
It should, yes. (Assuming OS/2 updates file timestamps in a sensible
fashion, which I expect it does.)
If you're not sure, is there any reason not to simply delete that
working directory and start again from the tarball? That's what I would
do in this situation, simply because it's quicker than thinking about
it.
(Yes, this is just the usual Unix worse-is-better brute-force approach
to the problem.)
Ben
------------------------------
Date: Wed, 21 Dec 2011 02:43:22 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Paging David Canzi
Message-Id: <4ef18e1a$29$fuzhry+tra$mr2ice@news.patriot.net>
This should appear without the X-* header fields.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Wed, 21 Dec 2011 17:24:01 +0000 (UTC)
From: "David Canzi" <dmcanzi@uwaterloo.ca>
Subject: Re: Paging David Canzi
Message-Id: <jct4nh$vhb$1@rumours.uwaterloo.ca>
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>This should appear without the X-* header fields.
>
>--
>Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
And your article is present on the news servers I checked that
your previous articles were not on.
--
David Canzi | "I put a dollar in a change machine. Nothing changed."
| -- George Carlin
------------------------------
Date: Wed, 21 Dec 2011 12:03:51 -0800 (PST)
From: Ted Byers <r.ted.byers@gmail.com>
Subject: Session termination using use CGI::Session; redirection tot eh login page doesn't yet work
Message-Id: <d667f66d-a473-4945-95a8-4b3d06caff63@h3g2000yqa.googlegroups.com>
I finally figured out how to clear the session created using:
my $session = CGI::Session->new('driver:mysql',$query,{ DataSource =>
'dbi:mysql:profitorius',
User =>
'yyyyyyy',
Password =>
'xxxxxxx'});
To do so, I am using:
$session->clear('CGISESSID');
$session->delete();
$session->flush();
my $scriptname = $query->url(-path=>1);
$scriptname =~ s/cgi-bin\/logout\.pl/login\.html/;
print $query->redirect(-location=>"$scriptname",-status=302);
#print $session->header(-location=>$scriptname);
When I do this, the session info goes away, but nothing I do has had
the effect of redirecting the user to the login page. How do I get
this to redirect to the login page?
Thanks
Ted
------------------------------
Date: Mon, 19 Dec 2011 16:04:38 +0000
From: Rui Maciel <rui.maciel@gmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <jcoje3$qhc$1@speranza.aioe.org>
Antony Scriven wrote:
> 1) Why?
> 2) Newlines are also valid within a CSV field. Use a proper parser.
The CSV format isn't formally defined and generally consists of a series of
lines, each one comprised by set of fields separated by a comma and
terminated by an end-of-line symbol. This means that newlines are not
valid within a CSV field in some implementations. From the example which
was presented by CC, it doesn't appear that his CSV documents includes any
end-of-line symbol in any field.
Regarding your suggestion to use a "proper parser", I believe we can agree
that it would be a bit excessive for this application. After all, the
purpose of this thread is to help someone "massage" a text file in order to
tweak the file format, which would be a "one in a lifetime" thing.
Rui Maciel
------------------------------
Date: Mon, 19 Dec 2011 23:37:52 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <8739cf7t9b.fsf@new.chromatico.net>
>>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:
JE> Oh, come on! For the first time in his life he discovered a
JE> feature that distinguishes a real editor from a toy and you
JE> chastise him? Cut the guy some slack, at some point we were
JE> young and inexperienced, too.
Most people grow out of it. Some people manage to remain inexperienced,
if not young, for decades. The OP has a long posting history here.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Tue, 20 Dec 2011 06:16:26 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: vi regex to preserve interior commas in CSV string
Message-Id: <1d163488-b320-41f7-889b-f54277937c25@x7g2000yqb.googlegroups.com>
On Dec 18, 3:26=A0pm, Antony Scriven <adscri...@gmail.com> wrote:
> And why does it have to be *one* regexp? --Antony
Because I can do it in three steps. I just wondered if it could be
done in one step.
I found this question interesting: how to replace a character except
when it appears between two characters. I feel reasonably sure that it
can be done in one statement, but I don't know what that statement is.
CC.
------------------------------
Date: Wed, 21 Dec 2011 10:08:23 -0800
From: "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>
Subject: Why doesn't this work?
Message-Id: <mt74f75nrtlnjitn9e6s42a0sqkee8dcvt@4ax.com>
When I submit the list of files to this [abbreviated] script for
uploading, instead of receiving a real-time list of files being uploaded,
I get nothing until the entire list of files has been uploaded, and then
the HTML page pops up (with the correct list shown).
HTML header
print "</head><body>\n";
print "<div >\n";
file_upload();
print "</div>\n";
print "</body></html>\n";
sub file_upload() {
@uploadFiles = param('myFile0[]');
for (my $i=0;$i<$imgCnt;$i++) {
my $j = $i+1;
$filename = $uploadFiles[$i];
$filename =~ s/.*[\/\\](.*)/$1/;
print "Uploading image $j : $filename<br>\n";
$upload_filehandle = $query->upload($uploadFiles[$i]);
open (UPLOADFILE, ">$filePathNew/$filename") or die "Can't Open
$filename: $!";
binmode UPLOADFILE;
while (<$upload_filehandle>) {
print UPLOADFILE;
}
} #end of for i
close UPLOADFILE or die "Can't Close. $!";
}
--
Joey
------------------------------
Date: Wed, 21 Dec 2011 18:13:58 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: Why doesn't this work?
Message-Id: <slrnjf48f6.23c3.willem@toad.stack.nl>
Joey@still_Learning.invalid wrote:
) When I submit the list of files to this [abbreviated] script for
) uploading, instead of receiving a real-time list of files being uploaded,
) I get nothing until the entire list of files has been uploaded, and then
) the HTML page pops up (with the correct list shown).
Have you tried it in different browsers?
Have you played around with the browser settings?
Have you looked at it with a browser-based debugger?
Have you looked at the HTTP traffic with a protocol sniffer?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Wed, 21 Dec 2011 18:17:42 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Why doesn't this work?
Message-Id: <87d3bhdc1l.fsf@sapphire.mobileactivedefense.com>
"Joey@still_Learning.invalid" <Joey@still_Learning.invalid> writes:
> When I submit the list of files to this [abbreviated] script for
> uploading, instead of receiving a real-time list of files being uploaded,
> I get nothing until the entire list of files has been uploaded, and then
> the HTML page pops up (with the correct list shown).
>
> HTML header
> print "</head><body>\n";
> print "<div >\n";
> file_upload();
> print "</div>\n";
> print "</body></html>\n";
>
> sub file_upload() {
> @uploadFiles = param('myFile0[]');
> for (my $i=0;$i<$imgCnt;$i++) {
> my $j = $i+1;
> $filename = $uploadFiles[$i];
> $filename =~ s/.*[\/\\](.*)/$1/;
> print "Uploading image $j : $filename<br>\n";
> $upload_filehandle = $query->upload($uploadFiles[$i]);
> open (UPLOADFILE, ">$filePathNew/$filename") or die "Can't Open
> $filename: $!";
> binmode UPLOADFILE;
> while (<$upload_filehandle>) {
> print UPLOADFILE;
> }
> } #end of for i
> close UPLOADFILE or die "Can't Close. $!";
> }
The output is very likely being cached until the script ran to
completion. Also, I'm pretty certain that generating HTML
piece-by-piece in this way and expecting a browser to render
subsequently more complete versions of an invalid HTML document
won't work, at least not universally.
------------------------------
Date: Wed, 21 Dec 2011 10:22:18 -0800
From: "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>
Subject: Re: Why doesn't this work?
Message-Id: <uk84f75gj5svs5bmhg6v6k7c43rr9ouhrh@4ax.com>
Willem wrote:
>Joey@still_Learning.invalid wrote:
>) When I submit the list of files to this [abbreviated] script for
>) uploading, instead of receiving a real-time list of files being uploaded,
>) I get nothing until the entire list of files has been uploaded, and then
>) the HTML page pops up (with the correct list shown).
>
>Have you tried it in different browsers?
I've tried it in two browsers (Opera 12 and FF) with the same result.
>Have you played around with the browser settings?
I don't know what browser settings would have an effect.
>Have you looked at it with a browser-based debugger?
Yes. No hints.
>Have you looked at the HTTP traffic with a protocol sniffer?
>
No, but I can't see how that would tell me anything.
Is it fair for me to presume that it should work as I want, if whatever is
causing it to behave the way it is resolved?
--
Joey
------------------------------
Date: Wed, 21 Dec 2011 11:26:49 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Why doesn't this work?
Message-Id: <211220111126493366%jimsgibson@gmail.com>
In article <mt74f75nrtlnjitn9e6s42a0sqkee8dcvt@4ax.com>,
<"Joey@still_Learning.invalid"> wrote:
> When I submit the list of files to this [abbreviated] script for
> uploading, instead of receiving a real-time list of files being uploaded,
> I get nothing until the entire list of files has been uploaded, and then
> the HTML page pops up (with the correct list shown).
>
That is the way browsers, servers, and HTTP works. Your expectation
that each line output by your CGI program on the server will make its
way quickly to your computer and be rendered in the browser is, alas,
too optimistic. See
<http://www.stonehenge.com/merlyn/LinuxMag/col39.html>
--
Jim Gibson
------------------------------
Date: Wed, 21 Dec 2011 11:28:26 -0800
From: "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>
Subject: Re: Why doesn't this work?
Message-Id: <unc4f75ijhtakjuvlhccpd8n8glsa90170@4ax.com>
Rainer Weikusat wrote:
>"Joey@still_Learning.invalid" <Joey@still_Learning.invalid> writes:
>> When I submit the list of files to this [abbreviated] script for
>> uploading, instead of receiving a real-time list of files being uploaded,
>> I get nothing until the entire list of files has been uploaded, and then
>> the HTML page pops up (with the correct list shown).
>>
>The output is very likely being cached until the script ran to
>completion.
I was afraid of this answer.
>Also, I'm pretty certain that generating HTML
>piece-by-piece in this way and expecting a browser to render
>subsequently more complete versions of an invalid HTML document
>won't work, at least not universally.
I understand, but I don't know why you think the HTML is incomplete.
Regardless, I'm afraid caching is probably the [insurmountable] issue.
--
Joey
------------------------------
Date: Wed, 21 Dec 2011 11:32:19 -0800
From: "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>
Subject: Re: Why doesn't this work?
Message-Id: <n1d4f7d7dmpa1ato8r7pdldahfres2nst7@4ax.com>
Jim Gibson wrote:
>In article <mt74f75nrtlnjitn9e6s42a0sqkee8dcvt@4ax.com>,
><"Joey@still_Learning.invalid"> wrote:
>
>> When I submit the list of files to this [abbreviated] script for
>> uploading, instead of receiving a real-time list of files being uploaded,
>> I get nothing until the entire list of files has been uploaded, and then
>> the HTML page pops up (with the correct list shown).
>>
>
>That is the way browsers, servers, and HTTP works. Your expectation
>that each line output by your CGI program on the server will make its
>way quickly to your computer and be rendered in the browser is, alas,
>too optimistic. See
>
><http://www.stonehenge.com/merlyn/LinuxMag/col39.html>
Ouch. Thanks.
--
Joey
------------------------------
Date: Wed, 21 Dec 2011 12:58:46 -0800
From: Steve May <stevem_@nogood.com>
Subject: Re: Why doesn't this work?
Message-Id: <JOrIq.29601$JE1.13711@newsfe21.iad>
On 12/21/2011 11:28 AM, Joey@still_Learning.invalid wrote:
> Rainer Weikusat wrote:
>
>> "Joey@still_Learning.invalid"<Joey@still_Learning.invalid> writes:
>>> When I submit the list of files to this [abbreviated] script for
>>> uploading, instead of receiving a real-time list of files being uploaded,
>>> I get nothing until the entire list of files has been uploaded, and then
>>> the HTML page pops up (with the correct list shown).
>>>
>> The output is very likely being cached until the script ran to
>> completion.
>
> I was afraid of this answer.
>
>> Also, I'm pretty certain that generating HTML
>> piece-by-piece in this way and expecting a browser to render
>> subsequently more complete versions of an invalid HTML document
>> won't work, at least not universally.
>
> I understand, but I don't know why you think the HTML is incomplete.
> Regardless, I'm afraid caching is probably the [insurmountable] issue.
Browsers need to understand how to lay out the page before they'll start
printing to screen.
With a mime type of text/html, the browser will wait until it knows what
the layout is before printing to screen even when autoflush is true.
The browser (typically) can not accurately calculate layouts until your
html file is fully loaded.
On the other hand, having said all that... some tricks can be played
with the <pre> tag.
I *have* done this before when I was more concerned with the information
content than pretty formatting. I had a system that was creating .rtf
invoices and ran for well over a minute. I wanted a visual on what it
was doing so I came up with a way to do that.
If I recall correctly (been almost 10 years and I don't have a real code
example on this machine) you might try:
HTML header
$| = 1; # <- set OUTPUT_AUTOFLUSH to true
print "</head><body>\n";
#print "<div >\n";# <- lose the divs
print "<pre>\n"; # <- critical bit, tells browser to print as is
file_upload();
print "</pre>\n";
#print "</div>\n";
print "</body></html>\n";
sub file_upload() {
@uploadFiles = param('myFile0[]');
for (my $i=0;$i<$imgCnt;$i++) {
my $j = $i+1;
$filename = $uploadFiles[$i];
$filename =~ s/.*[\/\\](.*)/$1/;
#print "Uploading image $j : $filename<br>\n";
print "Uploading image $j : $filename\n";
$upload_filehandle = $query->upload($uploadFiles[$i]);
open (UPLOADFILE, ">$filePathNew/$filename") or die "Can't Open
$filename: $!";
binmode UPLOADFILE;
while (<$upload_filehandle>) {
print UPLOADFILE;
}
} #end of for i
close UPLOADFILE or die "Can't Close. $!";
}
If THAT doesn't work, send a mime-type of text/plain instead of
text/html and try again...
hth,
\s
------------------------------
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 3572
***************************************
