[27799] in Perl-Users-Digest
Perl-Users Digest, Issue: 9163 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Apr 16 14:05:47 2006
Date: Sun, 16 Apr 2006 11:05:03 -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 Sun, 16 Apr 2006 Volume: 10 Number: 9163
Today's topics:
Re: Assignment of var without escape/interpolation <mtbr0228AT@sbcglobalDOT.net>
Re: existence and size of client file <no@thanks.com>
Re: existence and size of client file <no@thanks.com>
Re: existence and size of client file <no@thanks.com>
Re: existence and size of client file <no@thanks.com>
Re: existence and size of client file <hjp-usenet2@hjp.at>
PhpWiki to Mediawiki converter in php or perl? <news1234@free.fr>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 16 Apr 2006 07:54:08 GMT
From: Alan_C <mtbr0228AT@sbcglobalDOT.net>
Subject: Re: Assignment of var without escape/interpolation
Message-Id: <878xq6eyxq.fsf@AB60R.localdomain>
"Jürgen Exner" <jurgenex@hotmail.com> writes:
> Bart Van der Donck wrote:
> > [ . . ]
[ . . ]
> > [ . . ]
> > [ . . ] I'ld
> > rather state "Interpolations occur inside assignments if double quotes
> > are used to perform the assignment".
I get the same end or printed output result in the next using either single
or double quotes. And, assignment is involved.
#!/usr/bin/perl
use warnings;
use strict;
my $bar = "a";
# my $foo = "bc$bar";
# either of next 2 prints: bca
# my $foo = "bc" . $bar;
my $foo = 'bc' . $bar;
print $foo, "\n";
I agree with the logic/example about the + sign ie since the + does
it, it's naturally follows that when assigned if + is used that
addition occurs.
Double quotes interpolates but (I guess) an operator can as well under
certain circumstance -- like my code above, the concatenation operator.
The word context is coming up for me. I'm guessing here that context has
to do with it (I could be wrong). But it seems that in the context of
the operation (concatenation operator) that it knows to combine the bc
string with the *content* of the $bar scalar variable.
--
Alan.
------------------------------
Date: Sun, 16 Apr 2006 14:01:35 +0200
From: Asterbing <no@thanks.com>
Subject: Re: existence and size of client file
Message-Id: <MPG.1eaae7d144dc6fb39897f0@news.tiscali.fr>
In article <qyX%f.93$JY5.55@trnddc01>, jurgenex@hotmail.com says...
> Ok, then to answer your particular question: No, the programming language
> Perl does not know anything at all about HTTP or CGI. Nothing, nada, zilch,
> rien. Absolutely nothing. Had you checked "perldoc perlfunc" you probably
> would have noticed that yourself.
>
Oh, merci, thanks, spassiba, danke. Then, I'll surely have to check $ENV
{'CONTENT_LENGTH'} after form POSTing, then parse to find data and read
toward buffer before to write in a new file server target... All of this
without any line of Perl code even if my first line is "#!/usr/bin/perl
-T".
Huuuu, what a difficult thing :-)
------------------------------
Date: Sun, 16 Apr 2006 14:07:16 +0200
From: Asterbing <no@thanks.com>
Subject: Re: existence and size of client file
Message-Id: <MPG.1eac51daf56bc0079897f1@news.tiscali.fr>
In article <lbmdnb-ZwbFuxdzZnZ2dnUVZ_sydnZ2d@comcast.com>, joe@inwap.com
says...
> Your problem requires a change to the client's behavior, such as by
> forcing the end user to download an unsigned plugin and executing it.
> You're not expecting that to happen, are you?
>
Understood :-(
------------------------------
Date: Sun, 16 Apr 2006 14:08:56 +0200
From: Asterbing <no@thanks.com>
Subject: Re: existence and size of client file
Message-Id: <MPG.1eac52454e5ac2a09897f2@news.tiscali.fr>
In article <3qqdnTP9wK4AytzZRVn-uQ@comcast.com>, joe@inwap.com says...
> Let me reiterate: Under your control is the HTML that you send
> to provide a FORM to the client. You have control of what gets
> executed after the POST request reaches your server. You do not
> have control of what happens in between. The behavior of code
> running on the client depends on the software that is installed
> on the client, and you do not have control over that.
>
OK :-( Thus, even if I'm checking content-length, data file has already
been sent : right ?
------------------------------
Date: Sun, 16 Apr 2006 14:12:26 +0200
From: Asterbing <no@thanks.com>
Subject: Re: existence and size of client file
Message-Id: <MPG.1eac531511c1d8879897f3@news.tiscali.fr>
In article <UMCdnZS_OZ55xtzZRVn-pQ@comcast.com>, joe@inwap.com says...
> No. If your intent is to prevent a POST from even being started when
> the file size is too big, CGI.pm won't help. That problem is
> impossible to solve in the given problem arena.
>
Yes, it was, after refexion, what I expected. It's a pity !
------------------------------
Date: Sun, 16 Apr 2006 16:25:24 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: existence and size of client file
Message-Id: <l4kt1e.jae.ln@teal.hjp.at>
Asterbing wrote:
> In article <3qqdnTP9wK4AytzZRVn-uQ@comcast.com>, joe@inwap.com says...
>> Let me reiterate: Under your control is the HTML that you send
>> to provide a FORM to the client. You have control of what gets
>> executed after the POST request reaches your server. You do not
>> have control of what happens in between. The behavior of code
>> running on the client depends on the software that is installed
>> on the client, and you do not have control over that.
>>
>
> OK :-( Thus, even if I'm checking content-length, data file has
> already been sent : right ?
Maybe, maybe not. It depends on your web server, the speed of the
connection between the client and the server, and maybe some other
things.
The client sends an HTTP POST request, which contains the URL, the
Content-Type and the Content-Length in the header and the data file(s)
as well as any other form data in the body.
The server receives the request and has to read the header to know what
to do with the request and to fill in various environment variables
before invoking the CGI script.
Then the server has inkove the CGI script so that the CGI script can
read the body from STDIN. There are (at least) three ways to do that:
1) if the server has read *only* the header (which is difficult to
ensure in a efficient manner) it can simply pass the open socket to
the script.
2) It can also set up a pair of pipes or a socket to the script and send
everything it gets from the client to the script and vice versa.
3) Finally, it could read the rest of the body, save it to a temporary
file and invoke the script with stdin redirected to that file.
I believe most web servers use option 2 or maybe 1 with some trickery.
In these cases, the script is invoked as soon as the web server has
received and parsed the header of the request. For a large request, this
means that most of the content has not yet been sent by the client.
So theoretically, your script can just look at $ENV{HTTP_CONTENT_LENGTH}
before reading anything and - if it decides that the content length is
too long to process - send back an error message and exit.
With option 2, the web server may still read the rest of the request and
discard it. Or it may pass the output from the script to the client and
close the connection. In this case the client will notice that the
connection is broken and stop uploading. So you save some bandwidth.
However, if you do that, be sure to test it thoroughly with as many
browsers as possible. Some may display the message you sent back. Some
may additionally display a message that the connection was broken. Some
may only display this message and discard yours. Some may even retry the
upload automatically (early Mozilla versions used to do this).
None of this has anything to do with perl, of course.
hp
--
_ | Peter J. Holzer | Löschung von at.usenet.schmankerl?
|_|_) | Sysadmin WSR/LUGA |
| | | hjp@hjp.at | Diskussion derzeit in at.usenet.gruppen
__/ | http://www.hjp.at/ |
------------------------------
Date: Sun, 16 Apr 2006 18:13:43 +0200
From: news reader <news1234@free.fr>
Subject: PhpWiki to Mediawiki converter in php or perl?
Message-Id: <44426d2e$0$18262$636a55ce@news.free.fr>
Hi,
I'm looknig for advice / inspiration / modules / libraries, that could help.
I'm a little more fluent in perl, but a php solution would also be fine.
I'm having two Wiki servers:
Server1:
- phpwiki with user authentication
- direct access to the mysql data base possible
- contains about 400 entries
Server1:
- MediaWiki (Wikipedia is Mediawiki based) with user authentification
- direct access to the mysql data base possible
- contains about 30 entries
I'd like to copy over about 350 entries from Server1 to Server2(I could
apply a filter rule or semiautomatically create a list with entries to copy
As the amount of entries is low I don't really need an optimized solution.
Entries in server 2 can be overwritten.
I wanted to have your advice:
1.) Is there already something similiar, that exists?
2.) Is there a Wikiadmin focused news group (I don't like mailing lists
and web based forums, as you have to create a noew account for most of
them or to increase your spam rate even more) ?
If not:
I know very little about the wiki internals and was thinking about a
'brute force' method, not knowing if something better exists:
The idea:
1.) get all the entries from the phpWiki via mysql ( from table "wiki" )
2.) fix naming style (my phpwiki entries contain spaces)
3.) replace the phpWiki syntax with Mediawiki syntax (I found url with
some sed rules, which are probably incomplete, but could be a goiod
starting point) and fix naming styles of interlnal links.
4.) access the Mediawiki via http, authenticate and post the new entries
My idea was to 'post' new entries though it is probaly slower than
directly populating the mysql data base as this allows to populate
Mediawiki without having to know how the internal mysql book keeping
works exactly.
thanks in advance for any ideas and bye
N
P.S. I posted to comp.lang.php and comp.lang.perl.misc but thought, that
cross posting may not be a good idea as probaly most follow ups will be
very language specific.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9163
***************************************
