At 04:10 PM 12/5/2008 -0500, listmail wrote:
>> I have to chime in. That kind of construct is just plain wrong. :) U need
>> an if{} block to test for every possible return type of $chan->read(). i.e.
>> blank, undef, valid number, invalid number, and other junk. U've fallen
>Uh, I think you are just complaining about one of your pet peeves :) --
Yep. :)
>for him. The docs or Channel.pm code do not seem to indicate the return
>types you have mention here beyond -- bytes read or undef -- so I'm not
>sure how you would code against all of those conditions unless you are
Ur right it does depend on what the docs say, I was just trying to be
generic in describing a good practice. If the module itself restricts what
the call can return then u don't have to check all that, just leaving an
else{} block is sufficient. If undef or a number is the only legal return
value then the if{} block only needs to check for those specifically.
>If he's really concerned about ensuring that he gets all of the output
>-- he needs to consider using $channel->exec otherwise even with adding
>delays (ie. using select calls) *inside* the while loop it still may not
>be long enough of a wait for read to be able to pull in all the output
>as it will probably return undef several times. Unless, that is, he's
>ok with adding in several seconds of delays as needed to cover all types
>of commands or scripts he'd run.
Ur right. The problem is no terminator to the read. *No* amount of loop
delay will guarantee that all the data has been read. I ran into that
myself with some IPC I was working on. I ended up creating a mini protocol
to solve the problem since I had control of both processes.
--
REMEMBER THE WORLD TRADE CENTER ---=< WTC 911 >=--
"...ne cede malis"
00000100
_______________________________________________
Perl-Win32-Users mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
