Acabo de enviar ssh-ed a algún servidor remoto y descubrí que stdout y stderr de todos los comandos/procesos que intento ejecutar en bash se redirigen a algún lugar. lo tanto, tengo siguientes preguntasCómo redireccionar stdout, stderr a/dev/tty
Cómo detectar:
1) ¿Qué archivo stdout, stderr esta en buen estado reencaminado en Linux?
y
2) ¿Y cómo redireccionar de forma predeterminada stdout y stderr de nuevo a/dev/tty?
Gracias de antemano.
Un comando que debe hacer literalmente lo que solicitó en (2) es
exec >/dev/tty 2>&1
Pero sospecho que su análisis del problema es incorrecta. Sería útil ver el resultado de ssh -v ... (donde ... son los argumentos que haya escrito en el comando original ssh).
añadiendo esto a mi bucle de gestión de la horquilla fue el truco para restablecer la salida estándar. Estaba grabando, ejecutando una pantalla y ejecutando una secuencia de comandos de perching de parches USB, dentro de los cuales las nuevas líneas empezaron a actuar como un salto de carro a la siguiente línea sin regresar. Mucho gracias por señalar este comando. –
Solo se puede hacer si su caparazón anhelante se inicia con una tubería al comando tee con otra consola como parámetro.
Déjame explicarte.
Si está iniciando sesión en /dev/tty1 y alguien más está iniciando sesión en /dev/tty2. Si inicia su shell (bash) siguiendo el comando, todo STDOUT/STDERR se redireccionará/copiará a otro shell (/dev/tty2 en este caso).
bash 2>&1 | tee /dev/tty2
Así, alguien sentado en /dev/tty2 verá toda su actividad.
Si alguien inicia el shell es /bin/bash 2>&1 | tee /dev/tty2 en lugar de /bin/bash Sucederá cada vez que inicie sesión. Pero no estoy seguro de que el shell de inicio de sesión se pueda establecer de esa manera.
Si alguien reencamina toda la salida de su caparazón de esta forma, puede verificarlo simplemente marcando si se está ejecutando tee en segundo plano.
ps ax | grep tee
Este algo es la salida como
tee /dev/tty2
El comando:
ls -l /proc/$$/fd/{1,2}
le qué archivos están abiertos como (descriptor de archivo 1) stdout y stderr mostrar (descriptor de archivo 2) .
¡muy bueno! alguna idea de cómo relacionar ex .: '1 -> pipe: [16418291]' a un pid? –
Acabo de encontrar, en/proc, el otro pid con esto! '0 -> pipe: [16418291]' –
La respuesta a su primera pregunta se puede encontrar en /proc/self/fd. Contiene enlaces simbólicos a los archivos (u otras cosas, tuberías, conectores, etc.) a los que está conectada su instancia de bash.
[email protected]:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 May 21 02:18 0 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 1 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15529/fd/
[email protected]:~# ls -l /proc/self/fd < /dev/null
total 0
lr-x------ 1 root root 64 May 21 02:18 0 -> /dev/null
lrwx------ 1 root root 64 May 21 02:18 1 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15536/fd/
[email protected]:~# ls -l /proc/self/fd | cat
total 0
lrwx------ 1 root root 64 May 21 02:18 0 -> /dev/pts/3
l-wx------ 1 root root 64 May 21 02:18 1 -> pipe:[497711]
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15537/fd/
[email protected]:~#
En el primer ejemplo, se puede ver los 3 primeros descriptores de archivos (que son el estándar de salida, de entrada, y el error, respectivamente), apuntan a mi pseudo-terminal /dev/pts/3. En el segundo ejemplo, he redirigido la entrada a /dev/null, por lo que el descriptor de archivo de entrada estándar apunta a /dev/null. Y en el último ejemplo he enviado la salida de ls a cat a través de una tubería, y el descriptor de archivo de entrada estándar refleja esto. Hasta donde yo sé, no hay forma de encontrar qué proceso tiene el otro extremo de la tubería. En todos los ejemplos, hay un cuarto descriptor de archivo que representa el identificador que ls tiene para leer /proc/self/fd. En este caso, dice /proc/15537 porque /proc/self es de hecho un enlace simbólico a /proc/pid donde pid es el PID del proceso que accede a /proc/self.
¿Cómo lo descubrió? –
simplemente escribiendo comandos que deberían enviarse a STDOUT y STDERR. – Sergey
¿Hay algo relevante en .bashrc? –