Puncte:1

Rulați comanda pe alt terminal existent

drapel ru

Să presupunem că există două terminale 0 și 1. Ce comandă ar trebui să introduc la terminalul 0

pentru a face terminalul 1 să execute comanda.

Cunoscut: {comandă} > /dev/pts/1 nu funcționează. comanda este executată pe terminalul 0

și redirecționați rezultatul către terminal la terminalul 1.

Cas avatar
drapel in
Cas
De ce ai vrea asta? Nu contează în ce terminal executați o comandă. Veți obține același rezultat, așa că de ce l-ați dori în două terminale? Și de ce să rulați comanda de la terminalul 0 și să o executați în terminalul 1, în timp ce ați putea executa și comanda în terminalul 0.
王柏翔 avatar
drapel ru
Pentru că vreau să obțin informații despre terminalul 1, cum ar fi pwd, istoric,...
Nate T avatar
drapel it
Există un singur istoric pentru toate instanțele bash, situat la `~/.bash-history` și chiar și acesta este delicat. Îi place să aleagă și să aleagă la ce comenzi salvează
Nate T avatar
drapel it
Da, ai nevoie de tmux. Problema dvs. este motivul pentru care a fost creat tmux. Sesiunile au venit mai întâi, înainte de divizări, etc. doar pentru a rezolva problema mai multor utilizatori care au nevoie să acceseze același mediu shell în același timp, dar din locații diferite.
Puncte:0
drapel it

Puteți face acest lucru cu tmux. Când începeți o sesiune în terminalul A, va exista un număr întreg învelit între acolade în colțul din stânga jos al ferestrei. Acesta este ID-ul sesiunii.

Dacă apoi lansați terminalul B, puteți lansa comanda

atașare tmux [id]

Unde id este numărul de la terminalulA, veți putea controla acel terminal de la oricare terminal.

Cu toate acestea, dacă faceți doar pașii anteriori, veți pierde terminalul A. Există câteva soluții convenabile aici. Pentru unul, dacă înfășurați atașați comanda, urmată de && țintă-comandă între paranteze, le puteți rula într-un subshell. Teoretic, rezultatul acelor comenzi nu ar trebui să aibă niciun efect asupra mediului shellB. Acestea fiind spuse, atunci când rezultatul acestei comenzi este în mod normal de a distruge shellB, am putut vedea că este lovit sau ratat.

O altă opțiune este să rulați comanda într-un proces separat cu & operator astfel:

some-terminalB-command & tmux atașează [id] && terminalA-command

În această metodă am puțin mai multă încredere. Totuși, putem face mai bine:

some-terminalB-comandă & (tmux atașează [id] && terminalA-comandă)

Aceasta folosește ambele metode, astfel încât atașați este îndepărtat de două ori din shellB.

王柏翔 avatar
drapel ru
Mulțumesc pentru sugestie. Încerc să știu despre tmux, cred că tmux poate obține informații între sesiunile tmux. Cu toate acestea, vreau să primesc informații despre terminal ori de câte ori pornește, nu numai aceste terminale folosind comanda tmux.
Nate T avatar
drapel it
Sry, de aceea insistăm mereu pentru mai mult context în întrebare. Cu cât adăugați mai mult context (de exemplu, de ce încercați să faceți x, orice detalii conexe), cu atât este mai puțin probabil să vedeți răspunsuri care nu sunt utile și cu atât este mai probabil să obțineți răspunsuri utile „din cutie” care privesc întreaga situație dintr-un unghi diferit și rezolvă problema fără a răspunde direct la întrebare. Uneori nu există un răspuns direct, dar există întotdeauna o soluție. : ) Voi vedea dacă nu pot veni cu altceva pentru tine.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.