Bonjour,
Je cherche à envoyer une commande d’un terminal vers un autre.
J’ai cherché sur internet mais je trouve que l’envoie du résultat de la commande.
Du coup, je doute que ca soit possible.
Cordialement
Cambech
Bonjour,
Je cherche à envoyer une commande d’un terminal vers un autre.
J’ai cherché sur internet mais je trouve que l’envoie du résultat de la commande.
Du coup, je doute que ca soit possible.
Cordialement
Cambech
Pourriez-vous préciser ? Il y a tant de manières d’interpréter cette phrase.
Si je dis : je cherche à envoyer une commande d’une nouvelle batterie (pour mon portable Clevo), on imagine que le lecteur voit de quoi il retourne.
Dans votre cas, il semblerait que vous vouliez lancer une commande depuis un terminal et que cette commande soit interprétée « par un autre ». Un autre quoi ?
Si c’est un autre système, pourrait-on en savoir plus sur le type de système et si vous pouvez vous identifier sur cet autre système (si vous avez un compte ).
Un cas typique et simple serait
ssh -v utilisateur@ditant id
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
" On demande cheval sérieux connaissant bien Paris pour faire livraison tout seul. "
Petites annonces de l’os à moelle
carrément j’étais encore en train de chercher comment répondre sans me montrer tatillon ou style condescendant …
l’usage de stdin dans le titre suggère qu’un terminal attendrait en entrée une commande qu’il saurait interpréter (le tout avec les mains dans le dos) …
si on imagine qu’un terminal écoute et visualise des événements qui se passe ailleurs, à la manière de
$ sudo dmesg --follow
c’est parce qu’on lui a demandé de le faire … (exemple sans conviction)
C’est peut-être une ânerie, mais le logiciel «screen» (ou «tmux») n’est-il pas utilisable pour ça?
Écrire dans un terminal,
le détacher
Ouvrir un autre terminal, et attacher l’état du précédent.
Voilà, @Cambech, tu as trois réponses différentes à ta question et aucune n’est hors sujet. Un peu plus de précision sur ton cahier des charges ne fera pas de mal.
et le grand gagnant est … Usinagaz-theReturn… mais pas tout a fait. Bon tachons de répondre plus précisément…
Euh…
Quand on fait un ls > /dev/pts/0
sachant que je suis sur /dev/pts/1
je reçois sur /dev/pts/0 que le resultat de la commande ls.
ça serait bien de savoir comment on fait pour que la commande est envoyer a /dev/pts/X puis exécute soit via un retour à la ligne de la part de la commande envoié soit manuellement.
Heu … c’est crypté la dernière phrase ?
par défaut > est stdout, pas stdin, c’est le flux normal de sortie, que tu rediriges.
c’est 1&
par contre 2& n’est pas le résultat de la commande, mais les erreurs rencontrées par la commande. Suivant la nature de la commande, les deux flux sont mélangés (sauf paramétrage). Mais on peut les dissocier. Je maîtrise pas les flux ou j’ai oublié, et je sais même pas comment être sur /dev/pts/1, ou 0, j’ouvre un terminal quand j’ai besoin et c’est tout
Réexplique un peu ce que tu cherches à faire avec des exemples si possibles (de commandes, et tes souhaits) …
simplement
utilisé terminal 1(T1) pour exécute des commande sur le terminal 2(T2)
car quand je lance ls
sur le T1 sachant que le T1 est dans le dossier /home/user et que le T2 est sur le dossier /bin. je reçois les information de /home/user/* sur le T2. Alors que je veux les information de /bin/*.
après quand tu fais un ls -l | grep rouge
la sortie (stdout pour ls ou l’entrée (pour grep ici stdin pour grep)) de ls -l est retravaillé par grep pour affiché juste les lignes rouges.
en claire
clavier (ls) --> /dev/pts/0 --> visualisation du dossié /home/user
passe en
clavier (ls) --> /dev/pts/0 --> /dev/pts/1 --> visualisation du dossié /bin
Bonjour
Depuis l’interface graphique de l’Environnement de Bureau,
j’ouvre une fenêtre de terminal
et j’identifie le fichier de périphérique esclave (/dev/pts/N
) qui y a été associé :
michel@debT450:~$ tty
/dev/pts/0
michel@debT450:~$
j’ouvre une seconde fenêtre de terminal et j’identifie
le fichier de périphérique esclave qui y a été associé :
michel@debT450:~$ tty
/dev/pts/1
michel@debT450:~$
Depuis la première fenêtre de terminal,
je redirige vers la seconde fenêtre de terminal
le flux STDOUT
des commandes qui seront exécutées dans la première fenêtre de terminal :
exec 1> /dev/pts/1
Et maintenant, le flux de sortie STDOUT
de toutes les commandes
qui seront exécutées par le shell de la première fenêtre de terminal
s’affichera dans la seconde fenêtre de terminal.
Pour que le flux de sortie STDOUT
des lignes de commandes entrées dans la première fenêtre de terminal s’affiche à nouveau dans la première fenêtre de terminal,
depuis cette première fenêtre de terminal j’entre la ligne de commandes suivante :
exec 1> /dev/pts/0
Les variables d’environnement de chacun des shell qui a été lancé dans chaque fenêtre de terminal
sont (heureusement) totalement indépendantes.
Les commandes lancées par un shell utilisent les variables d’environnement
du shell qui exécutera ces commandes.
Si aucun répertoire n’est donné en paramètre à la commande ls
c’est la valeur de la variable d’environnement PWD
qui sera utilisée par défaut.
Pour compléter l’excellente réponse de @MicP, considérons les sorties de commandes suivantes
fp2@debpacha:/data/docs/hedia$ w
21:57:07 up 45 days, 23:59, 16 users, load average: 0,03, 0,06, 0,11
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
fp2 tty2 - 24août20 8:40m 2.34s 2.32s -bash
fp2 tty3 - 24août20 1:07 0.06s 0.00s tmux
fp2 tty4 - 21:49 1:25 0.10s 0.07s -bash
fp2 tty7 :0 07sept.20 46days 3:49m 0.00s /bin/sh /etc/x
fp2 pts/5 tmux(8091).%2 07sept.20 1:07 0.14s 0.14s -bash
fp2 pts/8 tmux(8091).%11 21sept.20 5:31 0.21s 0.21s -bash
fp2 pts/9 tmux(8091).%4 07sept.20 49:29 1.06s 0.02s python3
fp2 pts/11 tmux(8091).%5 07sept.20 4days 0.29s 0.29s -bash
fp2 pts/12 tmux(8091).%6 07sept.20 34:39m 0.28s 0.28s -bash
fp2 pts/13 tmux(8091).%7 08sept.20 0.00s 1.68s 0.00s w
fp2 pts/14 tmux(8091).%8 10sept.20 28:27 1:08 1:08 elinks http://
fp2 pts/3 tmux(8091).%0 07sept.20 5:13 0.10s 0.10s -bash
fp2 pts/4 tmux(8091).%1 07sept.20 17days 0.05s 0.05s -bash
fp2 pts/15 tmux(8091).%9 10sept.20 34:36m 4.38s 4.38s -bash
fp2 pts/16 tmux(8091).%10 13sept.20 48:34 0.96s 0.96s -bash
fp2@debpacha:/data/docs/hedia$
fp2@debpacha:/data/docs/hedia$ who
fp2 tty2 2020-08-24 21:51
fp2 tty3 2020-08-24 22:17
fp2 tty4 2020-10-09 21:49
fp2 tty7 2020-09-07 12:49 (:0)
fp2 pts/5 2020-09-07 12:51 (tmux(8091).%2)
fp2 pts/8 2020-09-21 22:20 (tmux(8091).%11)
fp2 pts/9 2020-09-07 12:58 (tmux(8091).%4)
fp2 pts/11 2020-09-07 14:47 (tmux(8091).%5)
fp2 pts/12 2020-09-07 14:48 (tmux(8091).%6)
fp2 pts/13 2020-09-08 15:11 (tmux(8091).%7)
fp2 pts/14 2020-09-10 12:25 (tmux(8091).%8)
fp2 pts/3 2020-09-07 12:51 (tmux(8091).%0)
fp2 pts/4 2020-09-07 12:51 (tmux(8091).%1)
fp2 pts/15 2020-09-10 18:01 (tmux(8091).%9)
fp2 pts/16 2020-09-13 16:21 (tmux(8091).%10)
fp2@debpacha:/data/docs/hedia$
Sur ce portable, je me suis donc connecté sur tty2 et tty3 (ces consoles à fond noir) le soir du 24 août, et j’ai une session tmux sur tty3 depuis ce moment là.
Avant d’ouvrir cette session tmux, j’avais pris la précaution de lancer dans le terminal
export DISPLAY=:0
xrdb -query
la deuxième commande est une simple vérification.
Dans cette session tmux
nommée 0 il y a 4 fenêtres
fp2@debpacha:~$ tmux list-windows -t 0
0: bash (1 panes) [100x27] [layout c27d,100x27,0,0,0] @0
1: bash- (1 panes) [100x27] [layout c27e,100x27,0,0,1] @1
2: bash* (1 panes) [100x27] [layout c27f,100x27,0,0,2] @2 (active)
3: bash (1 panes) [100x27] [layout 6170,100x27,0,0,11] @11
fp2@debpacha:~$
Chacune de ces fenêtres se comporte comme un terminal et l’instance de bash
qui y tourne a la variable DISPLAY
positionnée.
Vous remarquerez au passage que l’écran 16/9 1600 x 900 pixels correspond à seulement 27 lignes de 100 (gros) caracatères.
Côté environnement graphique, j’utilise les « wotkspaces » de XFCE. Sur le numéro 1, j’ai un terminal xfce4-terminal
avec 5 onglets. Sur le 2 un xfce4-terminal
sans onglet mais uns session tmux nommée 1
fp2@debpacha:~$ tmux list-windows -t 1
1: python3 (1 panes) [79x22] [layout aea1,79x22,0,0,4] @4
2: bash (1 panes) [79x22] [layout aea2,79x22,0,0,5] @5
3: bash- (1 panes) [79x22] [layout aea3,79x22,0,0,6] @6
4: bash* (1 panes) [79x22] [layout aea4,79x22,0,0,7] @7 (active)
5: elinks (1 panes) [79x22] [layout aea5,79x22,0,0,8] @8
6: bash (1 panes) [79x22] [layout aea6,79x22,0,0,9] @9
7: bash (1 panes) [79x22] [layout 577f,79x22,0,0,10] @10
fp2@debpacha:~$ tty
/dev/pts/13
fp2@debpacha:~$
donc ici 7 fenêtres. Pour chacune de ces fenêtres il y a un répertoire courant PWD, un terminal de contrôle /dev/pts/NN etc …
Deuxou trois choses remarquables
xfce4-terminal
, qu’on modifie la taille en 100x27 et qu’on y lancetmux attach -t 0
les sorties de w ou who sont quasi inchangées. On a alors 4 instances de bash qui sont accessibles depuis deux « endroits » différents : sur fond noir en tty3 et sur fond blanc dans l’émulateur de terminal.
Fort de ces remarques, il me semble que « clavier (ls) -> /dev/pts/xx … » n’a pas vraiment de sens. Une telle formulation est à côté de la plaque.
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
A VENDRE
Mains pour se tenir la tête, pour travaux difficiles, la poignée, 4,20 F.
Bras croisés pour se reposer, les deux, 7,50 F.
Manuel : L’Art de vendre, 12 F.
Manuel : L’Art de vendre des manuels, 29,90 F.
Les petites annonces de l’Os à moelle Pierre Dac.
Oki
Bon malgré quelque point de vos explication reste un peu flou par rapport au peu d’expérience que j’ai entre les différents flux stdin,stdout et stderr car je ne les utilise que depuis très peu.
Le seul truc que je pouvais faire pour l’instant, c’est ouvrir un programme sur l’interface graphique du serveur vidéo via un terminal ssh depuis mon ordinateur juste avec la commande export DISPLAY=:0
.
Je vais relire 1 millard de fois vos postes et je reviendrais pour clarifié les point que je n’ai pas compris.
Et encore merci de votre aide.