Re: [Ssh-sftp-perl-users] Net::SSH::Perl error handling

[Ofer N. <on...@sh...>]

Mark Fuller wrote:

>From: "Ofer Nave" <on...@sh...>
>  
>
>>goes out the window the minute I have to
>>call system() and use a seperate executable (not to mention the fact
>>that you fork several times needlessly in the process).
>>    
>>
>
>Wouldn't the fact that you're executing a binary cancel out the overhead of
>the system call to use it (and the forks)? I haven't noticed a performance
>problem using Expect.pm to drive an sftp executable.
>
>  
>
You're right that the binary will be faster than a pure-perl 
implementation like Net::SSH::Perl once the code has started running.  
It doesn't "cancel" anything out cleanly, because the cost of forking is 
one constant, while the cost of a slower implementation is proportional 
to the amount of data you transfer.  But the cost of forking, and 
perhaps even the cost of a slower perl implementation, are both likely 
negligble relative to the latency of network communication.

However, the fork still does have a time cost that can add up, and it's 
harder on the OS (more task switching), and pollutes the process table, 
and is just plain ugly.  I have scripts that fork all over the place, 
but I do it when I have to, not when I have a choice. [1]

The best of both world would be a Net::SSH::XS module that wraps a C 
library - preferably whatever C library is already used by the ssh 
command (openssl?) so the same code doesn't have to be written twice.  
Native perl calls, C speed.  XSellent!

>>And what is my feedback?  An 8-bit integer, and maybe some STDOUT/STDERR
>>    
>>
>output that I
>  
>
>>have to capture and parse?
>>    
>>
>
>I was interrogating results in N::S::P too. Also, capturing all results
>(eval, die signal and accumulating messages in an array) wasn't exactly
>graceful either. :) I don't see the difference. Either way a person is
>probably going to want to test the results and make decisions, right?
>
>  
>
Yes, but perl code works well with other perl code.  If I have to use 
the system function, it's the equivalent of building a model airplane 
using a pair of salad tongs instead of your hands.  You can get some 
stuff done, but it's a pain in the ass, and you're tactile feedback is 
astonishingly limited.

>>returning complex data structures, like a native function can?
>>    
>>
>
>I haven't needed that (yet). Can you give me an example of when returned
>complex data structures would be useful?
>
>  
>
Sure.  DBI.  Imagine having to use system() to call the 'isql' utility 
to run queries against Sybase and parse the output instead of using the 
DBI library.

Oh god, I wish I hadn't said that.  I think I'm breaking out in hives now.

>>Or being able to throw execptions that are captured?
>>    
>>
>
>I'm not sure what you mean. If the open-ssh sftp binary encounters an error,
>Expect.pm captures this. It's available to me. Are there other exceptions?
>
>To me, the greatest benefits using Expect.pm are these three:
>
>1. I can drive any binary in *exactly* the same manner. I'm not forced to
>learn the peculiarities of every pure-perl interface. I'm probably going to
>learn the binary's peculiarities since that's how I would first develop the
>steps to connect and test every operation of the connection. Wrapping it
>with Expect.PM is just implementing what I learned executing the binary
>manually. That's seems simpler. It's like "what you see is what you get."
>
>2. Because I'm using the binary, if anything begins failing (in the distant
>future), it's relatively easy to execute the binary manually in order to
>discover what (in the process of connecting and navigating) has changed. The
>binary becomes an accessible reference point.
>
>3. The binary is probably better vetted, having seen greater usage. There's
>less chance of stumbling upon a bug or security risk.
>
>Off hand, the only thing I can think of for when a pure-perl interface would
>be better is if the client will execute on a variety of platforms. Then
>you'd only have to learn one peculiar interface rather than each vendor's
>binary. (FTP is an example of how different each vendor's binary could be).
>
>  
>
Does anyone else want to jump in and field these?  Or am I in the 
minority?  If I am, I'll shut up.

-ofer

[1] I lied.  I don't *have* to fork all the times that I do, but I'm too 
scared to learn multi-threaded programming.  :)