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

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

Mark Fuller wrote:

>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*.
>  
>
How does Expect work?  It works by capturing the output of a command, 
and giving you useful mechanisms for parsing it and responding to it, 
right?  But you're still parsing the human readable output of a command 
line.  How can that be consider more reliable than depending on the 
documented behavior of a perl function or module?  The output can change 
at any time.  There are differences in system utiltities from OS to OS 
(the 'ps' command is a classic example).  If you get new mail you might 
get a "new mail arrived" line thrown in unexpectedly.  Expect is 
powerful and useful, but it is a hack.

-ofer