[32468] in Perl-Users-Digest
Perl-Users Digest, Issue: 3734 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 11 18:09:20 2012
Date: Wed, 11 Jul 2012 15:09:06 -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 Wed, 11 Jul 2012 Volume: 11 Number: 3734
Today's topics:
Re: Making CGI.pm forget <cartercc@gmail.com>
Re: Making CGI.pm forget <ben@morrow.me.uk>
Output buffering on IIS7 <brillisoft@gmail.com>
Re: Output buffering on IIS7 <ben@morrow.me.uk>
Re: Output buffering on IIS7 brillisoft@gmail.com
Re: Output buffering on IIS7 brillisoft@gmail.com
Re: Output buffering on IIS7 brillisoft@gmail.com
Re: Output buffering on IIS7 brillisoft@gmail.com
Re: Output buffering on IIS7 <veatchla@yahoo.com>
Re: Output buffering on IIS7 brillisoft@gmail.com
Re: Output buffering on IIS7 <ben@morrow.me.uk>
Re: Perl 5.14 Windows Strawberry Perl 64 bits brillisoft@gmail.com
Re: question concerning pipes and large strings <rweikusat@mssgmbh.com>
Re: question concerning pipes and large strings brillisoft@gmail.com
Re: question concerning pipes and large strings (Seymour J.)
Traversing folders <dirk.devos@usa.net>
Re: Traversing folders <rweikusat@mssgmbh.com>
Re: Traversing folders <news@lawshouse.org>
Re: Traversing folders <ben@morrow.me.uk>
Updating greymausg@mail.com
Re: Updating <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 11 Jul 2012 13:37:57 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Making CGI.pm forget
Message-Id: <ebff1467-21f0-4211-a160-bba165ea6816@w6g2000yqg.googlegroups.com>
On Jun 19, 11:51=A0am, Bernie Cosell <ber...@fantasyfarm.com> wrote:
> One aspect of CGI.pm that I've never liked is that it tries to 'remember'
> form variables from one page to the next --- and worse makes it hard to
> change a value, preferring to ignore your attempts to change the value an=
d
> keep the old one unless you go to some bother. =A0I *hate* this behavior =
and,
> basically, always want to build my forms exactly as I want them [and,
> indeed, generally prefer sessions to provide continuity from one form to
> the next rather than larding up each form].
My first reaction to your code was to wonder why you didn't explicitly
set the value of the variables you use to generate your form elements.
Different strokes for different folks. I write CGI scripts pretty
often, and usually force my form variables to initialize to some
value, even if it's only "" (blank value). I do a lot of displaying
values from a database, and the mental template I use expects the
widget to have some value. This way, I never have to think about the
sticky/nonsticky behavior, i.e., I make sure that the value of each
variable I use in the HTML is set to what I want it to be set to
before I sent it to the client.
I have a pronounced distaste for client side validation, and never use
it. It's more work to validate the query parameters client side
perhaps, but I can control the values and that makes me happy.
I also have a pronounced distaste for cookies, and do all my session
validation server side. This is more work, but it allows me to track
the details of what a user does in each session. I typically stuff all
my query parameters in a database, and query the database with each
HTTP request.
My philosophy is to strictly control what the client sees, and to
distrust everything I receive from the client. I haven't had any
problems in a long time, at least that I know about.
CC.
------------------------------
Date: Wed, 11 Jul 2012 22:59:00 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Making CGI.pm forget
Message-Id: <4i91d9-btk1.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
>
> I have a pronounced distaste for client side validation, and never use
> it. It's more work to validate the query parameters client side
> perhaps, but I can control the values and that makes me happy.
Client-side validation can be a useful optimisation, in that you can
give the user a more helpful error message sooner than you could
otherwise, but it must never be relied on. Even if you were to validate
the data client-side, you would have to do it again server-side to guard
against clients which manage to subvert the validation code.
> I also have a pronounced distaste for cookies, and do all my session
> validation server side. This is more work, but it allows me to track
> the details of what a user does in each session. I typically stuff all
> my query parameters in a database, and query the database with each
> HTTP request.
It would not be normal to put significant amounts of data in cookies:
usually you would just put a session ID, and keep the important data in
a database. The only real advantage of cookies is that they give you a
way of tracking sessions across ordinary (non-form) requests.
> My philosophy is to strictly control what the client sees, and to
> distrust everything I receive from the client. I haven't had any
> problems in a long time, at least that I know about.
That is an extremely sensible approach.
Ben
------------------------------
Date: Sun, 8 Jul 2012 11:49:37 -0700 (PDT)
From: David Hiskiyahu <brillisoft@gmail.com>
Subject: Output buffering on IIS7
Message-Id: <8e7774a2-fe00-4ea2-bff2-550dcb299184@googlegroups.com>
I moved a rather simple program from an IIS 5.x that was running under ActivePerl on an old Win2000 32 bits machine to an IIS7 server running under ActivePerl 12.x on a new Windows 2008 64 bits server.
In the old place, the program would visit a number of databases in a loop, grab some data from each database, print it and go on to the next one.
$|=1 is obviously set in the beginning to let the data flush out.
While all was fine on the old server, the program just does not want to flush in the new place .. it only shows the first byte of output when it finishes running the entire code.
Looked at IIS7 settings, disabled Output Caching.
Disabled compression.
.. still the same.
The output is delayed and starts to show only when the entire script finishes running.
Any clues, please?
------------------------------
Date: Sun, 8 Jul 2012 22:32:55 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Output buffering on IIS7
Message-Id: <7tapc9-uhi2.ln1@anubis.morrow.me.uk>
Quoth David Hiskiyahu <brillisoft@gmail.com>:
> I moved a rather simple program from an IIS 5.x that was running under
> ActivePerl on an old Win2000 32 bits machine to an IIS7 server running
> under ActivePerl 12.x on a new Windows 2008 64 bits server.
Do you mean 5.12.x?
> In the old place, the program would visit a number of databases in a
> loop, grab some data from each database, print it and go on to the next
> one.
>
> $|=1 is obviously set in the beginning to let the data flush out.
>
> While all was fine on the old server, the program just does not want to
> flush in the new place .. it only shows the first byte of output when it
> finishes running the entire code.
>
> Looked at IIS7 settings, disabled Output Caching.
> Disabled compression.
>
> .. still the same.
> The output is delayed and starts to show only when the entire script
> finishes running.
How is the script being run (CGI, FCGI, PerlScript, ...)? What happens
if you run it from the command line? Can you try it with a different web
server?
Take the script and cut as much of it out as you can without making the
problem go away. If this doesn't make the problem apparent, post what's
left. (Something really simple like 'print "foo"; sleep 5' might be a
good place to start.)
Ben
------------------------------
Date: Mon, 9 Jul 2012 02:30:55 -0700 (PDT)
From: brillisoft@gmail.com
Subject: Re: Output buffering on IIS7
Message-Id: <e278d6d5-ed01-468d-911a-cc55241b2f58@googlegroups.com>
Ben, thanks for your prompt reply.
5.12.x is right .. my typo.
And yes, I did exactly that when I saw that I am fighting a buffering issue=
- made a mini-script that does a bit of sleeping and printing in a loop, m=
ore is not needed - and posted here when I saw that the problem is exactly =
that and not some of my script logic.
The old server prints a row every second.
The new server waits 5 seconds then prints all:
#!/usr/bin/perl=20
use CGI qw/:standard/;
select((select(STDOUT), $| =3D 1)[0]);
print header, start_html(-title =3D> 'test.pl page', -bgcolor =3D> '#fffff=
f');=20
print "<P>TEST BEGIN\n";
print "<br>Going to sleep 5 seconds\n";
sleep 1; print "<br>Slept 1 second\n";
sleep 1; print "<br>Slept 1 more second, 2 seconds so far\n";
sleep 1; print "<br>Slept 1 more second, 3 seconds so far\n";
sleep 1; print "<br>Slept 1 more second, 4 seconds so far\n";
sleep 1; print "<br>Slept 1 more second, 5 seconds so far\n";
print "<p>TEST END<p><hr>\n";
print end_html();
------------------------------
Date: Mon, 9 Jul 2012 02:33:07 -0700 (PDT)
From: brillisoft@gmail.com
Subject: Re: Output buffering on IIS7
Message-Id: <8130b3b3-bcbb-47ae-b008-e21fce15ae5f@googlegroups.com>
And it is CGI.
------------------------------
Date: Mon, 9 Jul 2012 02:49:51 -0700 (PDT)
From: brillisoft@gmail.com
Subject: Re: Output buffering on IIS7
Message-Id: <7b853307-1fa9-4e44-8cba-d7bae42f2470@googlegroups.com>
The script sleeps and prints as expected when running from a black DOS window in command mode .. so it is surely not Perl that delays the print.
Must be something in the IIS7 Web Server settings.
------------------------------
Date: Tue, 10 Jul 2012 03:21:07 -0700 (PDT)
From: brillisoft@gmail.com
Subject: Re: Output buffering on IIS7
Message-Id: <8f0f9821-889d-471d-88e2-850132082c61@googlegroups.com>
Same exactly is happening with a similar PHP script, which probably means
that my thread should be kicked out of here ..:
<?php
Print "<br>Hello, World! \n";
flush();
$sleep = 2;
flush();
echo date('h:i:s') . " - going to sleep $sleep seconds now!\n";
flush();
sleep($sleep);
Print "<br>Hello again! \n";
flush();
sleep($sleep);
echo date('h:i:s') . " - going to sleep $sleep more seconds now!\n";
flush();
Print "<br>OK, slept enough.\n";
flush();
$myFile = "hello.php";
$fh = fopen($myFile, 'r');
$source = fread($fh, filesize($myFile));
$source = htmlspecialchars($source);
print "<p><hr>Here is the code of this program:<pre>\n";
echo $source;
flush();
?>
------------------------------
Date: Tue, 10 Jul 2012 21:07:55 -0500
From: l v <veatchla@yahoo.com>
Subject: Re: Output buffering on IIS7
Message-Id: <jtin5n$r8q$1@dont-email.me>
On 7/9/2012 4:30 AM, brillisoft@gmail.com wrote:
> Ben, thanks for your prompt reply.
> 5.12.x is right .. my typo.
>
> And yes, I did exactly that when I saw that I am fighting a buffering issue - made a mini-script that does a bit of sleeping and printing in a loop, more is not needed - and posted here when I saw that the problem is exactly that and not some of my script logic.
>
> The old server prints a row every second.
> The new server waits 5 seconds then prints all:
>
> #!/usr/bin/perl
> use CGI qw/:standard/;
>
> select((select(STDOUT), $| = 1)[0]);
>
> print header, start_html(-title => 'test.pl page', -bgcolor => '#ffffff');
>
> print "<P>TEST BEGIN\n";
> print "<br>Going to sleep 5 seconds\n";
>
> sleep 1; print "<br>Slept 1 second\n";
> sleep 1; print "<br>Slept 1 more second, 2 seconds so far\n";
> sleep 1; print "<br>Slept 1 more second, 3 seconds so far\n";
> sleep 1; print "<br>Slept 1 more second, 4 seconds so far\n";
> sleep 1; print "<br>Slept 1 more second, 5 seconds so far\n";
>
> print "<p>TEST END<p><hr>\n";
>
> print end_html();
Install Fiddler2 on your PC and enable it under IE's Tool menu. This
will allow you to trace the http traffic. If I recall correctly, IIS7
recognizes the browser type and behaves differently. IIS5 does not
perform this browser check.
I do not remember if there is a solution - I was investigating a
different problem when my company was upgrading from IE6 to IE7.
--
Len
------------------------------
Date: Wed, 11 Jul 2012 01:58:03 -0700 (PDT)
From: brillisoft@gmail.com
Subject: Re: Output buffering on IIS7
Message-Id: <23038ab9-af17-416e-a100-28e32eef06fe@googlegroups.com>
Len, thanks for the tip .. Fiddler is great!
As for this specific issue I am investigating, Fiddler2 confirms that there is no buffering inside the browser.
The ServerGotRequest and ServerBeginResponse timestamps prove that the buffering occurs on the server side.
So .. back to square 1, IIS7 is buffering output of my scripts, be them PHP or Perl, in same way .. regardless the explicit output flushing that is coded in the scripts, and I do not see how to stop that buffering.
------------------------------
Date: Wed, 11 Jul 2012 13:04:10 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Output buffering on IIS7
Message-Id: <qm60d9-k5g1.ln1@anubis.morrow.me.uk>
Quoth brillisoft@gmail.com:
>
> So .. back to square 1, IIS7 is buffering output of my scripts, be them
> PHP or Perl, in same way .. regardless the explicit output flushing that
> is coded in the scripts, and I do not see how to stop that buffering.
Get a real web server?
Ben
------------------------------
Date: Sun, 8 Jul 2012 12:28:50 -0700 (PDT)
From: brillisoft@gmail.com
Subject: Re: Perl 5.14 Windows Strawberry Perl 64 bits
Message-Id: <ad5f3003-692b-4ae2-b1ce-afa437b08099@googlegroups.com>
When I had a similar trouble finding a module, and it was BDB::MySQL then, I just stepped back to ActivePerl 12.x ...
------------------------------
Date: Sun, 08 Jul 2012 20:33:06 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: question concerning pipes and large strings
Message-Id: <87sjd259ql.fsf@sapphire.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Fri, 22 Jun 2012 18:29:07 +0100, Rainer Weikusat wrote:
>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>> On Thu, 21 Jun 2012 23:11:55 +0100, Rainer Weikusat wrote:
[...]
>>> What is more valuable, your time or computer time?
>>
>> Depending on how you look at it, my time is either infinitely more
>> valuable than computer time
[...]
>> or infinitely less> valuable (People will pay in order to use computer time to solve
[...]
>> Seems you question doesn't really make sense ...
>
> I think you just answered the question... :-)
I don't think so. On its own, 'my time' has some value to me and even
this only insofar I can make some productive use of it.
> But the context is of course one of efficiency. To put it to extremes,
> should you put in a few hours work to shave of a few milliseconds
> runtime? If you work in realtiome systems the answer might be a definate
> yes. Otherwise it more often than not should be no. Unless your hobby is
> making programs run as efficient as possible.
'A realtime system' is the classic example for something which is
either 'fast enough' (capable of operating within the time constraints
associated with a given problem). In this case, making it work faster
offers no benefit. Or it is not fast enough. And then, it is entirely
unusable.
As with the 'your time versus computer time' issue, the question is
ill-defined. In order to answer it, at least the following pieces of
additional information are necessary: How large is the benefit
achieved in this way compared to the total runtime? How often is the
code going to be executed and/or how many instances of it will be
executed concurrently?
------------------------------
Date: Sun, 8 Jul 2012 12:53:07 -0700 (PDT)
From: brillisoft@gmail.com
Subject: Re: question concerning pipes and large strings
Message-Id: <5b8c1d80-0a22-402b-99fd-5ee0f6737e1f@googlegroups.com>
Let's roll back to the beginning of the process - if that is feasible, and maybe redesign the process?
How is this file created in the first place?
Whatever logic creates it - could that logic store a lighter mirror file with just the IDs and positions of the ids and the text in the large file?
Then that lighter file could be used as a kind of index of the large file.
Or .. maybe the whole thing could sit in a database in the first place?
------------------------------
Date: Mon, 09 Jul 2012 06:58:23 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: question concerning pipes and large strings
Message-Id: <4ffab94f$5$fuzhry+tra$mr2ice@news.patriot.net>
In <87sjd259ql.fsf@sapphire.mobileactivedefense.com>, on 07/08/2012
at 08:33 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>'A realtime system' is the classic example for something which is
>either 'fast enough' (capable of operating within the time
>constraints associated with a given problem). In this case, making it
>work faster offers no benefit. Or it is not fast enough. And then, it
>is entirely unusable.
Close but no cigar. Spare capacity is an issue in real time systems
because the workload grows if the business is successful. It's less
expensive to add, e.g., sensors, to an existing system than to buy and
maintain an additional system. The Devil is in the details.
--
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, 11 Jul 2012 08:40:59 -0700 (PDT)
From: Dirk <dirk.devos@usa.net>
Subject: Traversing folders
Message-Id: <0584f12e-d335-441b-9b20-715f12c7ccfa@googlegroups.com>
Hi,
I am new to Perl and I am trying to list all the folders within a given folder and I have the following code. I know it is simple but for some reason the program just stops and I am not seeing any error code being returned.
Does anybody have a good example of File::Find that they are willing to share. Examples are easier for me to follow.
#!/usr/bin/perl
#
use warnings;
use strict;
use File::Find;
my $path_name;
$path_name = '/test';
find sub {
return unless -d;
print "$File::Find::name\n";
},$path_name;
exit;
------------------------------
Date: Wed, 11 Jul 2012 16:56:11 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Traversing folders
Message-Id: <87fw8yjnqc.fsf@sapphire.mobileactivedefense.com>
Dirk <dirk.devos@usa.net> writes:
> I am new to Perl and I am trying to list all the folders within a
> given folder and I have the following code. I know it is simple but
> for some reason the program just stops and I am not seeing any error
> code being returned.
[...]
> #!/usr/bin/perl
> #
>
> use warnings;
> use strict;
> use File::Find;
>
> my $path_name;
> $path_name = '/test';
>
> find sub {
> return unless -d;
> print "$File::Find::name\n";
> },$path_name;
>
> exit;
Works for me.
------------------------------
Date: Wed, 11 Jul 2012 22:12:01 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Traversing folders
Message-Id: <nJWdndrXuZK8cWDSnZ2dnUVZ7vidnZ2d@giganews.com>
On 11/07/12 16:40, Dirk wrote:
> Hi,
>
> but for some reason the program just stops and I am not seeing any error code being returned.
Hmm; it works for me. Are you sure you're not getting anything? Does
"/test" exist? (That's the only thing I changed before I ran your code).
Try putting some "print" statements in, to make sure it's running at
all. Or use perl -d.
--
Henry Law Manchester, England
------------------------------
Date: Wed, 11 Jul 2012 22:49:55 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Traversing folders
Message-Id: <3191d9-btk1.ln1@anubis.morrow.me.uk>
Quoth Dirk <dirk.devos@usa.net>:
>
> I am new to Perl and I am trying to list all the folders within a given
> folder and I have the following code. I know it is simple but for some
> reason the program just stops and I am not seeing any error code being
> returned.
>
> Does anybody have a good example of File::Find that they are willing to
> share. Examples are easier for me to follow.
>
>
> #!/usr/bin/perl
> #
>
> use warnings;
> use strict;
> use File::Find;
>
> my $path_name;
> $path_name = '/test';
>
> find sub {
> return unless -d;
> print "$File::Find::name\n";
> },$path_name;
>
> exit;
You don't need to call 'exit' unless you want to exit early, or with an
error code. Falling off the end of a Perl program is the usual way to
exit successfully.
This program works correctly for me, with or without the 'exit'. How
exactly are you invoking it, and what output do you see?
Ben
------------------------------
Date: 10 Jul 2012 11:51:28 GMT
From: greymausg@mail.com
Subject: Updating
Message-Id: <slrnjvo28g.2bd.greymausg@slack.org>
I want to update my Perl. How do I do that and
keep the modules I cpanned down for the present
one?
--
maus
.
.
...
------------------------------
Date: Tue, 10 Jul 2012 22:58:40 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Updating
Message-Id: <g5luc9-5a21.ln1@anubis.morrow.me.uk>
Quoth greymausg@mail.com:
> I want to update my Perl. How do I do that and
> keep the modules I cpanned down for the present
> one?
One way is to use the 'autobundle' command in the CPAN shell.
Ben
------------------------------
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 3734
***************************************
