RSH(1)

πŸ“¦ version 0.17, in debian bookworm, ubuntu jammy

πŸ’– 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 realm and -l username, but the DESCRIPTION below only spills the tea on -K, -d, -l and -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:

  • rsh copies 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 rsh normally 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, using setsockopt(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 in rlogin(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 an rsh in 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, redirect rsh's input to /dev/null using the -n option. that's literally why -n exists 🫠
  • you cannot run an interactive command with rsh β€” like rogue(6) or vi(1). not happening. use rlogin(1) instead πŸ™…
  • stop signals stop the local rsh process only. this is arguably wrong, but currently hard to fix, for reasons too complicated to explain here. iconic of them honestly 😭
tl;dr: -n when 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