Well, so long as you must use Net::SSH::Perl, yes, you're bound to PARI. I'll note though that from what hints you've provided about your execution environment, you aren't in a situation where you'd really be taking advantage of Net::SSH::Perl's main advantage, which is that you don't have to create an extra process in order to ssh - this is a boon in a long-running perl process that will ssh frequently, or on a system with a high per-process overhead (such as windows). You don't seem to be in such a situation.
Could you also accomplish what you need to accomplish by using the ssh command-line client already there on the machine you're going to be running on and using Net::SSH, IPC::Open3, or possibly even Expect?
(Note that Expect comes with its own shared-library baggage, but likely less than Pari's)
--
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
| [reply]
[d/l] |
I'd very much like to avoid Expect, and I'd prefer to avoid Net::SSH if only because my code is already tested and written with something else. If the performance problems prove too severe then yes, I can and will fall back on that. (I say this often: Aren't I glad I have a test suite!)
But it'd be pretty sad if the tool I was relying on to ease deployment is limiting my choice of modules, so I'm not giving up yet.
(To clarify: without PAR the performance is acceptable.)
| [reply] |
