Net::SSH2::Channel(3)
π Net::SSH2::Channel(3) β the SSH2 channel object, explained by your bestie π
okay so welcome to Net::SSH2::Channel, bestie!! this is the channel object from the Perl docs (User Contributed Perl Documentation, no less), and it's literally the thing that carries your actual data back and forth over an SSH connection. it's an object, but plot twist: it's also a tied filehandle. main character energy fr fr. π
β¨ SYNOPSIS β¨
my $chan = $ssh2->channel()
or $ssh2->die_with_error;
$chan->exec("ls -ld /usr/local/libssh2*")
or $ssh2->die_with_error;
$chan->send_eof;
while (<$chan>) {
print "line read: $_";
}
print "exit status: " . $chan->exit_status . "\n";
like. look at her go. π
πΈ DESCRIPTION πΈ
so a channel object gets created by the Net::SSH2 channel method. and yes it's a real object with methods and everything, but it's also a tied filehandle, so you can <$chan> it like it's just some file. iconic behaviour, no notes.
π§ setenv ( key, value ... )
sets remote environment variables!! cute!! but ngl, most servers do not let you set environment variables all willy-nilly, so don't get your hopes up.
you pass in a list of keys and values β those are the things you wanna set.
returns a true value if all the given environment variables got set correctly. all of them. every single one. periodt.
π§ blocking ( flag )
turn blocking on or off, your call.
heads up though: this is currently implemented in libssh2 by setting a per-session flag. it's equivalent to Net::SSH2::blocking. so like, it's the same vibe, just wearing a different outfit.
π§ eof
returns true if the remote server sent an EOF. that's it. that's the whole method. she's simple, she's effective. β¨
π§ send_eof
sends an EOF to the remote side!
after an EOF has been sent, no more data may be sent to the remote process STDIN channel. none. zero. the door is closed bestie.
β οΈ note that if a PTY was requested for the channel, the remote server may just... ignore the EOF. rude. see pty.
π§ close
close the channel!! (it also happens automatically on object destruction, so she's self-sufficient like that π«Ά)
π§ wait_closed
wait for a remote close event.
in order to avoid a bug in libssh2, this method discards any unread data queued in the channel. so like, bye to that data. it's gone. it's not coming back. π
π§ exit_status
returns the channel's program exit status.
this method blocks until the remote side closes the channel. so she will sit there and wait. patiently. forever if she has to. π
π§ pty ( terminal [, modes [, width [, height ]]] )
request a terminal on a channel!!
terminal is the type of emulation (e.g. vt102, ansi, etc...).
modes are the terminal mode modifiers, for instance:
$c->pty('vt100', { echo => 0, vintr => ord('k') });
the list of acceptable mode modifiers is available from the SSH Connection Protocol RFC (RFC4254 <https://tools.ietf.org/html/rfc4254#section-8>).
if provided, width and height are the width and height in characters (defaults to 80x24); if negative their absolute values specify width and height in pixels. yes, pixels. fancy.
π§ pty_size ( width, height )
request a terminal size change on a channel. width and height are the width and height in characters; if negative their absolute values specify width and height in pixels. same rules as pty, just the resize edition. π
π§ ext_data ( mode )
set the extended data handling mode:
- normal (default) β keep data in separate channels;
STDERRis read separately. - ignore β ignore all extended data.
- merge β merge into the regular channel.
pick your fighter. π
π§ process ( request, message )
start a process on the channel. see also shell, exec, subsystem.
β οΈ note that only one invocation ofprocessor any of the shortcutsshell,execorsubsystemis allowed per channel. in order to run several commands, shells or/and subsystems, a newChannelinstance must be used for every one. one channel, one job. that's the rule.
alternatively, it is also possible to launch a remote shell (using shell) and simulate the user interaction printing commands to its stdin stream and reading data back from its stdout and stderr. but honestly?? this approach should be avoided if possible; talking to a shell is difficult and, in general, unreliable. it's giving chaos. π
π§ shell
start a shell on the remote host (calls process("shell")).
π§ 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. like please quote it. for your own good. π₯
π§ subsystem ( name )
run subsystem on the remote host (calls process("subsystem", name)).
π§ read ( buffer, max_size [, ext ] )
attempts to read up to max_size bytes from the channel into buffer. if ext is true, reads from the extended data channel (STDERR).
the method returns as soon as some data is available, even if the given size has not been reached. she's not gonna wait around for the full amount, she has places to be.
returns number of bytes read or undef on failure. and note that 0 is a valid return code β don't @ me, that's just how it is. β¨
π§ read2 ( [max_size] )
attempts to read from both the ordinary (stdout) and the extended (stderr) channel streams. multitasking queen. π
returns two scalars with the data read both from stdout and stderr. it returns as soon as some data is available and any of the returned values may be an empty string.
when some error happens it returns the empty list.
example:
my ($out, $err) = ('', '');
while (!$channel->eof) {
if (my ($o, $e) = $channel->read2) {
$out .= $o;
$err .= $e;
}
else {
$ssh2->die_with_error;
}
}
print "STDOUT:\n$out\nSTDERR:\n$err\n";
π§ readline ( [ext [, eol ]] )
reads the next line from the selected stream (ext defaults to 0: stdout).
$/ is used as the end of line marker when eol is undef.
in list context reads and returns all the remaining lines until some read error happens or the remote side sends an eof.
β οΈ note that this method is only safe when the complementary stream (e.g.!ext) is guaranteed to not generate data or whenext_datahas been used to discard or merge it; otherwise it may hang. this is a limitation of libssh2 that hopefully would be removed in a future release, in the meantime you are advised to use read2 instead. fr fr, use read2.
π§ getc( [ext] )
reads and returns the next character from the selected stream.
returns undef on error.
β οΈ note that due to some libssh2 quirks, the return value can be the empty string which may indicate an EOF condition (but not always!). see eof. she's mysterious like that. π¦
π§ write ( buffer )
send the data in buffer through the channel. returns number of bytes written, undef on failure.
in versions of this module prior to 0.57, when working in non-blocking mode, the would-block condition was signaled by returning LIBSSH2_ERROR_EAGAIN (a negative number) while leaving the session error status unset. from version 0.59, undef is returned and the session error status is set to LIBSSH2_ERROR_EAGAIN as for any other error. glow-up tbh. β¨
β οΈ in non-blocking mode, ifwritefails with aLIBSSH2_ERROR_EAGAINerror, no other operation must be invoked over any object in the same SSH session besidessockand blocking_directions. once the socket becomes ready again, the exact same formerwritecall, with exactly the same arguments must be invoked. failing to do that would result in a corrupted SSH session. this is a limitation in libssh2. do not test this. do not be curious. π
π§ flush ( [ ext ] )
discards the received but still unread data on the channel; if ext is present and set, discards data on the extended channel. returns number of bytes discarded, undef on error. goodbye data, you will not be missed. π
π§ exit_signal
returns the name of exit signal from the remote command.
in list context returns also the error message and a language tag, though as of libssh2 1.7.0, those values are always undef. so like... they're there. theoretically. π
this method blocks until the remote side closes the channel.
π§ exit_signal_number
converts the signal name to a signal number using the local mapping (which may be different to the remote one if the operating systems differ). cross-platform chaos, we love to see it. π
π§ window_read
returns the number of bytes which the remote end may send without overflowing the window limit.
in list context it also returns the number of bytes that are immediately available for read and the size of the initial window. bonus content!! π
π§ window_write
returns the number of bytes which may be safely written to the channel without blocking at the SSH level. in list context it also returns the size of the initial window.
β οΈ note that this method doesn't take into account the TCP connection being used under the hood. getting a positive integer back from this method does not guarantee that such number of bytes could be written to the channel without blocking the TCP connection. she's talking about the SSH layer only, bestie. read the fine print.
π§ receive_window_adjust ( adjustment [, force] )
adjust the channel receive window by the given adjustment bytes.
if the amount to be adjusted is less than LIBSSH2_CHANNEL_MINADJUST and force is false the adjustment amount will be queued for a later packet. it's giving "we'll get to it". β¨
on success returns the new size of the receive window. on failure it returns undef.
π SEE ALSO π
- Net::SSH2.
and that's the whole page bestie!! go forth and channel responsibly, and remember: non-blocking write errors are not a vibe to experiment with. π
perl v5.42.0 Β· 2025-07-25 Β· Net::SSH2::Channel(3) β mwah, ily, see u in the next manpage π π«Ά
π¦ where this page comes from
- fedora 43: perl-Net-SSH2 0.74-4.fc43 Β· GPL-1.0-or-later OR Artistic-1.0-Perl
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms