ceci est juste au cas où ça inspire un commentaire , sans plus .
en mettant au point la commande xdotool type « adresse-1 » j’ai observé un genre d’écho dans la façon dont cette commande s’exécute . Mais peut-être est-ce un comportement normal du shell ?
mm@ldlc:~$ xdotool type "hello"
hellomm@ldlc:~$ hello^C ---> j'ai utilisé Ctrl + C pour remettre le prompt à zéro
mm@ldlc:~$ xdotool type "hello1" ; echo "hello2"
hello1hello2
mm@ldlc:~$ hello1
( 2ème partie effacée car mélange de 2 choses différentes )
Edit : bien possible que la réponse , pour la 1ère commande , soit dans ce commentaire :
Whenever anything is typed in to the terminal it is echoed. This is what are seeing. When bash restarts it sets the terminal to raw in order to handle all the special characters and editing etc, and so also turns off echo. It then reads what xdotool has typed, and dutifully echoes it.
j’avais trouvé un moyen de le faire automatiquement mais ça sort 2 lignes supplémentaires car je suppose que bash en lisant ce qui apparaît après l’invite de commandes l’interprète comme étant une commande , c’est ce qu’il écrit, et en affiche la sortie , introuvable dans ce cas .
Après, à quoi ça sert d’envoyer du texte (et non des commandes) dans un terminal bash, plutôt que dans une application qui comprend le texte, c’est une autre question optionnelle.
ça n’était pas du tout le but recherché , il s’agit juste d’un genre " d’effet secondaire " de xdotool que je ne comprenais pas et qui était apparu lors de la mise au point de la commande pour la création d’un raccourci clavier pour insérer une adresse courriel dans un document .
note : une autre solution proposée sur le site que j’avais trouvé et qui parlait de cette répétition du texte à insérer était celle-ci :
Ce n’est en aucun cas une ‹ solution › dans ton cas, et non celui d’un autre, comme tu le constates, puisque bash ne comprendra jamais la commande ‹ adresse-1 ›.
En général, il est beaucoup plus simple de :
1 - définir ce que l’on veut faire, l’objectif;
2 - trouver le moyen la commande pour le faire,
plutôt que d’essayer des commandes dans tous les sens, un peu au pif, sans savoir ce qu’on en attend.
je me demande si ça peut avoir un intérêt quelconque cet « effet secondaire » car en entrant une vraie commande on peut la faire s’exécuter . Y aurait-il un intérêt pratique à la chose ?
exemple : xdotool type « vim fichier » ouvre bien un fichier
Edit : vraie commande = commande comprise par bash
vim est une commande comprise par bash. adresse-1 n’est pas une commande.
Difficile de comprendre ce qui n’est pas compris.
――――――――――――――――――――――――――
Réponse à l’edit:
Bash ne comprend pas qu’exclusivement les ‹ vraies › commandes, ou plutôt les ‹ built-in commands › dont le nombre est très limité:
$ compgen -b
. : [ alias bg bind break builtin caller cd command compgen complete compopt
continue declare dirs disown echo enable eval exec exit export false fc fg
getopts hash help history jobs kill let local logout mapfile popd printf pushd
pwd read readarray readonly return set shift shopt source suspend test times
trap true type typeset ulimit umask unalias unset wait
Les commandes couramment utilisées telles que cp, ls, date, etc, ne sont pas spécifiques à bash, et sont fournies par le paquet coreutils:
cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir mknod mktemp mv
pwd readlink rm rmdir sleep stty sync touch true uname vdir [ arch b2sum base32
base64 basename basenc chcon cksum comm csplit cut dircolors dirname du env
expand expr factor fmt fold groups head hostid id install join link logname md5sum
mkfifo nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx
realpath runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum
shred shuf sort split stat stdbuf sum tac tail tee test timeout tr truncate tsort tty
unexpand uniq unlink users wc who whoami yes chroot
Bash utilise exec (built-in) de manière transparente pour lancer plus généralement les exécutables graphiques ou non, tel que xterm par exemple.
Le souci relatif à xdotool n’est donc pas la notion de ‹ vraies › commandes, mais uniquement de comprendre que ‹ Hello1 › ou n’importe quel ligne de texte ne peut pas être comprise par bash, la touche ‹ Return › du clavier lançant l’exécution de la supposée ligne de commande.
Si envoyer des lignes de texte avec xdotool dans un terminal est inutile, sauf preuve du contraire, il n’est probablement pas judicieux d’insister dans cette voie.
Pour afficher du texte pur dans un terminal, bash comprendra mieux les commandes cat, echo, print, printf etc., lancées à partir d’un script *sh, ou d’un alias, ou d’une fonction.