RSH(1)
π NAME π
rsh β remote shell, aka your lil teleport-to-another-computer bestie π¦
β¨ SYNOPSIS β¨
rsh [-Kdnx] [-k realm] [-l username] host [command]
ok so heads up: the synopsis is showing you-Kdnx,-k realmand-l username, but the DESCRIPTION below only spills the tea on-K,-d,-land-n. i'm just reporting what the page says, bestie, no gatekeeping π
πΈ DESCRIPTION πΈ
rsh runs command on host. that's it, that's the whole vibe. it's giving "be somewhere else without moving" β¨
here's the plumbing tho, and it's lowkey elegant:
rshcopies its standard input to the remote command π₯- it copies the standard output of the remote command back to its own standard output π€
- it copies the standard error of the remote command to its own standard error π¨
- interrupt, quit and terminate signals get propagated to the remote command, so your ctrl-C actually travels π«Ά
- and
rshnormally terminates when the remote command does β ride or die, they leave together π
the options, one by one π
-Kβ turns off all Kerberos authentication. just... all of it. bye π-dβ turns on socket debugging, usingsetsockopt(2), on the TCP sockets used to talk to the remote host. nerdy, we love her π-lβ by default the remote username is the same as your local username. this option lets you specify the remote name instead. Kerberos authentication is used, and authorization is determined as inrlogin(1)π-nβ redirects input from the special device/dev/null. pls read the BUGS section below before you come for me π
no command? no problem β¨
if you don't specify a command, you'll be logged in on the remote host using rlogin(1). so it's basically a lil baby rlogin in that case π§
the quoting lore (this part is iconic) π
shell metacharacters that are not quoted get interpreted on the local machine. quoted metacharacters get interpreted on the remote machine. yes, this matters. yes, it will bite you if you ignore it. π¦
so like, this:
rsh otherhost cat remotefile >> localfile
appends the remote file remotefile to the local file localfile β because that >> was unquoted, your local shell ate it π
while THIS:
rsh otherhost cat remotefile ">>" other_remotefile
appends remotefile to other_remotefile β because the ">>" was quoted, it travelled over to the remote machine and got interpreted there. same characters, completely different energy, no cap π
π FILES π
/etc/hosts
π SEE ALSO π
rlogin(1), kerberos(3), krb_sendauth(3), krb_realmofhost(3)
π°οΈ HISTORY π°οΈ
the rsh command appeared in 4.2BSD. an elder. a legend. respect the ancestor fr fr π
π BUGS π
ok bestie, gather round, this is the part where we hold hands π€
- if you're using
csh(1)and you put anrshin the background without redirecting its input away from the terminal, it will block β even if the remote command isn't posting any reads at all. if you don't actually want input, redirectrsh's input to/dev/nullusing the-noption. that's literally why-nexists π« - you cannot run an interactive command with
rshβ likerogue(6)orvi(1). not happening. userlogin(1)instead π - stop signals stop the local
rshprocess only. this is arguably wrong, but currently hard to fix, for reasons too complicated to explain here. iconic of them honestly π
tl;dr:-nwhen you background it,rlogin(1)for anything interactive, and don't ask about the stop signals π
ok that's the whole page, you're basically a networking girlie now πβ¨
this was RSH(1) from the Linux NetKit, version 0.17, dated August 15, 1999 β mwah, sending you love from the late 90s ππ«Άπ
π¦ where this page comes from
- debian bookworm: rsh-client 0.17-24 Β· BSD-4-Clause
- ubuntu jammy: rsh-client 0.17-22 Β· BSD-4-Clause
- Copyright (c) 1983, 1990 The Regents of the University of California
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms