equivalent

[Dave]

Gang,

I'm looking for an equivalent in perl to the php syntax:

$data = file_get_contents('php://input');

I've read some posts about IO::File::String and LWP::Simple possibly
being used instead of 'file_get_contents'. The php line accepts raw
input and assigns it to a variable. This input is coming from the
output of another script and not a file. If anyone has any ideas or
modules to look into, please feel free to chime in!

Thanks,
Dave

 

[Jürgen Exner]

I'm looking for an equivalent in perl to the php syntax:

$data = file_get_contents('php://input');

I've read some posts about IO::File::String and LWP::Simple possibly
being used instead of 'file_get_contents'. The php line accepts raw
input

I have no idea what raw input is supposed to mean.

and assigns it to a variable. This input is coming from the
output of another script and not a file.

Are your trying to capture the output of another program?

'perldoc -q output':
Why can't I get the output of a command with system()?

There are other ways for special circumstances, too, but in general you
want backticks or qx.

jue

 

[Dave]

I have no idea what raw input is supposed to mean.


Are your trying to capture the output of another program?

'perldoc -q output':
          Why can't I get the output of a command with system()?

There are other ways for special circumstances, too, but in general you
want backticks or qx.

jue

Thanks for the reply, unfortunately backticks and qx are not quite
what I'm looking for. The description for php://input is as follows:

php://input allows you to read raw POST data. It is a less memory
intensive alternative to $HTTP_RAW_POST_DATA and does not need any
special php.ini directives. php://input is not available with
enctype="multipart/form-data".

Do perl have an equivalent for this?

Thanks,
Dave

 

[RedGrittyBrick]

Thanks for the reply, unfortunately backticks and qx are not quite
what I'm looking for. The description for php://input is as follows:

php://input allows you to read raw POST data. It is a less memory
intensive alternative to $HTTP_RAW_POST_DATA and does not need any
special php.ini directives. php://input is not available with
enctype="multipart/form-data".

Do perl have an equivalent for this?

Are you familiar with the CGI module?
Are you hitting out-of memory problems?

 

[Dave]

Are you familiar with the CGI module?
Are you hitting out-of memory problems?

I'm somewhat familiar with the CGI and I'm not getting any out-of
memory problems.

 

[RedGrittyBrick]

I'm somewhat familiar with the CGI and I'm not getting any out-of
memory problems.

Sorry, it isn't clear to me why you don't just use CGI normally?

use strict;
use warnings;
use CGI;
...
my $query = new CGI;
...
my $foo = $query->param('foo');

Are you having some specific problem with this?

 

[Dave]

Sorry, it isn't clear to me why you don't just use CGI normally?

   use strict;
   use warnings;
   use CGI;
   ...
   my $query = new CGI;
   ...
   my $foo = $query->param('foo');

Are you having some specific problem with this?

Because the source is sending raw xml data without normal key/value
pairs (eg xml=...) over an HTTP POST. I think I found that I can use
$data=param('POSTDATA'); instead of the php line from the OP. The
tests so far seem to be right on point. Does anyone know if this is
safe or if there are problems that might arise using this syntax?

Dave

 

[RedGrittyBrick]

Because the source is sending raw xml data without normal key/value
pairs (eg xml=...) over an HTTP POST. I think I found that I can use
$data=param('POSTDATA'); instead of the php line from the OP. The
tests so far seem to be right on point. Does anyone know if this is
safe or if there are problems that might arise using this syntax?

According to the documentation that is the correct function/method to
call for XML payloads such as yours
http://perldoc.perl.org/CGI.html#HANDLING-NON-URLENCODED-ARGUMENTS

I'd feed the resulting $data string into one of Perl's XML parsing
routines to see if it is well-formed. If you have the XML schema, you
can validate your $data against the schema using modules such as
XML::Validator::Schema.

Is this not what you meant by "safe" and "problems"? What sort of safety
do you seek? What sort of problems do you fear? Are you worried about
characters sets and encodings?

 

[Dave]

According to the documentation that is the correct function/method to
call for XML payloads such as yourshttp://perldoc.perl.org/CGI.html#HANDLING-NON-URLENCODED-ARGUMENTS

I'd feed the resulting $data string into one of Perl's XML parsing
routines to see if it is well-formed. If you have the XML schema, you
can validate your $data against the schema using modules such as
XML::Validator::Schema.

Is this not what you meant by "safe" and "problems"? What sort of safety
do you seek? What sort of problems do you fear? Are you worried about
characters sets and encodings?

I guess I was right on the money! I was just interested in
knowing if someone knew of a better way or could provide known issues
with that way of parsing raw data. Thanks for everyones help.

Dave

 

[Dr.Ruud]

my $query = new CGI;

ITYM:

my $cgi = CGI::->new();

 

[Dr.Ruud]

Yes, I did hesitate over that. In the end I copied what is in the
documentation http://perldoc.perl.org/CGI.html#PROGRAMMING-STYLE.

I've actually forgotten the pitfalls of the, er, deprecated syntax.
Perusing perlobj, perlboot and perltoot didn't help me (though I wasn't
very thorough). Is it anything to do with naming your constructor shazam
and writing `my $instance = shazam OddObject'. Though it works,
presumably as intended, I guess that sort of thing can confuse people &
perl?

So, why is `CGI::->new()' preferred over `CGI->new()' preferred over
`new CGI()'?

perl -MData:umper -MCGI -wle'
sub new { die "in new" }
sub CGI { die "in CGI" }
my $cgi = CGI::->new;
print Dumper $cgi;
'

$VAR1 = bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.fieldnames' => {},
'escape' => 1
}, 'CGI' );

 

[sreservoir]

Yes, I did hesitate over that. In the end I copied what is in the
documentation http://perldoc.perl.org/CGI.html#PROGRAMMING-STYLE.

I've actually forgotten the pitfalls of the, er, deprecated syntax.
Perusing perlobj, perlboot and perltoot didn't help me (though I wasn't
very thorough). Is it anything to do with naming your constructor shazam
and writing `my $instance = shazam OddObject'. Though it works,
presumably as intended, I guess that sort of thing can confuse people &
perl?

So, why is `CGI::->new()' preferred over `CGI->new()' preferred over
`new CGI()'?

it isn't, unless someone's stupid enough to make &new or &CGI. it's
just less ambiguous:

new CGI chokes if there is a &new or a &CGI.
CGI->new chokes if there is a &CGI. might do bad things if CGI isn't
require'd or use'd.
'CGI'->new almost always does the right thing.
CGI::->new is syntactic sugar for 'CGI'->new.

actally, foo::bar:: is syntactic sugar for 'foo::bar' except in one
specific case, which usually shouldn't come up.

I use it in tie, mostly.

 

[sreservoir]

Yes, I did hesitate over that. In the end I copied what is in the
documentation http://perldoc.perl.org/CGI.html#PROGRAMMING-STYLE.

I've actually forgotten the pitfalls of the, er, deprecated syntax.
Perusing perlobj, perlboot and perltoot didn't help me (though I
wasn't very thorough). Is it anything to do with naming your
constructor shazam and writing `my $instance = shazam OddObject'.
Though it works, presumably as intended, I guess that sort of thing
can confuse people & perl?

So, why is `CGI::->new()' preferred over `CGI->new()' preferred over
`new CGI()'?

perl -MData:umper -MCGI -wle'
sub new { die "in new" }
sub CGI { die "in CGI" }
my $cgi = CGI::->new;
print Dumper $cgi;
'

$VAR1 = bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.fieldnames' => {},
'escape' => 1
}, 'CGI' );

this is horribly contrived and should never happen. but yes, this is
a case where ::-> is preferred.

 

[Justin C]

Having a 'sub new' in scope is not uncommon:

package Foo;

sub new { ... }

sub init { my $x = CGI->new(...) }

1;


Not if you do it properly, that is

new CGI ();

rather than a bare

new CGI;

The latter is a little too ambiguous even for Perl.


You mean 'if the CGI->new method isn't defined'.


use IO::Handle;
warn "STDOUT"->blocking;

Yes, this is 'the right thing' in this case, but not always. Just don't
open a filehandle called 'CGI'.


For CGI->new, except it ignores any 'sub CGI'.

Ben

Well thanks a whole *huge* bunch, guys. Just when I start thinking I'm
starting to understand what I'm doing you go and confuse the hell out of
me! I spend a lot of my time in this group reading that I should refer
to documentation, and then you go and contradict the damn documentation!
OK, I accept that the module documentation isn't Perl documentation, but
that's a heavily used module, and it says quite clearly (unless I need
to update it):

use CGI;
$q = new CGI;
print $q->header, ....

If you can't explain it to me simply can you point me to some docs... I
see a Catch 22 here.

Justin.

 

[sreservoir]

perl -MData:umper -MCGI -wle'
sub new { die "in new" }
sub CGI { die "in CGI" }
my $cgi = CGI::->new;
print Dumper $cgi;
'

$VAR1 = bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.fieldnames' => {},
'escape' => 1
}, 'CGI' );

this is horribly contrived and should never happen. but yes, this is
a case where ::-> is preferred.

perldoc aliased.

No documentation found for "aliased".

 

[sreservoir]

Having a 'sub new' in scope is not uncommon:

package Foo;

sub new { ... }

sub init { my $x = CGI->new(...) }

1;

I haven't written an OO module for a long time, so this possibility
slipped my mind. however:

% perl -MCGI -E 'sub new { die "wrong new" } say new CGI'
CGI=HASH(0x86f882c)

Not if you do it properly, that is

new CGI ();

rather than a bare

new CGI;

The latter is a little too ambiguous even for Perl.

fair enough. actually, I don't like that much either.

You mean 'if the CGI->new method isn't defined'.

% perl -MCGI -MIO::Handle -E'sub CGI { IO::Handle:: } say CGI->new'
IO::Handle=GLOB(0x9ac1a20)

I mean exactly what I said.

but yes, it will also choke if CGI can't new.

use IO::Handle;
warn "STDOUT"->blocking;

Yes, this is 'the right thing' in this case, but not always. Just don't
open a filehandle called 'CGI'.

"almost"; in any case, none of the others would help you much if you did
have *CGI{IO}.

For CGI->new, except it ignores any 'sub CGI'.

actually, both seem to be syntactic sugar for 'CGI'->, except CGI->
does call a function if it exists.

% perl -MO=Deparse -e 'CGI::->new'
'CGI'->new;
-e syntax OK
% perl -MO=Deparse -e 'CGI->new'
'CGI'->new;
-e syntax OK
% perl -MO=Deparse -e 'new CGI'
'CGI'->new;
-e syntax OK
% perl -MO=Deparse -e 'new CGI ()'
'CGI'->new;
-e syntax OK

 

[sreservoir]

Well, no. It's a CPAN module, quite commonly used in some circles, which
allows you to say

use aliased "Some::Silly::Long::Class::Name" => "SomeClass";

my $x = SomeClass->new;

It works by exporting a 'sub SomeClass' into the current package that
simply returns the string "Some::Silly::Long::Class::Name", and relies
on the fact that Perl will pick a sub over a package for a bareword if
one exists. I find the whole concept makes me uneasy, especially since
once you've said

package Foo;
use aliased "Some::Class" => "SomeClass";

you've effectively stomped on Foo::SomeClass from the point of view of
the rest of the program.

I suppose you could use some caller shenanigans with a closure, but.

sub foo($$) {
my $caller = caller;
my $aliased = shift;
my $package = shift;
*$aliased = sub () {
((caller)->isa($caller))? $package : $aliased;
}
}

of course, I don't understand what is so difficult about:
$this = that::;
$this->foo;

 

[sreservoir]

There is no other possible interpretation for the bareword CGI here. If
you also had a 'sub CGI' you would get new(CGI()) rather than
CGI()->new(). Also, if you were calling 'method $object' rather than
'method Class' and there was a 'sub method' in scope you would get the
sub call.

fair enough.

I was responding to 'might do bad things if...'.

~% perl -e'sub CGI::new { warn "CGI->new" } CGI->new'
CGI->new at -e line 1.

No require or use there. The case where it does make a difference is
(ironically) with the 'new CGI' syntax, where the presence of a 'require
CGI' or 'use CGI' will prime the parser to try and make CGI into a
classname rather than something else.

typically, you shouldn't define stuff int the namespace of a standard
module. contrived counterexample, though, I suppose.

Fair enough; also true. I don't believe there's any way to force
interpretation as a class rather than a filehandle.

this is, incidentally, slightly ridiculous.

% perl -E'sub STDOUT::a { die "right blocking" }
say((*{STDOUT}{PACKAGE})->blocking);'
Can't locate object method "blocking" via package "main" at -e line 2.

um.

Well, both CGI:: and CGI-where-we-expect-a-classname are simply
exceptions to strict 'subs' (which actually prevents barewords from
being treated as unquoted strings, and has nothing to do with subs).
However, CGI->new and "CGI"->new are at least slightly different:

I suppose it should be clarified that I meant it's syntactic sugar only
in the 'suppose it's a classname' case.

~% perl -MO=Concise -e'CGI->new'
7<@> leave[1 ref] vKP/REFC ->(end)
1<0> enter ->2
2<;> nextstate(main 1 -e:1) v:{ ->3
6<1> entersub[t1] vKS/TARG ->7
3<0> pushmark s ->4
4<$> const(PV "CGI") sM/BARE ->5
5<$> method_named(PV "new") ->6
-e syntax OK

~% perl -MO=Concise -e'"CGI"->new'
7<@> leave[1 ref] vKP/REFC ->(end)
1<0> enter ->2
2<;> nextstate(main 1 -e:1) v:{ ->3
6<1> entersub[t1] vKS/TARG ->7
3<0> pushmark s ->4
4<$> const(PV "CGI") sM ->5
5<$> method_named(PV "new") ->6
-e syntax OK

I don't know whether that extra '/BARE' makes any difference, though.

% perl -MO=Concise -e'CGI::->new'
7 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v:{ ->3
6 <1> entersub[t1] vKS/TARG ->7
3 <0> pushmark s ->4
4 <$> const[PV "CGI"] sM/BARE ->5
5 <$> method_named[PV "new"] ->6
-e syntax OK

maybe somebody who mangles the guts of perl can enlighten us?

 

[sreservoir]

Quoth Justin C<[email protected]>:

Method calls like

new Class;
method $object;
method $object @args; # note the lack of comma after $object

are in a form usually called 'indirect object syntax'[0]. This was added
into Perl when objects were first introduced (5.000, I believe),

OP should see the docs section "Indirect Object Syntax" in perlobj.pod.

But it contradicts Ben too:

The other way to invoke a method is by using the so-called "indirect
object" notation. This syntax was available in Perl 4 long before
objects were introduced...

out of curiosity, what did it do in perl4?

 

[RedGrittyBrick]

Well thanks a whole *huge* bunch, guys. Just when I start thinking I'm
starting to understand what I'm doing you go and confuse the hell out of
me! I spend a lot of my time in this group reading that I should refer
to documentation, and then you go and contradict the damn documentation!
OK, I accept that the module documentation isn't Perl documentation, but
that's a heavily used module, and it says quite clearly (unless I need
to update it):

use CGI;
$q = new CGI;
print $q->header, ....

If you can't explain it to me simply can you point me to some docs... I
see a Catch 22 here.

---------------------------8<----------------------
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use Data:umper;

foo();

sub CGI { print "Subroutine 'CGI' called\n"; }
sub new { print "Subroutine 'new' called\n"; }
sub foo {
my $query;
$query = new CGI; print Dumper(\$query);
$query = 'CGI'->new; print Dumper(\$query);
$query = CGI::->new; print Dumper(\$query);
$query = CGI->new; print Dumper(\$query);
}
---------------------------8<----------------------
:!perl testnew.pl
Subroutine 'CGI' called
Subroutine 'new' called
$VAR1 = \'1';
$VAR1 = \bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.fieldnames' => {}
}, 'CGI' );
$VAR1 = \bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.fieldnames' => {}
}, 'CGI' );
Subroutine 'CGI' called
Can't call method "new" without a package or object reference at
testnew.pl line 16.