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

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

From: "Ofer Nave" <on...@sh...>
> 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.

I guess I still don't understand the significance of this as applied to
Expect.pm driving an open-ssh sftp compiled executable. Expect.pm is Perl.
So, it's my Perl code working well with another Perl code (which itself
abstracts all the details about system calls and trapping the output). Why
should I care that all this is happening beneath the covers (except for
perhaps the performace issues of forking and pipe creation for interprocess
communication)?

To me that's a strength. I'm not interfacing directly to the sftp command.
I'm interfacing to Expect.pm. I do Perl like I normally would. I don't have
to think too much about what's happening. And, once I learn the Expect.pm
heuristics, I can do the same thing with *anything*.

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

Yes, I understand in the case of DBI (and it's rows and columns). But, in
the case of protocols like SFTP, FTP, Telnet, etc., when would this be of
value? That's what I was trying to ask.

> Does anyone else want to jump in and field these?  Or am I in the
> minority?  If I am, I'll shut up.

Sorry. I wasn't trying to challenge you. I just didn't understand why
Expect.pm would be a last resort (undesireable). I can see positives and
negatives involved with either way.

Mark