Eseguire il comando nel terminale attivo remoto

Supponiamo di avere un emulatore di terminale (T1) aperto con un PID di 6350.

Da un altro terminale, digitare questo comando (C1):

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

Questo scrive lse la nuova riga in T1 ma non la esegue. Perché?

Ho anche provato a usare cat|bashcon echo "ls\n" > /proc/catid/fd/0ma non è ancora stato eseguito.

Come posso ripetere il comando in un altro terminale e far eseguire il comando?

possibile risposta:

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

In questo caso non è più possibile scrivere direttamente nel terminale (tutto viene visualizzato nello stesso modo in cui il comando (C1) mostra cosa in questo terminale.

— rvlander
fonte

stackoverflow.com/questions/3846033/…

— rush

L'ho letto, ma non è molto utile.

— rvlander,

Potrebbe non essere "utile" come darti un modo per farlo, ma risponde alla tua domanda: non puoi. Potresti dirci l'obiettivo finale che stai cercando di raggiungere e vedere se c'è un altro modo.

— Kevin,

Ok non puoi ma allora perché il testo viene visualizzato nell'altro terminale?

— rvlander,

perché si invia il testo all'interfaccia del terminale, non alla shell.

— corsa

Risposte:

Esiste un'utilità della riga di comando chiamata ttyechoche può inviare un comando a un altro terminale (tty / pts) e far eseguire il comando.

sudo ttyecho -n /dev/pts/5 ls

Vedere: Utilità per inviare comandi o dati ad altri terminali (tty / pts)

Vedi anche: ttyechocodice sorgente su github .

Un altro comando tty interessante è selector, un matcher di pattern interattivo in tempo reale nella console che aggiorna il buffer di input tty.

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

Vedi: selettore - RICERCA DINAMICA IN CONSOLLE

— chad
fonte

Purtroppo, il collegamento al ttyechocodice sorgente su github sembra essere rotto. Tuttavia, ora sembra essere disponibile su github.com/osospeed/ttyecho .

— Wilson F,

Quando si emette una scrittura a /dev/pts/X( /proc/6350/fd/0, 1e 2è solo un link simbolico a quello), ciò che accade è esattamente la stessa cosa che succede quando processo 6350(o uno dei suoi figli, opportunamente biforcuta) uscite qualcosa: si scrive al terminale.

Se provi a leggere da quel dispositivo ( cat < /dev/pts/X), accadranno cose funky. Dovresti vedere le cose che scrivi nella shell originale mostrate. (Molto probabilmente solo dopo la prima nuova riga che hai digitato - Immagino che il programma terminale ( xtermo qualunque cosa tu stia usando) fa un buffering di linea, e la 6350shell su cui è stato bloccato readottiene quel pezzo; quindi o shell potrebbe, o potrebbe no, vinci le letture successive, ma potrei benissimo sbagliarmi al riguardo.)

Il fatto è: quando leggi o scrivi su quel dispositivo, non stai parlando con l'altra shell che lo sta usando. Stai parlando con l'emulatore di terminale ( xtermad esempio). Solo l'emulatore di terminale può inserire dati in quel canale (ciò che legge la shell) e tutto ciò che la shell scrive va al terminale. Collegare una seconda shell non cambia questo.

Se vuoi inserire comandi in quel 6530processo, dovrà farlo tramite il terminale (che sia un'app X11 o qualcos'altro).

Lettura consigliata: qual è la differenza esatta tra un "terminale", una "shell", una "tty" e una "console"?

— Stuoia
fonte

È interessante notare che, leggendo dai punti ( cat /dev/pts/x, non è necessario <), le lettere si alternano strettamente tra i terminali.

— Kevin,

Non usare il reindirizzamento probabilmente non cambia molto. Ottengo risultati non prevedibili in entrambi i casi.

— Mat

Interessante, grazie per il link. Quindi /proc/6350/fd/0è un collegamento simbolico al genitore stdin di process 6350cui è un terminale. Immagino sia lo stesso per le applicazioni con finestre?

— rvlander,