xrsh – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

xrsh – Starten Sie ein X-Programm auf einem Remote-Computer

ZUSAMMENFASSUNG

xrsh [ -Hilfe ] [ -Ausführung ] [ -l Benutzername ] [ -e rshprog ] [ -auth Authentifizierungstyp ] [ -Bildschirm
Bildschirm-# ] [ -bestehen envlist ] [ -debuggen ] [ -debug2 ] Remote-Host [ X-Befehl [ Argumente
... ] ]

BESCHREIBUNG

Xrsh führt den angegebenen X-Befehl auf einem Remote-Host aus. Es schafft die Umgebung dafür
Befehl so, dass seine Fenster auf dem Bildschirm des aktuellen Servers angezeigt werden
Weitergabe der Umgebungsvariablen $DISPLAY. Wenn nicht angegeben, ist der Standard-Client
Xterm. Xrsh wählt automatisch aus ssh(1) rsh(1) remsch(1) oder rcmd(1) Remote ausführen
Befehle, abhängig davon, was in der Betriebssystemumgebung verfügbar ist.

Xrsh übernimmt die Authentifizierung automatisch, sodass der Remote-Client dazu berechtigt ist
Öffnen Sie Fenster auf dem Server. Dies geschieht je nach Wert auf unterschiedliche Weise
der Umgebungsvariablen $XRSH_AUTH_TYPE oder des Arguments -auth.

Standardmäßig verwendet xrsh xhost, um dem Remote-Client das Öffnen einer Serververbindung zu ermöglichen.
Es kann auch angewiesen werden, xauth zu verwenden, um lokale Schlüssel in einer Remote-Autorisierungsdatei zusammenzuführen.
Oder es kann die Umgebungsvariable $XAUTHORITY an den Remote-Host übergeben, um eine zu teilen
Gemeinsame NFS-gemountete Autoritätsdatei. Es kann auch angewiesen werden, in dem Fall nichts zu unternehmen
wo keine ausdrückliche Genehmigung erforderlich ist.

Benutzer, die nur ein Remote-Terminalfenster möchten, schauen sich vielleicht den Schwesterbefehl von xrsh an:
xrlogin(1). Xrlogin verwendet ein lokal ausgeführtes xterm, um eine Rlogin-Verbindung zu einer Remote-Verbindung herzustellen
Gastgeber. Die Entscheidung, ob „xrsh host xterm“ oder „xrlogin host“ verwendet werden soll, sollte darauf basieren
auf mehreren Faktoren. Wenn X auf dem Remote-Host oder dem lokalen Terminalemulator nicht verfügbar ist
hat bessere Funktionen, verwenden Sie xrlogin. Generell empfiehlt der Autor die Verwendung von xrsh over
xrlogin in den meisten Situationen.

Wenn der auf dem Remote-Host auszuführende Befehl ein xterm ist, übergibt xrsh automatisch den
-name-Argument für xterm mit dem Wert „xterm-hostname“, wobei hostname der Name des ist
Remote-Host. Dadurch kann der Benutzer Ressourcen im Ressourcenmanager seines Servers angeben
die spezifisch für xterms von einem bestimmten Host sind. Diese Funktion kann beispielsweise dazu genutzt werden
Stellen Sie sicher, dass alle xterm-Fenster eines bestimmten Remote-Hosts dieselbe Farbe haben oder eine bestimmte Schriftart verwenden
oder an einer bestimmten Stelle auf dem Bildschirm starten. Xrlogin übergibt dieselbe Zeichenfolge, also sind sie es
diesbezüglich kompatibel. Diese Funktion kann durch Angabe Ihres eigenen Namens überschrieben werden
Argument in der xterm-Befehlszeile.

Wenn der auf dem Remote-Host auszuführende Befehl ein xterm ist, gibt xrsh dies als Standard an
Der Titel für das neue xterm lautet „xterm@hostname“, wobei hostname der Name der Fernbedienung ist
Gastgeber. Dies kann auch überschrieben werden, indem Sie Ihr eigenes Argument -title im xterm angeben
Befehlszeile.

Xrsh achtet sehr darauf, keine zusätzlichen Prozesse lokal oder remote zu belassen
Die Maschine wartet darauf, dass der Client beendet wird. In einigen abgelegenen Umgebungen (insbesondere
Bei einigen Sys-V-Implementierungen von csh und rsh ist dies nicht möglich und xrsh sollte als ausgeführt werden
Hintergrundbefehl.

OPTIONAL

Beachten Sie, dass xrsh-Optionen dem angegebenen X-Befehl und seinen Argumenten vorangestellt sind.

-auth Authentifizierungstyp
Wählen Sie aus, welche Art von X-Autorisierung (oder Zugriffskontrolle) verwendet werden soll.
Der Authentifizierungstyp kann „xhost“, „xauth“, „xhost-xterminal“, „environment“ oder sein
"keiner". Der Standardwert ist xhost, der Standardwert kann jedoch durch Festlegen des Werts von festgelegt werden
die Umgebungsvariable $XRSH_AUTH_TYPE.

Wenn xhost angegeben ist und der X-Server auf dem lokalen Computer ausgeführt wird, wird xhost dies tun
lokal ausgeführt werden, damit der Remote-Host eine X-Verbindung öffnen kann. Wenn der Server ist
auf einem dritten Host (nicht dem, auf dem xrsh läuft und nicht dem, auf dem Sie möchten).
Um den Befehl auszuführen, wird rsh verwendet, um xhost auf dem zu autorisierenden Serverhost auszuführen
Der Host, auf dem der Befehl ausgeführt wird.

Wenn xauth angegeben ist, führt xrsh die Einträge für den Server aus dem zusammen
Fügen Sie die lokale $XAUTHORITY-Datei mithilfe von rsh in die Datei des Remote-Hosts ein.

Der Authentifizierungstyp xhost-xterminal ist für die Verwendung durch Benutzer von X-Terminals gedacht. Wenn
Wenn xhost-xterminal verwendet wird, wird xrsh beim ersten Ausführen von xhost lokal ausgeführt
Aktivieren Sie den Remote-Host für den Zugriff. Dies sollte funktionieren, da (theoretisch) die
Die erste Ausführung erfolgt auf dem XDMCP-Host für das X-Terminal. Von da an
gibt den Namen dieses Hosts über die Umgebungsvariable an alle Remote-Hosts weiter
$XHOST. Bei nachfolgenden Aufrufen von Remote-Hosts verwendet xrsh rsh, um eine Verbindung herzustellen
den Host $XHOST und führen Sie xhost aus, um neue Remote-Hosts zu aktivieren.

Authtype „none“ führt keine explizite Arbeit für die Zugriffskontrolle durch. Verwenden Sie dies, wenn Sie dies nicht tun
Aktivieren Sie die Zugriffskontrolle oder verwenden Sie einen anderen Mechanismus zur Zugriffskontrolle.

Schließlich gibt Authtype „environment“ die Umgebungsvariable automatisch weiter
$XAUTHORITY an Remote-Hosts senden, vorausgesetzt, es handelt sich um einen NFS-gemounteten Speicherort, der dies kann
von allen Hosts aus zugänglich sein.

-debuggen Normalerweise leitet xrsh die Standardeingabe und die Standardausgabe in einem nach /dev/null um
Versuch, nicht benötigte RSHD- und Shell-Prozesse zum Beenden zu bringen. Infolgedessen der Benutzer
Normalerweise werden keine Fehler angezeigt, die auftreten könnten (z. B. „Berechtigung verweigert“)
rsh). Wenn Sie Probleme haben, xrsh mit einem Remote-Host zum Laufen zu bringen, versuchen Sie es
Geben Sie den Schalter -debug an, um zu sehen, ob Fehler generiert werden.

-debug2
Dieser Schalter bewirkt, dass xrsh die Option -x in der Shell aktiviert, damit der Benutzer dies tun kann
Sehen Sie sich jeden von xrsh ausgeführten Shell-Befehl an. Verwenden Sie dieses Skript nur, wenn Sie es sind
Debuggen des XRSH-Codes selbst.

-Hilfe Drucken Sie die Argumentliste in die Standardausgabe aus.

-l Benutzername
Verwenden Sie den Schalter -l, um einen anderen Benutzernamen anzugeben, der für die Anmeldung über rsh on verwendet werden soll
der Remote-Host.

-e rshprog
Mit dem Schalter -e kann ein anderes Remote-Shell-Programm eingestellt werden, z. B. ssh. Der
Der Standardwert ist je nach System remsh oder rsh. Dieses Flag überschreibt $XRSH_RSH.

-bestehen envlist
Envlist ist eine durch Anführungszeichen getrennte Zeichenfolge, die einen beliebigen Satz von Umgebungen benennt
Variablen zur Weitergabe an die Shell-Umgebung auf dem Remote-Host. Wenn man wollte
Setzen Sie $XRSH_AUTH_TYPE und $XAUTHORITY auf den Remote-Host. Man könnte Folgendes verwenden: -pass
„XRSH_AUTH_TYPE XAUTHORITY“. Ein Standardsatz von zu übergebenden Umgebungsvariablen kann sein
Wird mithilfe der Umgebungsvariablen $XRSH_ENVS_TO_PASS festgelegt.

-Bildschirm Bildschirm-#
Geben Sie einen anderen Bildschirm auf dem Server an, auf dem der Remote-Client angezeigt werden soll.

-Ausführung
Versionsinformationen ausdrucken und beenden.

Die Umgebungsvariablen XRSH_AUTH_TYPE und XRSH_ENVS_TO_PASS, die zum Setzen verwendet werden können
Schalterstandards werden überschrieben, wenn auch der entsprechende Schalter angegeben wird.

XAUTHORITÄT
Die Umgebungsvariable $XAUTHORITY wird an den Remote-Host übergeben, wenn der Authtype
angegeben durch -auth oder $XRSH_AUTH_TYPE ist „Umgebung“.

XRSH_AUTH_TYPE
Mit dieser Umgebungsvariablen kann der Standardtyp der Autorisierung angegeben werden
oder Zugangskontrolle. Die Werte, auf die es eingestellt werden kann, sind die gleichen wie die Werte für
Argument -auth.

XRSH_RSH
Diese Variable kann das zu verwendende Remote-Shell-Programm neu definieren, z. B. ssh.

XRSH_RSH_ERRORS
Wenn die Umgebungsvariable XRSH_RSH_ERRORS auf den Namen einer Datei gesetzt ist, kann jeder rsh
Fehler werden in dieser Datei auf dem Remote-Host angezeigt. Wenn diese Variable nicht gesetzt ist,
Fehlermeldungen werden verworfen, es sei denn, der Schalter -debug ist angegeben. (Hinweis: nicht
Verwenden Sie „~“ im Dateinamen, da es auf dem lokalen Host zu „~“ erweitert wird, aber versuchen Sie, es einzufügen
die Fehler in dieser Datei auf dem Remote-Host.)

XRSH_ENVS_TO_PASS

COMMON PROBLEME

Stellen Sie sicher, dass Ihre PATH-Umgebungsvariable auf dem Remote-Host in Ihrer .cshrc-Datei festgelegt ist
.bashrc, damit RSH-Programme Zugriff darauf haben. (/ Bin / sh und /bin/ksh-Benutzer haben es schwer
time time hier, da ihre Shells keine Init-Dateien unter rsh ausführen. Du kannst den ... benutzen
Umgebungsvariable XRSH_ENVS_TO_PASS, um die Umgebungsvariable PATH an die Fernbedienung zu übergeben
Gastgeber. Optional können Sie in diesem Fall einen vollständigen Pfad zu xrsh eingeben. (z. B. xrsh remote-
Host /usr/bin/X11/xterm))

Stellen Sie sicher, dass Ihre PATH-Umgebungsvariable auf dem Remote-Host das Verzeichnis enthält
enthält die X-Programme. Dies ist häufig /usr/bin/X11 oder /usr/local/bin/X11.

Stellen Sie sicher, dass Sie rsh für die Arbeit auf dem Remote-Host konfiguriert haben. Sie können dies testen, indem Sie
Geben Sie Folgendes ein: rsh remote-host echo '$PATH' Dies wird beweisen, dass rsh funktioniert, und Ihnen den PATH anzeigen
die auf dem Remote-Host verwendet wird. Wenn die Meldung „Berechtigung verweigert“ angezeigt wird. Sie brauchen wahrscheinlich
um deine zu aktualisieren ~/.rhosts Datei auf dem Remote-Host. Sehen rlogin(1).

Beispiele:

xrsh yoda
Starten Sie ein xterm auf dem Host yoda, das auf dem aktuellen X-Server angezeigt wird. Verwenden Sie xhost
zur Zugangskontrolle.

xrsh -auth xauth Underdog Emacs
Starten Sie einen Emacs für den Host-Außenseiter. Dazu xauth-Berechtigungseinträge zusammenführen
Server in die Autoritätsdatei auf dem Remote-Host.

xrsh -l mjd -auth none -pass XRSH_AUTH_TYPE -debug tigger xterm -fn 5x7
Starten Sie ein xterm auf dem Host-Tigger in einer sehr kleinen Schriftart und verbreiten Sie es in der Umgebung
Variable $XRSH_AUTH_TYPE zum Remote-Host, melden Sie sich mit der ID beim Remote-Host an
„mjd“, führen Sie keine spezifische Autorisierung durch und leiten Sie die Standard-/Fehlerausgabe nicht um
nach /dev/null, damit ich etwaige Fehler sehen kann.

Verwenden Sie xrsh online über die Dienste von onworks.net