Ejecutar comando en terminal activo remoto

Supongamos que tiene un emulador de terminal (T1) abierto con un PID de 6350.

Desde otro terminal, escriba este comando (C1):

echo "ls\n" > /proc/6350/fd/0

Esto escribe lsy la nueva línea en T1 pero no la ejecuta. ¿Por qué?

También intenté usar cat|bashcon echo "ls\n" > /proc/catid/fd/0pero todavía no se ejecuta.

¿Cómo puedo hacer eco del comando en otro terminal y ejecutar el comando?

posible respuesta :

$ mkfifo toto;
$ bash < toto;
$ echo "ls" > toto;

En este caso, no puede escribir más directamente en la terminal (todo se muestra de la misma manera que el comando (C1) muestra la cosa en esta terminal.

— rvlander
fuente

stackoverflow.com/questions/3846033/…

— rush

Lo leí, pero no es muy útil.

— rvlander

Puede que no sea "útil" como para darle una forma de hacerlo, pero responde a su pregunta: no puede. Puede decirnos el objetivo final que está tratando de lograr y ver si hay otra forma.

— Kevin

Ok, no puedes, pero ¿por qué el texto se muestra en la otra terminal?

— rvlander

porque envías el texto a la interfaz del terminal, no al shell.

— prisa

Respuestas:

Hay una utilidad de línea de comando llamada ttyechoque puede enviar un comando a otro terminal (tty / pts) y ejecutar el comando.

sudo ttyecho -n /dev/pts/5 ls

Consulte: Utilidad para enviar comandos o datos a otros terminales (tty / pts)

Ver también: ttyechocódigo fuente en github .

Otro comando interesante de tty es selectorun comparador de patrones interactivo en tiempo real en la consola que actualiza el búfer de entrada tty.

# selector examples
selector -v -x @ <(find . -maxdepth 2 -type d | awk '{print $0"@cd "$0}')
selector -v -x @ <(grep -E -o 'http[^ ]+' fileWithURLS)

Ver: selector - BÚSQUEDA DINÁMICA EN CONSOLA

— Chad
fuente

Lamentablemente, el enlace al ttyechocódigo fuente en github parece estar roto. Sin embargo, parece estar disponible en github.com/osospeed/ttyecho en su lugar, ahora.

— Wilson F

Cuando se emite una escritura en /dev/pts/X( /proc/6350/fd/0, 1y 2es sólo un enlace simbólico a eso), lo que ocurre es exactamente lo mismo que ocurre cuando el proceso 6350(o uno de sus hijos, de manera adecuada en forma de tenedor) salidas de algo: se escribe en el terminal.

Si intentas leer desde ese dispositivo ( cat < /dev/pts/X), sucederán cosas funky. Debería ver aparecer las cosas que escribe en el shell original. (Muy posiblemente solo después de la primera línea nueva que escribió; supongo que el programa del terminal ( xtermo lo que sea que esté usando) hace un búfer de línea, y el 6350shell que estaba bloqueado readobtiene esa pieza; entonces puede que el shell o no, ganar las lecturas posteriores, pero bien podría estar completamente equivocado en esto).

La cuestión es: cuando lees o escribes en ese dispositivo, no estás hablando con el otro shell que lo está usando. Estás hablando con el emulador de terminal ( xtermpor ejemplo). Solo el emulador de terminal puede inyectar datos en ese canal (lo que lee el shell), y todo lo que escribe el shell va al terminal. Adjuntar un segundo caparazón no cambia eso.

Si desea inyectar comandos en ese 6530proceso, tendrá que hacerlo a través del terminal (ya sea una aplicación X11 o alguna otra cosa).

— Estera
fuente

Curiosamente, al leer los pts ( cat /dev/pts/xno es necesario <), las letras se alternan estrictamente entre los terminales.

— Kevin

No usar la redirección probablemente no cambie mucho. Obtengo resultados no predecibles de cualquier manera.

— Mat

Interesante, gracias por el enlace. Entonces, /proc/6350/fd/0es un enlace simbólico al stdin padre del process 6350cual es un terminal. ¿Supongo que es lo mismo para las aplicaciones con ventana?

— rvlander