On 9/23/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> Yeah, but thats a can of worms in of itself. Using backticks is
> simple, and requires no special stuff. If you dont mind blocking until
> the other process completes, I see no reason to use another more
> complex approach.
I seem to recall
Ovid wrote:
> - Original Message
> From: Michael G Schwern <[EMAIL PROTECTED]>
>
>> Something to consider in all this is that TAPx::Parser
>> needs to know to display what goes to STDERR
>> and suppress what goes to STDOUT. This means
>> you simply can't mash the two streams together,
>>
- Original Message
From: Michael G Schwern <[EMAIL PROTECTED]>
> Something to consider in all this is that TAPx::Parser
> needs to know to display what goes to STDERR
> and suppress what goes to STDOUT. This means
> you simply can't mash the two streams together,
> you have to read them
I had lots of trouble getting IPC::Run to work well on Win32; if it
worked well there, I'd recommend it for this application.
If anyone knows how, in Perl, to open up to 3 pipes and then use
WaitForMultipleObjects() on the ends the parent process reads & writes,
please let me know. That's the
demerphq wrote:
>> I found that the suggested code for saving and restoring STDOUT and
>> STDERR given in "perldoc -f open" seems to work OK. This is essentially
>> what IPC::Run3 is doing -- capturing to an external file and then
>> reading it back in and making it available.
>
> Yeah, but thats
On 9/18/06, David Golden <[EMAIL PROTECTED]> wrote:
demerphq wrote:
> On 9/18/06, Ovid <[EMAIL PROTECTED]> wrote:
>> I've gotten a report that the open command fails on Windows. Not a
>> surprise, now that I think about it. However, I don't know of any
>> portable way of forcing STDERR to STDOU
demerphq wrote:
On 9/18/06, Ovid <[EMAIL PROTECTED]> wrote:
I've gotten a report that the open command fails on Windows. Not a
surprise, now that I think about it. However, I don't know of any
portable way of forcing STDERR to STDOUT (and I don't have a Windows
box handy). This means that m
On 9/18/06, Ovid <[EMAIL PROTECTED]> wrote:
- Original Message
From: Michael G Schwern <[EMAIL PROTECTED]>
> > What about an optional environment variable
> > which forcess *all* output to STDOUT or STDERR
> > but, if not present, leaves things as is?
>
> Did anyone think to try it?
>
* Ovid <[EMAIL PROTECTED]> [2006-09-18T13:18:19]
> Anyone have a Windows box and is willing to test this out for me?
I will gladly run tests under WinXP + Strawberry if you tell me where to get it
and what you want to know. Drop me an IM or email.
--
rjbs
- Original Message
From: Chris Dolan <[EMAIL PROTECTED]>
> Try IPC::Open3, it's in the Perl core.
> http://search.cpan.org/perldoc?IPC::Open3
>
> IPC::Run3 is supposed to be good on Windows, but I haven't tried it
> enough.
> http://search.cpan.org/perldoc?IPC::Run3
Anyone have a W
- Original Message
From: Ovid <[EMAIL PROTECTED]>
> If Test::Builder accepted an environment variable which allowed
> me to override this, I might have a way out. So far removing the
> 2>&1 seems to make my tests pass on a Linux box, but that
> strikes me as bizarre as I thought STDERR w
On Sep 18, 2006, at 11:55 AM, Ovid wrote:
I have a bit of a problem, I think. It could simply be a matter of
misunderstanding how things work, but I have the following bit of
code in TAPx::Parser::Source::Perl:
my $sym = gensym;
if ( open $sym, "$command 2>&1 |" ) {
return
- Original Message
From: Michael G Schwern <[EMAIL PROTECTED]>
> > What about an optional environment variable
> > which forcess *all* output to STDOUT or STDERR
> > but, if not present, leaves things as is?
>
> Did anyone think to try it?
>
> $ cat ~/tmp/stdout.t
> #!/usr/bin/perl -w
>
Geoffrey Young wrote:
and
seems a little broken so I doubt anyone's using it,
I use it every day, and it's not broken for me...
By broken I mean I was surprised to find the behavior of Apache::Test changed
by changing the backend. I would have expected the interface to remain the
same. Lo
> Its been doing that for the last 10 years or so. Try an espresso.
yeah, ok.
> Apache::Test, by default, sends diagnostics to STDERR. This is because
> by default it uses Test.pm which sends its errors to STDERR.
right. I haven't actually used the Test.pm interface in ages. but most
other
Geoffrey Young wrote:
$ perl -MTest::Harness -wle 'runtests @ARGV' ~/tmp/stdout.t
/Users/schwern/tmp/stdoutdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat
> $ perl -MTest::Harness -wle 'runtests @ARGV' ~/tmp/stdout.t
> /Users/schwern/tmp/stdoutdubious
>Test returned status 1 (wstat 256, 0x100)
> DIED. FAILED test 1
>Failed 1/1 tests, 0.00% okay
> Failed Test Stat Wstat Total
Ovid wrote:
Are there any Test:: modules which test the STDERR output directly or something
like that?
* Test::Output
* IO::Capture
There are tests that specifically check what's being sent to STDERR (as
well as STDOUT). Of course, these modules intercept STDOUT and STDERR
to keep them awa
On Tue, Sep 05, 2006 at 12:01:47 +0300, Yuval Kogman wrote:
> FWIW, pugs' test suite outputs diags to STDOUT. Things like
> Test::TAP::Builder are much more useful this way, too.
Err, i mean Test::TAP::Model.
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
p
On Tue, Sep 05, 2006 at 01:08:45 -0700, Ovid wrote:
> So who wants to bet against Adam and me?
I'm willing to bet that it'll take you at least a week to win, thus
making it seem like you actually lost ;-)
FWIW, pugs' test suite outputs diags to STDOUT. Things like
Test::TAP::Builder are much mor
- Original Message
From: Adam Kennedy <[EMAIL PROTECTED]>
> Without knowing anything that will specifically break, I think I'll take
> that bet. There's just too much code scattered around the place not to
> have SOMETHING break...
>
> Loser buys the winner a restaurant meal at the nex
Ovid wrote:
- Original Message
From: ivorw <[EMAIL PROTECTED]>
I've had similar issues with test output out of sequence, especially when
I pipe the output into more or tee (sometimes 2>&1 helps, but not
always).
What about an optional environment variable which forcess *all* output t
Ovid wrote:
- Original Message
From: Andy Lester <[EMAIL PROTECTED]>
I think I might just JFDI a "T::H goes to STDOUT" release.
You can call it the "Ovid wants to have Petdance's children" release. Anyone
care to place bets as to whether or not anything depends on this behavior?
Rafael Garcia-Suarez wrote:
Ovid wrote in perl.qa :
I've had similar issues with test output out of sequence, especially when
I pipe the output into more or tee (sometimes 2>&1 helps, but not
always).
What about an optional environment variable which forcess *all* output
to STDOUT or STDERR bu
On Sep 4, 2006, at 4:15 PM, Ovid wrote:
You can call it the "Ovid wants to have Petdance's children"
release. Anyone care to place bets as to whether or not anything
depends on this behavior?
PLease note as David pointed out that it's really Test::Builder
that's the issue here.
--
And
- Original Message
From: Andy Lester <[EMAIL PROTECTED]>
> I think I might just JFDI a "T::H goes to STDOUT" release.
You can call it the "Ovid wants to have Petdance's children" release. Anyone
care to place bets as to whether or not anything depends on this behavior?
Cheers,
Ovid
On Sep 4, 2006, at 10:58, Andy Lester wrote:
I think I might just JFDI a "T::H goes to STDOUT" release.
That won't preveing T::B from sending output to two different file
handles…
Best,
David
On Sep 4, 2006, at 07:19, Ovid wrote:
Actually, I'm not sure how this would break anything and *I* don't
see a problem with it, but since the current behavior is to use
separate file handles, I'm not sure if there's anyone relying on
the current behavior. However, given that it's so widesp
On Sep 4, 2006, at 12:44 PM, chromatic wrote:
T::H didn't always know how to cope with that. I patched it within
the past
couple of years.
I think it's a long-time backwards compatibility issue, but I don't
feel
strongly about it.
I think I might just JFDI a "T::H goes to STDOUT" relea
On Monday 04 September 2006 07:12, Rafael Garcia-Suarez wrote:
> What's exactly the problem with sending everything to stdout by default?
> T::H knows how to cope with that.
T::H didn't always know how to cope with that. I patched it within the past
couple of years.
I think it's a long-time ba
- Original Message
From: Rafael Garcia-Suarez <[EMAIL PROTECTED]>
> What's exactly the problem with sending everything to stdout by default?
> T::H knows how to cope with that. I don't like the environment variable
> idea. It's easy to forget your environment and be surprised when
> switc
Ovid wrote in perl.qa :
>> I've had similar issues with test output out of sequence, especially when
>> I pipe the output into more or tee (sometimes 2>&1 helps, but not
>> always).
>
> What about an optional environment variable which forcess *all* output
> to STDOUT or STDERR but, if not present
- Original Message
From: ivorw <[EMAIL PROTECTED]>
> I've had similar issues with test output out of sequence, especially when
> I pipe the output into more or tee (sometimes 2>&1 helps, but not
> always).
What about an optional environment variable which forcess *all* output to
STDOUT
> -Original Message-
> From: demerphq [mailto:[EMAIL PROTECTED]
> Sent: 04 September 2006 13:13
> To: Ovid
> Cc: perl-qa@perl.org
> Subject: Re: Terrible diagnostic failure
>
>
> On 9/4/06, Ovid <[EMAIL PROTECTED]> wrote:
> > Once again we have a
On 9/4/06, Ovid <[EMAIL PROTECTED]> wrote:
Once again we have an example of how using different output streams for regular
and diagnostic information causes serious problems. This is the worst I've
seen. In one method I'm testing I embedded the following:
use Data::Dumper;
::diag(Dat
Once again we have an example of how using different output streams for regular
and diagnostic information causes serious problems. This is the worst I've
seen. In one method I'm testing I embedded the following:
use Data::Dumper;
::diag(Data::Dumper->Dump(
[$stripped, [EMAIL
36 matches
Mail list logo
