[29525] in Perl-Users-Digest
Perl-Users Digest, Issue: 769 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 18 21:09:42 2007
Date: Sat, 18 Aug 2007 18:09:07 -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 Sat, 18 Aug 2007 Volume: 11 Number: 769
Today's topics:
Re: about CGI <nobull67@gmail.com>
Re: FAQ 6.16 How do I efficiently match many regular ex <brian.d.foy@gmail.com>
Re: Gaa! UNIX hack tries PPM and fails! <sisyphus1@nomail.afraid.org>
Re: Guitars, amps, tabs and more!! <shendeajay@gmail.com>
Re: Help on compiling Perl 5.8.8 <sigzero@gmail.com>
Re: Help on compiling Perl 5.8.8 <sisyphus1@nomail.afraid.org>
Re: Sending a "status" <m@rtij.nl.invlalid>
Re: Sending a "status" <stoupa@practisoft.cz>
Stumped: returning a read pipe from a function <socyl@987jk.com.invalid>
Re: Stumped: returning a read pipe from a function <noreply@gunnar.cc>
Re: Stumped: returning a read pipe from a function <socyl@987jk.com.invalid>
Re: Stumped: returning a read pipe from a function <socyl@987jk.com.invalid>
Re: Stumped: returning a read pipe from a function (Alan Curry)
Re: Stumped: returning a read pipe from a function xhoster@gmail.com
Re: Stumped: returning a read pipe from a function <noreply@gunnar.cc>
Re: Stumped: returning a read pipe from a function <noreply@gunnar.cc>
Re: Stumped: returning a read pipe from a function xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 18 Aug 2007 13:39:41 -0000
From: Brian McCauley <nobull67@gmail.com>
Subject: Re: about CGI
Message-Id: <1187444381.893230.106830@19g2000hsx.googlegroups.com>
On Aug 17, 4:38 pm, joker <attack...@yahoo.com> wrote:
> Thanks a lot to all.
>
> A word to Bryan
>
> Really my english is so important?? The others guys has answered me
> very well. You have to be more flexible about language...You are on
> internet, DO YOU KNOW THAT?
I don't care about your poor English so long as you manage to express
yourself. (I'm not "she who must no be named").
You may consult my posting history to see that I care very much about
how well the questions are asked in terms of the asker thinking about
how they can help the answerer. I care not at all if people use very
limited English.
For the record: I don't think _anyone_ understood your question.
Paul's response only shows that he picked up on the one word "CGI". He
showed you a simple Perl CGI script and told you to RTFM. I can't
really see how Paul's example script would help you any more than the
"Synopsis" section of Perl's CGI manpage. So in effect Paul's response
was just an RTFM.
So that's two "we don't understand" responses as one "RTFM" response.
I gave you the benifit of the doubt and assumed you had a valid
question that you were unable to express clearely. I did _not_ assume
you simply could not be bothered to RTFM so I didn't think it would
help to suggest that you RTFM.
I am very sorry if I miss-judged you.
------------------------------
Date: Sat, 18 Aug 2007 15:20:35 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 6.16 How do I efficiently match many regular expressions at once?
Message-Id: <180820071520357201%brian.d.foy@gmail.com>
In article <slrnfc40ns.95e.allergic-to-spam@no-spam-allowed.org>, Jim
Cochrane <allergic-to-spam@no-spam-allowed.org> wrote:
> On 2007-08-14, PerlFAQ Server <brian@stonehenge.com> wrote:
> > 6.16: How do I efficiently match many regular expressions at once?
> > @patterns = map { qr/\b$_\b/i } qw( foo bar baz );
> >
> > LINE: while( <> )
> > {
> > foreach $pattern ( @patterns )
> > {
> > print if /\b$pattern\b/i;
>
> # Aren't the '\b's redundant here, or am I missing something? If so,
fixed, thanks.
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Sun, 19 Aug 2007 01:51:42 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: Gaa! UNIX hack tries PPM and fails!
Message-Id: <46c7158d$0$31115$afc38c87@news.optusnet.com.au>
<usenet@DavidFilmer.com> wrote in message
news:1187428926.816924.277300@m37g2000prh.googlegroups.com...
.
.
>
> Hmmm. If I were one of those smug, stuck-up UNIX hack types then I
> would make some smug comment here about Perl and Windows.
<this is really just a rant>
Heh ... you missed out on *one* adjective. Following "stuck-up", you should
have written "and anachronistic" :-)
It's actually fairly trivial to build most things from *source* on Windows
these days (using free tools).
Libraries like openssl are readily buildable using the (freely available)
MinGW port of gcc in the (freely available) MSYS shell. And the crypto
modules are just as easily built from source (in the cmd.exe shell) using
the aforementioned MinGW port of gcc (even with ActivePerl).
These days, PPM is more a "convenience", rather than a "necessity".
Then ... along came fucking Windows Vista ... which breaks MinGW, breaks
MSYS, and makes a total mockery of what I've just written :-)
There are patched versions of gcc.exe and g++.exe available for the MinGW
port of gcc-3.4.5 that work with Vista, but, afaik, there's still no
properly functioning version of the MSYS shell for Vista. As I understand
it, if you've got Windows Vista, and you want to build openssl for MinGW
from source, then you would have to do it from Cygwin as a cross-compilation
for MinGW. And then, to link against that library, as is the case when you
build the Perl crypto libraries, you'll need the patched version of gcc.exe.
</this is really just a rant>
Cheers,
Rob
------------------------------
Date: Sat, 18 Aug 2007 08:36:39 -0700
From: Bliton <shendeajay@gmail.com>
Subject: Re: Guitars, amps, tabs and more!!
Message-Id: <1187451399.881011.135830@q3g2000prf.googlegroups.com>
On Aug 18, 1:57 am, mobile...@gmail.com wrote:
> Reviews of latest models of best guitars, fender, gibson, yamaha, and
> many more, with pictures and prices.
>
> http://pro-guitars.blogspot.com/
>
> And if you want to win a free guitar go here
>
> http://freeguitars.blogspot.com/
Hello my friend,
This is group where we discuss about C language and programming.
you should have posted this message in some music group.
------------------------------
Date: Sat, 18 Aug 2007 06:22:55 -0700
From: Robert Hicks <sigzero@gmail.com>
Subject: Re: Help on compiling Perl 5.8.8
Message-Id: <1187443375.598401.92180@o80g2000hse.googlegroups.com>
On Aug 18, 1:09 am, "Sisyphus" <sisyph...@nomail.afraid.org> wrote:
<snip>
> Looks like you need to link to libm (since that's where those references are
> defined).
> You might be able to hack your way past the problem by running:
>
> cc -L/usr/local/lib -o miniperl miniperlmain.o opmini.o libperl.a
> /usr/lib/libcrypt.a /usr/lib/libm.a
>
> and then run 'make' again.
>
> Or maybe add the "usr/lib/libm.a" to the end of that command in the makefile
> itself - before running 'make'.
>
> Cheers,
> Rob
I wonder why it is happening though. We built the server on Monday and
Perl compiled flawlessly and when we rebuilt on Thursday using the
same process I get the error now. Strange...
Robert
------------------------------
Date: Sun, 19 Aug 2007 00:14:26 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: Help on compiling Perl 5.8.8
Message-Id: <46c6fec2$0$1381$afc38c87@news.optusnet.com.au>
"Robert Hicks" <sigzero@gmail.com> wrote in message
.
.
>
> I wonder why it is happening though. We built the server on Monday and
> Perl compiled flawlessly and when we rebuilt on Thursday using the
> same process I get the error now. Strange...
>
I agree, it's odd. I'm no expert (especially on anything that aint windows),
but as I understand it, libm is linked in automatically (by default) on some
systems (eg windows), but is not linked in automatically on some other
systems.
My best guess is that, under the original build, libm was linked in by
default. But under the new rebuild libm has to be explicitly linked in.
Furthermore, configure has not detected this change (which would probably be
a bug in configure), and the new makefile therefore fails in that regard.
Or something like that :-)
If you can verify that my original suggestion of modifying the makefile
actually works, then I think that suggests that configure is not doing its
job correctly, and you should submit a bug report.
If neither of my original suggestions are helpful then you should probably
ignore me altogether and wait for a more knowledgeable reply :-)
(Best way to submit a bug report is to run 'perlbug'.)
Cheers,
Rob
------------------------------
Date: Sat, 18 Aug 2007 15:41:02 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Sending a "status"
Message-Id: <pan.2007.08.18.13.40.58@rtij.nl.invlalid>
On Sat, 18 Aug 2007 04:58:54 +0200, Petr Vileta wrote:
> Bill H wrote:
>> Using $|++ I have learned that I can "flush" the print buffer to a
>> browser while perl is doing things, instead of sending all the html
>> when it is done. Is there any drawbacks to using this in the real world
>> that any of you may have encountered?
>>
>> Basically what I would be doing is sending a status to a client while
>> the perl scripts are working such as (after sending the html headers
>> and other stuff):
>>
>> Saving your data...
>> Processing your data...
>> Generating completed pdf...
>> Complete.
>>
>> etc...
>>
>> and then sending the ending html data.
>>
> It is solvable but not for 100% ;-)
> At first you must keep in mind that some html tags are displayed after
> end tag only. For example you must not put messages into <table>. At
> second you must send many (useless) spaces to fill browser buffer.
>
> $|=1;
> print "<p>Saving your data...</p>, ' 'x1024; # do something
> print "<p>Processing your data......</p>, ' 'x1024;
>
> # do something
>
> This work well (tested) for MSIE5.x and latter and Firefox 2.x and
> latter.
To be more exact, some versions of IE don't display anything unless they
have received 256 characters (or the page is complete, obviously). So
send 256 spaces first and then start outputting the rest. No need to send
1024 spaces on every print.
M4
------------------------------
Date: Sat, 18 Aug 2007 16:11:46 +0200
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: Sending a "status"
Message-Id: <fa6uqp$274l$1@ns.felk.cvut.cz>
Martijn Lievaart wrote:
>> $|=1;
>> print "<p>Saving your data...</p>, ' 'x1024; # do something
>> print "<p>Processing your data......</p>, ' 'x1024;
>>
>> # do something
>>
>> This work well (tested) for MSIE5.x and latter and Firefox 2.x and
>> latter.
>
> To be more exact, some versions of IE don't display anything unless
> they have received 256 characters (or the page is complete,
> obviously). So send 256 spaces first and then start outputting the
> rest. No need to send 1024 spaces on every print.
>
Yes, I found this information somewhere too, but in real this is not true
:-) Some MSIE (maybe some 6.x) need 512 bytes and some Firefox need a little
more so I send 1024 everytime and this work for most browsers. All browsers
trash redundant spaces and show only one.
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
------------------------------
Date: Sat, 18 Aug 2007 17:30:48 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Stumped: returning a read pipe from a function
Message-Id: <fa7ac8$a9e$1@reader1.panix.com>
I'd like to write a function along these lines:
sub foo {
my @args = @_;
open my $in, '-|', '/some/command', @args or die $!;
return $in;
}
(The OS is Unix.)
The code above works fine when the arguments in @args are all OK.
Otherwise '/some/command' spits an error message to stderr and
dies, a failure that the code above fails to trap, so the routine
exits normally.
Putting an eval around the open statement fails to catch the error,
and certainly it does not prevent the error message from /some/command
from appearing in stderr.
The root of all these problems I'm sure has to do with the implicit
fork triggered by the '-|' argument to open.
My question is: how can I trap the error and the error message?
TIA!
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Sat, 18 Aug 2007 20:40:39 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <5iospgF3pa0foU1@mid.individual.net>
kj wrote:
> I'd like to write a function along these lines:
>
> sub foo {
> my @args = @_;
> open my $in, '-|', '/some/command', @args or die $!;
> return $in;
> }
>
> (The OS is Unix.)
>
> The code above works fine when the arguments in @args are all OK.
> Otherwise '/some/command' spits an error message to stderr and
> dies, a failure that the code above fails to trap, so the routine
> exits normally.
<snip>
> My question is: how can I trap the error and the error message?
One idea:
sub foo {
my @args = @_;
open my $in, '-|', '/some/command', @args;
return $in if fileno $in;
close $in or die $!;
}
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 18 Aug 2007 18:59:15 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <fa7fi3$35q$1@reader1.panix.com>
In <fa7ac8$a9e$1@reader1.panix.com> kj <socyl@987jk.com.invalid> writes:
>I'd like to write a function along these lines:
> sub foo {
> my @args = @_;
> open my $in, '-|', '/some/command', @args or die $!;
> return $in;
> }
>(The OS is Unix.)
>The code above works fine when the arguments in @args are all OK.
>Otherwise '/some/command' spits an error message to stderr and
>dies, a failure that the code above fails to trap, so the routine
>exits normally.
>Putting an eval around the open statement fails to catch the error,
>and certainly it does not prevent the error message from /some/command
>from appearing in stderr.
>The root of all these problems I'm sure has to do with the implicit
>fork triggered by the '-|' argument to open.
>My question is: how can I trap the error and the error message?
Well, I'm getting close (I think). This is the best I've managed,
though it has at least a few problems:
use Socket;
use IO::Handle;
sub foo {
socketpair( my $child, my $parent, AF_UNIX,
SOCK_STREAM, PF_UNSPEC)
or die $!;
$_->autoflush( 1 ) for $child, $parent;
unless ( my $pid = fork ) {
die $! unless defined $pid;
close $child or die $!;
open STDOUT, '>&', $parent or die $!;
my $status = system "/some/command @_ 2>&1";
exit( $status ? 1 : 0 );
}
close $parent or die;
wait;
die join '', <$child> if $?;
return $child;
}
This seems to work, but the system() call requires the shell, due
to the "2>&1" redirection. Also, it's a lot of machinery to do
something that is rather simple, conceptually at least. Plus it
uses an explicit fork, which makes debugging with perldb a bit of
a pain.
Any other comments or suggestions about this code would be much
appreciated. TIA!
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Sat, 18 Aug 2007 20:32:36 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <fa7l14$j5j$1@reader1.panix.com>
In <5iospgF3pa0foU1@mid.individual.net> Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>One idea:
> sub foo {
> my @args = @_;
> open my $in, '-|', '/some/command', @args;
> return $in if fileno $in;
> close $in or die $!;
> }
Thanks, but, as it happens, fileno( $in ) is positive even when
'/some/command' fails.
I had a bit better luck testing for eof( $in ), but this is not a
general solution, because there may be cases in which eof( $in )
evaluates to true even when the command was executed successfully.
Worse yet, even when the error is correctly detected, I still don't
have the error message...
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Sat, 18 Aug 2007 21:43:19 +0000 (UTC)
From: pacman@TheWorld.com (Alan Curry)
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <fa7p5n$6a5$1@pcls4.std.com>
In article <fa7ac8$a9e$1@reader1.panix.com>,
kj <socyl@987jk.com.invalid> wrote:
>
>I'd like to write a function along these lines:
>
> sub foo {
> my @args = @_;
> open my $in, '-|', '/some/command', @args or die $!;
> return $in;
> }
[...]
>My question is: how can I trap the error and the error message?
>
Use IPC::Open3.
The problem isn't as simple as you might think. Once you've spawned a child
process this way, it can generate 3 different things that you want to take
notice of: write something on stdout, write something on stderr, or exit.
You need a select() loop and a SIGCHLD handler to be ready for whatever it
might do next.
But if you can be sure that the amount of stuff written to the child's stderr
will never fill the pipe buffer, you can just read the child's stdout until
eof, then read the stderr and waitpid for the exit value.
--
Alan Curry
pacman@world.std.com
------------------------------
Date: 18 Aug 2007 23:02:49 GMT
From: xhoster@gmail.com
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <20070818190255.984$lK@newsreader.com>
kj <socyl@987jk.com.invalid> wrote:
> I'd like to write a function along these lines:
>
> sub foo {
> my @args = @_;
> open my $in, '-|', '/some/command', @args or die $!;
> return $in;
> }
>
> (The OS is Unix.)
>
> The code above works fine when the arguments in @args are all OK.
> Otherwise '/some/command' spits an error message to stderr and
> dies, a failure that the code above fails to trap, so the routine
> exits normally.
That is because the open doesn't fail. /some/command is successfully
started. That is all open cares about. At some later point /some/command
realizes it was given bogus arguments and it exits, but that is irrelevant
to the open--open cares about staring the program. Close worries about
how the program ended.
> Putting an eval around the open statement fails to catch the error,
Of course. The error might not have even happened yet.
> and certainly it does not prevent the error message from /some/command
> from appearing in stderr.
You could redirect stderr to /dev/null if you wanted to do that.
> The root of all these problems I'm sure has to do with the implicit
> fork triggered by the '-|' argument to open.
Not really. The problem is that while the specific error you are
interested in in this case just happens to occur before the first line is
printed, that is not the case generally.
> My question is: how can I trap the error and the error message?
The easiest way would be to have the command save it's output into
a temp file, check the programs exit status ($? after close), and if it
is OK, then open that temp file for reading, unlink it, and return that
file handle back from the sub.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Sun, 19 Aug 2007 01:12:14 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <5ipcmmF3qgm8sU1@mid.individual.net>
kj wrote:
> In <5iospgF3pa0foU1@mid.individual.net> Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>> One idea:
>
>> sub foo {
>> my @args = @_;
>> open my $in, '-|', '/some/command', @args;
>> return $in if fileno $in;
>> close $in or die $!;
>> }
>
> Thanks, but, as it happens, fileno( $in ) is positive even when
> '/some/command' fails.
Ok, here is another try, where $in is a package global, and where you
explicitly close the handle in an END block.
our $in;
sub foo {
my @args = @_;
open my $in, '-|', '/some/command', @args or die $!;
}
END { close $in or die $? }
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 19 Aug 2007 01:15:47 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <5ipctcF3qgm8sU2@mid.individual.net>
Gunnar Hjalmarsson wrote:
>
> our $in;
>
> sub foo {
> my @args = @_;
> open my $in, '-|', '/some/command', @args or die $!;
> }
>
> END { close $in or die $? }
Should of course be
open $in, ...
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 18 Aug 2007 23:20:37 GMT
From: xhoster@gmail.com
Subject: Re: Stumped: returning a read pipe from a function
Message-Id: <20070818192044.362$P8@newsreader.com>
kj <socyl@987jk.com.invalid> wrote:
> Well, I'm getting close (I think). This is the best I've managed,
> though it has at least a few problems:
>
> use Socket;
> use IO::Handle;
> sub foo {
> socketpair( my $child, my $parent, AF_UNIX,
> SOCK_STREAM, PF_UNSPEC)
> or die $!;
>
> $_->autoflush( 1 ) for $child, $parent;
>
> unless ( my $pid = fork ) {
> die $! unless defined $pid;
> close $child or die $!;
>
> open STDOUT, '>&', $parent or die $!;
>
> my $status = system "/some/command @_ 2>&1";
>
> exit( $status ? 1 : 0 );
> }
> close $parent or die;
> wait;
This is liable to deadlock. The parent won't start reading until the
child has exited. The child won't exit until the spawned process
has exited. The spawned process won't exit until it is done printing.
And, if what it is printing is more than one buffer full, then it can't
finish printing until the parent starts reading. Round and round you go.
>
> This seems to work, but the system() call requires the shell, due
> to the "2>&1" redirection. Also, it's a lot of machinery to do
> something that is rather simple, conceptually at least.
I think you are over-estimating the conceptual simplicity of what you
are trying to do.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 V11 Issue 769
**************************************
