Curiosité de xdotool type ou comportement normal?

Programmation
#1

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.

#2

C’est normal, xdotool type simule une frappe au clavier, d’où le CTRL-C pour arrêter.

#3

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 .

mm@ldlc:~$ xdotool type "adresse-1" ; xdotool key Return
adresse-1
mm@ldlc:~$ adresse-1
bash: adresse-1 : commande introuvable
mm@ldlc:~$
#4

oui c’est exactement ça.

#5 
$ printf 'Hello1\nHello2\n'
Hello1
Hello2

$ xdotool type 'printf "Hello1\nHello2\n"' ; xdotool key Return
printf "Hello1\nHello2\n"
$ printf "Hello1\nHello2\n"
Hello1
Hello2

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.

#6

ç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 :

mm@ldlc:~$ xdotool type 'adresse-1
'
adresse-1
mm@ldlc:~$ adresse-1
bash: adresse-1 : commande introuvable
mm@ldlc:~$
#7

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.

#8

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

#9

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.

#10

je vois qu’il y a une incompréhension à la base de ce que j’écris . Probablement que je suis un peu brouillon .

Mais peu importe , merci pour les commentaires qui m’apprennent toujours quelque chose .