I admit, my initial post was a little short.
Well, yes, I am in a situation where I actually *have to* avoid perl filesystem methods. I'm working on an improved Filesys::Virtual::SSH, as the original doesn't reuse the ssh connection, for example.
The approach is similar to what IPC::PerlSSH does, except that I even have to drop the remote perl from the mix. So this here sshs into remote, and then executes system binaries, reading their output, then parsing this on the local end.
I would try to avoid executing perl on the other end wherever possible.
That's why I'd like to parse the brief "ls -a", in a way that allows all sorts of chars in the filenames.
The more I think about it. I might run into a situation where I can't avoid calling perl on the remote end. But really: why should I?? Continuing to use Net::SSH::Expect and solving the parsing of binaries could become a reinvention of the wheel... And perl is also just another binary readily available on most systems. I think I should switch over to IPC::PerlSSH for the hard work. RFC, guys. | [reply] |