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

[Mark F. <mar...@ea...>]

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.

>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?

> 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?

>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).

Mark