If you look at the sample, the exec method is called on a $chan object. And if you look at the previous line:

      my $chan = $ssh2->channel();
      $chan->exec('program');
[download]

You'll see that is create using the channel() method. Look down for the documentation on the channel method and you find:

channel ( [type, [window size, [packet size]]] )

Creates and returns a new channel object. See Net::SSH2::Channel.
[download]

That reference to Net::SSH2::Channel is a live link, and if you click it, you'll find:

exec ( command ) Execute the command on the remote host (calls process("exec", command)). Note that the given command is parsed by the remote shell; it should be properly quoted, specially when passing data from untrusted sources.

Modules by this author are better (if sometimes more tersely) documented than most.

Thank you kindly BrowserUk, when you showed it to me, everything seemed to be a bit clearer :). So, documentation can be nested, it's a valuable information.

May i assume that this rule applies to all modules? like when Foo::Bar calls baz method and i did not find (sub?)methods for baz, looking for Foo::Bar::baz is an option?

Question might sound naive, but i am rather skilled in shell scripting/ 8bit assemblers and this whole OO-way of thinking is much abstraction to me. I found it very complicated as you can see on above example...

May i assume that this rule applies to all modules? like when Foo::Bar calls baz method and i did not find (sub?)methods for baz, looking for Foo::Bar::baz is an option?

No. Don't assume that. It is entirely down to how the author choses to document (or not!) his code.

But it certainly does no harm to look for it :)

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

If you have a specific Net::SSH2 question - ask it! I too have had issues trying to understand its use but finally figured out some of my problems. Another challenge is that I'm exclusively on Windows / Strawberry Perl so that's (one of) the only SSH modules that will work - and it comes bundled / compiled with Strawberry in vendor/lib. I was able to understand enough to cobble together a simple SSH client and the CPAN Net::SSH2::Cisco module - a drop in replacement for Net::Telnet::Cisco. Happy to share that code if you think it will help.

That said, in a more general sense, I try to put probably more documentation in my releases than most. I started with inline comments but then moved to POD once I understood what that was, how it worked, and how superior it is to understanding usage for new users. I (most of the time) try to include a pretty complete SYNOPSIS and either an EXAMPLES section or provide bin/ scripts that provide basic functionality which a user can use right away, or customize to their heart's content.

True, some authors just don't document or don't document "well", but that's relative. Someone who writes a module is sometimes so familiar with the way it works and what it does, they may sometimes lose sight that other users may not be as familiar and need a jump-start / working example to build on.

Good luck!

Thank you all for fistful of valuable informations. Now i see that being a perlist isn't so colorful and fluffy as being pythonist, but on the other hand, what comes in pain gives more gain ;)

Like on this meme https://pics.me.me/ill-protect-you-ill-keep-you-warm-until-youre-ready-21405659.png ,just s/Gentoo/perl/

…being a perlist isn't so colorful and fluffy as being pythonist…

I must add that Python is scaly and black and white, no softness or shades of color at all. :P

not colorful? For Brits we even have colours!