Este es el comando xrsh que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
xrsh: inicia un programa X en una máquina remota
SINOPSIS
xrsh [ -ayuda ] [ -versión ] [ -l nombre de usuario ] [ -e rshprog ] [ -autorización Tipo de autenticación ] [ -pantalla
pantalla-# ] [ -pasar lista de env ] [ -depurar ] [ -depurar2 ] servidor remoto [ Comando X [ argumentos
... ] ]
DESCRIPCIÓN
xrsh ejecuta el comando X dado en un host remoto. Establece el entorno para eso
comando de modo que muestre sus ventanas en la pantalla del servidor actual por
propagando la variable de entorno $ DISPLAY. Si no se especifica, el cliente predeterminado es
xterm. Xrsh selecciona automáticamente ssh(1) rsh(1) remiendo(1) o rcmd(1) para ejecutar remoto
comandos, dependiendo de lo que esté disponible en el entorno O / S.
Xrsh maneja automáticamente la autenticación para que el cliente remoto pueda
abrir ventanas en el servidor. Lo hace de varias formas diferentes dependiendo del valor
de la variable de entorno $ XRSH_AUTH_TYPE o el argumento -auth.
De forma predeterminada, xrsh utilizará xhost para permitir que el cliente remoto abra una conexión de servidor.
También se le puede decir que use xauth para fusionar claves locales en un archivo de autorización remoto.
O puede pasar la variable de entorno $ XAUTHORITY al host remoto para compartir una
archivo de autoridad común montado en NFS. También se le puede indicar que no haga nada en el caso
donde no es necesaria una autorización explícita.
Los usuarios que solo quieren una ventana de terminal remota pueden mirar el comando hermano de xrsh,
xrlogin(1). Xrlogin usa un xterm que se ejecuta localmente para abrir una conexión rlogin a un control remoto
anfitrión. La decisión sobre si utilizar "xrsh host xterm" o "xrlogin host" debe basarse
en varios factores. Si X no está disponible en el host remoto o en el emulador de terminal local
tiene mejores características, use xrlogin. En general, el autor recomienda usar xrsh en lugar de
xrlogin en la mayoría de situaciones.
Si el comando para ejecutar en el host remoto es un xterm, xrsh pasa automáticamente el
-name argumento a xterm con un valor de "xterm-hostname" donde hostname es el nombre del
servidor remoto. Esto permite al usuario especificar recursos en el administrador de recursos de su servidor.
que son específicos de xterms de un host determinado. Por ejemplo, esta función se puede utilizar para
hacer que todas las ventanas xterm de un host remoto dado sean del mismo color o usar una fuente específica
o iniciar en un lugar específico de la pantalla. Xrlogin pasa la misma cadena para que sean
compatible en este sentido. Esta función puede anularse especificando su propio nombre.
argumento en la línea de comando xterm.
Si el comando para ejecutar en el host remoto es un xterm, xrsh especifica que el
el título para el nuevo xterm será "xterm @ hostname" donde hostname es el nombre del control remoto
anfitrión. Esto también se puede anular especificando su propio argumento -title en el xterm
línea de comando.
Xrsh tiene mucho cuidado de no dejar ningún proceso adicional en el local o remoto
máquina esperando a que el cliente salga. En algunos entornos remotos (particularmente
algunas implementaciones Sys V de csh y rsh), esto es imposible y xrsh debe ejecutarse como un
comando de fondo.
CAMPUS
Tenga en cuenta que las opciones xrsh preceden al comando X dado y sus argumentos.
-autorización Tipo de autenticación
Elija qué tipo de autorización X (o control de acceso) se utilizará.
El tipo de autenticación puede ser "xhost", "xauth", "xhost-xterminal", "environment" o
"ninguno". El valor predeterminado es xhost, pero el valor predeterminado se puede establecer estableciendo el valor de
la variable de entorno $ XRSH_AUTH_TYPE.
Si se especifica xhost y el servidor X se está ejecutando en la máquina local, xhost
se ejecutará localmente para permitir que el host remoto abra una conexión X. Si el servidor es
en un tercer host (no en el que se está ejecutando xrsh ni en el que desea
para ejecutar el comando), rsh se utilizará para ejecutar xhost en el host del servidor para autorizar
el host donde se ejecutará el comando.
Si se especifica xauth, entonces xrsh fusionará las entradas para el servidor desde el
local $ XAUTHORITY en el del host remoto usando rsh.
El authtype xhost-xterminal está diseñado para que lo utilicen personas que utilicen terminales X. Si
se usa xhost-xterminal, luego, la primera vez que se ejecuta xrsh, ejecuta xhost localmente para
habilite el host remoto para el acceso. Esto debería funcionar ya que (teóricamente) el
la primera vez que se ejecuta es en el host XDMCP para el terminal X. A partir de entonces
propaga el nombre de ese host a todos los hosts remotos a través de la variable de entorno
$ XHOST. En invocaciones posteriores desde hosts remotos, xrsh usa rsh para conectarse a
el host $ XHOST y ejecute xhost para habilitar nuevos hosts remotos.
Authtype "none" no funciona explícitamente para el control de acceso. Usa esto si no lo haces
habilite el control de acceso o si utiliza otro mecanismo para el control de acceso.
Por último, authtype "environment" propaga automáticamente la variable de entorno
$ XAUTHORITY a hosts remotos, asumiendo que es una ubicación montada en NFS que puede
se puede acceder desde todos los hosts.
-depurar Normalmente, xrsh redirige la entrada y la salida estándar a / dev / null en un
Esfuerzo para hacer que los procesos rshd y shell innecesarios salgan. Como resultado, el usuario
por lo general, no puede ver los errores que puedan ocurrir (como un "Permiso denegado" de
rsh). Si tiene problemas para hacer que xrsh funcione con un host remoto, intente
dando la opción -debug para ver si se están generando errores.
-depurar2
Este modificador hace que xrsh active la opción -x en el shell para que el usuario pueda
vea cada comando de shell ejecutado por xrsh. Utilice este script solo si está
depurando el propio código xrsh.
-ayuda Imprima la lista de argumentos en la salida estándar.
-l nombre de usuario
Utilice el modificador -l para especificar un nombre de usuario diferente a utilizar para iniciar sesión a través de rsh en
el host remoto.
-e rshprog
El modificador -e se puede utilizar para configurar un programa de shell remoto diferente, por ejemplo, ssh. los
el valor predeterminado es remsh o rsh, dependiendo de su sistema. Esta bandera anula $ XRSH_RSH.
-pasar lista de env
Envlist es una cadena delimitada por comillas que nombra un conjunto arbitrario de entorno
variables para pasar al entorno de shell en el host remoto. Si uno quisiera
establecer $ XRSH_AUTH_TYPE y $ XAUTHORITY en el host remoto, se podría usar: -pass
"XRSH_AUTH_TYPE XAUTHORITY". Un conjunto predeterminado de variables de entorno para pasar puede ser
establecer utilizando la variable de entorno $ XRSH_ENVS_TO_PASS.
-pantalla pantalla-#
Especifique una pantalla diferente en el servidor en la que mostrar el cliente remoto.
-versión
Imprima la información de la versión y salga.
MEDIO AMBIENTE
Las variables de entorno XRSH_AUTH_TYPE y XRSH_ENVS_TO_PASS que se pueden utilizar para establecer
los valores predeterminados del conmutador se anulan si también se especifica el conmutador equivalente.
AUTORIDAD
La variable de entorno $ XAUTHORITY se pasa al host remoto si el authtype
especificado por -auth o $ XRSH_AUTH_TYPE es "entorno".
XRSH_AUTH_TYPE
Esta variable de entorno se puede utilizar para especificar el tipo de autorización predeterminado
o control de acceso. Los valores que se pueden establecer son los mismos que los valores para el
argumento -auth.
XRSH_RSH
Esta variable puede redefinir el programa de shell remoto que se utilizará, por ejemplo, ssh.
XRSH_RSH_ERRORS
Si la variable de entorno XRSH_RSH_ERRORS se establece en el nombre de un archivo, cualquier rsh
aparecerán errores en ese archivo en el host remoto. Si esa variable no está configurada,
los mensajes de error se descartarán a menos que se proporcione la opción -debug. (Nota: no
use ~ en el nombre del archivo porque se expandirá a ~ en el host local, pero intente poner
los errores en ese archivo en el host remoto.)
XRSH_ENVS_TO_PASS
COMÚN PROBLEMAS
Asegúrese de que su variable de entorno PATH en el host remoto esté configurada en su .cshrc o
.bashrc para que los programas rsh tengan acceso a él. (/ Bin / sh y los usuarios de / bin / ksh tienen dificultades
tiempo aquí ya que sus shells no ejecutan ningún archivo de inicio bajo rsh. Puedes usar el
Variable de entorno XRSH_ENVS_TO_PASS para pasar la variable de entorno PATH al control remoto
anfitrión. Opcionalmente, puede escribir una ruta completa a xrsh en ese caso. (Por ejemplo, xrsh remoto-
host / usr / bin / X11 / xterm))
Asegúrese de que su variable de entorno PATH en el host remoto incluya el directorio
que contiene los programas X. Suele ser / usr / bin / X11 o / usr / local / bin / X11.
Asegúrese de tener rsh configurado para funcionar en el host remoto. Puedes probar esto por
escribiendo: rsh remote-host echo '$ PATH' Esto demostrará que rsh funciona y le mostrará la RUTA
que se utilizará en el host remoto. Si obtiene "Permiso denegado". probablemente necesites
para actualizar tu ~ / .rhosts archivo en el host remoto. Ver iniciar sesión(1).
EJEMPLOS
xrsh yoda
Inicie un xterm en el yoda del host que se muestra en el servidor X actual. Utilice xhost
para control de acceso.
xrsh -auth xauth desvalido emacs
Inicie un emacs en el host desvalido. Fusionar entradas de autorización de xauth para esto
servidor en el archivo de autoridad en el host remoto.
xrsh -l mjd -auth ninguno -pass XRSH_AUTH_TYPE -debug tigger xterm -fn 5x7
Inicie un xterm en el host tigger en una fuente muy pequeña, propague el entorno
variable $ XRSH_AUTH_TYPE al host remoto, inicie sesión en el host remoto usando el id
"mjd", no realice ninguna autorización específica y no redirija la salida estándar / de error
a / dev / null para que pueda ver los errores.
Use xrsh en línea usando los servicios de onworks.net
