[32119] in Perl-Users-Digest
Perl-Users Digest, Issue: 3384 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun May 15 14:09:27 2011
Date: Sun, 15 May 2011 11: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 Sun, 15 May 2011 Volume: 11 Number: 3384
Today's topics:
edit_file and edit_file_lines <uri@StemSystems.com>
Re: FAQ 1.5 What was Ponie? <*@eli.users.panix.com>
Re: FAQ 1.5 What was Ponie? <brian.d.foy@gmail.com>
Re: help!!! <rweikusat@mssgmbh.com>
Perl 5.14 Windows Strawberry Perl 64 bits <dilbert1999@gmail.com>
Re: piping a vraiable content through a filter <rweikusat@mssgmbh.com>
Re: piping a vraiable content through a filter <hhr-m@web.de>
Re: piping a vraiable content through a filter <rweikusat@mssgmbh.com>
Re: piping a vraiable content through a filter <jimsgibson@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 15 May 2011 01:32:22 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: edit_file and edit_file_lines
Message-Id: <87aaeosf4p.fsf@quad.sysarch.com>
Have you ever wanted to use perl -pi inside perl? did you have the guts
to localize $^I and @ARGV to do that? now you can do that with a simple
call to edit_file or edit_file_lines in the new .018 release of
File::Slurp. Now you can modify a file in place with a simple call.
edit_file reads a whole file into $_, calls its code block argument and
writes $_ back out the file. These groups are equivalent operations:
perl -0777 -pi -e 's/foo/bar/g' filename
use File::Slurp qw( edit_file ) ;
edit_file { s/foo/bar/g } 'filename' ;
edit_file sub { s/foo/bar/g }, 'filename' ;
edit_file \&replace_foo, 'filename' ;
sub replace_foo { s/foo/bar/g }
edit_file_lines reads a whole file and puts each line into $_, calls its
code block argument and writes each $_ back out the file. These groups are
equivalent operations:
perl -pi -e '$_ = "" if /foo/' filename
use File::Slurp qw( edit_file_lines ) ;
edit_file_lines { $_ = '' if /foo/ } 'filename' ;
edit_file_lines sub { $_ = '' if /foo/ }, 'filename' ;
edit_file \&delete_foo, 'filename' ;
sub delete_foo { $_ = '' if /foo/ }
So now when someone asks for a simple way to modify a file from inside
Perl, you have an easy answer to give them.
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 13 May 2011 21:42:48 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: FAQ 1.5 What was Ponie?
Message-Id: <eli$1105131738@qz.little-neck.ny.us>
[posted and mailed]
In comp.lang.perl.misc, PerlFAQ Server <brian@theperlreview.com> wrote:
> 1.5: What was Ponie?
> Ponie stands for "Perl On the New Internal Engine", started by Arthur
> Bergman from Fotango in 2003, and subsequently run as a project of The
> Perl Foundation. It was abandoned in 2006 (
> http://www.nntp.perl.org/group/perl.ponie.dev/487 ).
Speaking of retring FAQs, a project that lasted maybe three years and
was abandoned five years ago might be a good candidate for no longer
being "frequently" asked.
And even that final "out to pasture" message says "not been in active
development for almost half a year" extending the obsolescence.
Elijah
------
though at least the question is in the past tense
------------------------------
Date: Sat, 14 May 2011 02:03:21 -0300
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 1.5 What was Ponie?
Message-Id: <140520110203219463%brian.d.foy@gmail.com>
In article <eli$1105131738@qz.little-neck.ny.us>, Eli the Bearded
<*@eli.users.panix.com> wrote:
> In comp.lang.perl.misc, PerlFAQ Server <brian@theperlreview.com> wrote:
> > 1.5: What was Ponie?
> Speaking of retring FAQs, a project that lasted maybe three years and
> was abandoned five years ago might be a good candidate for no longer
> being "frequently" asked.
This one should be removed. Thanks,
------------------------------
Date: Fri, 13 May 2011 15:06:49 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: help!!!
Message-Id: <8762pezocm.fsf@sapphire.mobileactivedefense.com>
Ralph Malph <ralph@happydays.com> writes:
> My script isn't working can someone here help me?
Tell your owner to let some vet put you out of your misery.
------------------------------
Date: Sun, 15 May 2011 08:29:57 -0700 (PDT)
From: Dilbert <dilbert1999@gmail.com>
Subject: Perl 5.14 Windows Strawberry Perl 64 bits
Message-Id: <79ad1d90-f984-464b-afb0-c87151ef38fa@j28g2000vbp.googlegroups.com>
Perl 5.14 has been released yesterday (see discussion on perl5.porters
"Perl 5.14.0 is now available" http://groups.google.com/group/perl.perl5.porters/msg/4e952ff85c716c27)
I hope that Perl 5.14 Windows Strawberry Perl 64 bits will be released
soon, I can't wait to test the new features
Here is a summary from the release message on perl5.porters:
>> Some notable changes in this release include:
>>
>> * Unicode 6.0 support, along with many, many improvements
>> to our Unicode-related features
>>
>> * Improved support for IPv6
>>
>> * Significantly easier autoconfiguration of the CPAN client
>>
>> * A new /r flag which makes s/// substitutions non-destructive
>>
>> * New regular expression flags to control whether matched
>> strings should be treated as ASCII or Unicode
>>
>> * New "package Foo { }" syntax
>>
>> * Uses less memory and CPU than previous releases
------------------------------
Date: Fri, 13 May 2011 15:05:47 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: piping a vraiable content through a filter
Message-Id: <87aaeqzoec.fsf@sapphire.mobileactivedefense.com>
Helmut Richter <hhr-m@web.de> writes:
> On Thu, 12 May 2011, Rainer Weikusat wrote:
>> Helmut Richter <hhr-m@web.de> writes:
>>> I have a filter program "filter" which reads from STDIN and writes to
>>> STDOUT. Now I have in a Perl script a variable $filter_in with data
>>> that have to be transformed to $filter_out.
[...]
>> Have a look at IPC::Open3(3pm).
>
> Thanks, this is a valuable hint. There is also
> http://perldoc.perl.org/perlipc.html#Bidirectional-Communication-with-Another-Process
> with a little more explanation.
>
> In my intended application, things are much simpler: there is no real
> two-way communication. The input data is sent once, and the output
> data is received once. Without the buffering problems, things would be
> as simple as
>
> use IPC::Open2;
>
> $stuff = 'x' x $ARGV[0];
>
> $pid = open2($child_out, $child_in, "cat");
> print ($child_in "$stuff");
> close $child_in;
> $got = <$child_out>;
> close $child_out;
>
> print "$ARGV[0]\n";
> if ($stuff eq $got) {
> print "okay\n";
> } else {
> print "wrong\n";
> };
>
> The simple buffered "cat" was chosen deliberately because I do not
> make assumptions on the behaviour of the child process.
>
> Just trying out, things went well as long data was shorter than 135168
> bytes. This is *much* more than what I need. Now there are two ways to
> go on:
>
> - Either enhance the logic of the program that it will work for
> arbitrary length of data.
How about 'fix the broken program in order to make it work'? It might
be possible to determine how many bytes of output the child can write
before it blocks and consequently, how many bytes of input the parent
can write while ignoring the output produced by the child before it is
blocked waiting for the blocked child to read some more data, IOW,
before the whole things deadlocks until the end of electricity but
that's certainly more work than one of the proper solutions, namely:
- 'offline processing': child writes output to a temporary
file, parents reads that after child is done
- 'online processing' parent uses select/ poll to determine
when to do which I/O operation on which handle
------------------------------
Date: Fri, 13 May 2011 18:10:55 +0200
From: Helmut Richter <hhr-m@web.de>
Subject: Re: piping a vraiable content through a filter
Message-Id: <alpine.LNX.2.00.1105131803120.5121@lxhri02.ws.lrz.de>
On Fri, 13 May 2011, Rainer Weikusat wrote:
> Helmut Richter <hhr-m@web.de> writes:
>> Just trying out, things went well as long data was shorter than 135168
>> bytes. This is *much* more than what I need. Now there are two ways to
>> go on:
>>
>> - Either enhance the logic of the program that it will work for
>> arbitrary length of data.
>
> How about 'fix the broken program in order to make it work'?
Exactly this is the first of the two options I have: fix it in order to
make it work even in those cases that will probably never occur. The other
option is to make it abort with a reasonable message, should the
never-occurring case occur all the same.
> - 'offline processing': child writes output to a temporary
> file, parents reads that after child is done
This has also some complexity: the temporary file must be safely removed.
> - 'online processing' parent uses select/ poll to determine
> when to do which I/O operation on which handle
This has obviously also some complexity which I cannot estimate at the
moment.
--
Helmut Richter
------------------------------
Date: Fri, 13 May 2011 17:47:40 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: piping a vraiable content through a filter
Message-Id: <87oc36y2c3.fsf@sapphire.mobileactivedefense.com>
Helmut Richter <hhr-m@web.de> writes:
> On Fri, 13 May 2011, Rainer Weikusat wrote:
>
>> Helmut Richter <hhr-m@web.de> writes:
>
>>> Just trying out, things went well as long data was shorter than 135168
>>> bytes. This is *much* more than what I need. Now there are two ways to
>>> go on:
>>>
>>> - Either enhance the logic of the program that it will work for
>>> arbitrary length of data.
>>
>> How about 'fix the broken program in order to make it work'?
>
> Exactly this is the first of the two options I have: fix it in order
> to make it work even in those cases that will probably never
> occur.
How have you determined what amount of internal buffering is done
inside perl and the program you are trying to execute and how much
additional buffering the kernel provides for the type of 'file
descriptor based IPC-channel' IPC::Open2 happens to use on the
platform you happened to use so that you are able to make the
statement above with confidence?
> The other option is to make it abort with a reasonable message,
> should the never-occurring case occur all the same.
Make the output file descriptor non-blocking.
>> - 'offline processing': child writes output to a temporary
>> file, parents reads that after child is done
>
> This has also some complexity: the temporary file must be safely removed.
>
>> - 'online processing' parent uses select/ poll to determine
>> when to do which I/O operation on which handle
>
> This has obviously also some complexity which I cannot estimate at the
> moment.
I continue to be amazed by this 'rather a false result than a
complicated calculation' attitude ...
------------------------------
Date: Fri, 13 May 2011 11:57:45 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: piping a vraiable content through a filter
Message-Id: <130520111157457406%jimsgibson@gmail.com>
In article <alpine.LNX.2.00.1105131100511.5121@lxhri02.ws.lrz.de>,
Helmut Richter <hhr-m@web.de> wrote:
> On Thu, 12 May 2011, Rainer Weikusat wrote:
>
> > Helmut Richter <hhr-m@web.de> writes:
> >> I have a filter program "filter" which reads from STDIN and writes to
> >> STDOUT. Now I have in a Perl script a variable $filter_in with data
> >> that have to be transformed to $filter_out. An obvious ways to do that
> >> would be
> >>
> >> use File::Temp qw/tempfile/;
> >> ($fh, $fpath) = tempfile();
> >> binmode($fh, ":utf8" );
> >> print ($fh $filter_in);
> >> close ($fh);
> >> open (FILTER, "filter <$fpath |");
> >> read (FILTER [...]
> >>
> >> Can it be done without creating a temporary file?
> >
> > Have a look at IPC::Open3(3pm).
>
> Thanks, this is a valuable hint. There is also
>
> http://perldoc.perl.org/perlipc.html#Bidirectional-Communication-with-Another-
> Process
> with a little more explanation.
>
> In my intended application, things are much simpler: there is no real
> two-way communication. The input data is sent once, and the output data is
> received once. Without the buffering problems, things would be as simple as
>
> use IPC::Open2;
>
> $stuff = 'x' x $ARGV[0];
>
> $pid = open2($child_out, $child_in, "cat");
> print ($child_in "$stuff");
> close $child_in;
> $got = <$child_out>;
> close $child_out;
>
> print "$ARGV[0]\n";
> if ($stuff eq $got) {
> print "okay\n";
> } else {
> print "wrong\n";
> };
>
> The simple buffered "cat" was chosen deliberately because I do not make
> assumptions on the behaviour of the child process.
>
> Just trying out, things went well as long data was shorter than 135168
> bytes. This is *much* more than what I need. Now there are two ways to go
> on:
If you are using the above test program and writing out a string of
135168 'x' characters, then you should not be using line-oriented input
to read the result ($got = <$child_out>). That assumes some reasonable
line lengths with lines separated by newline characters.
If you are not reading lines, then look at 'perldoc -f sysread'.
>
> - Either enhance the logic of the program that it will work for arbitrary
> length of data.
Have you tried:
while( my $got = <$child_out> ) {
...
}
or
my @got = <$child_out>;
yet?
--
Jim Gibson
------------------------------
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 3384
***************************************
