Salut, j’ai créé sur mon bureau un script test.sh comme ceci :
#!/bin/bash
echo "$# $@"
echo "$# $@" > output.txt
read -p "Appuyer sur ENTRÉE pour continuer" </dev/tty
J’ai donné les droits d’exécution avec chmod +x test.sh.
Si je double-clique dessus, le fichier output.txt est créé, il contient (comme attendu) la chaîne suivante : 0 (un zéro suivi d’un espace) mais je ne vois pas s’afficher de fenêtre avec le echo tout simple ni le « Appuyez sur ENTREE pour continuer ».
Je soupçonne que le shell utilisé est un shell non interactif, mais je suis surpris car le #!/bin/bash du début est censé ouvrir bash qui est un shell interactif… Qu’est-ce que je fais mal ? Ou qu’est-ce que je ne comprends pas ?
Je précise à toutes fins utiles que mon bureau est sous Plasma, des fois que ça ait une importance dans l’exécution des scripts shell par double-clic.
Bonjour,
#!/bin/bash
echo "$# $@"
echo "$# $@" > output.txt
echo "Appuyer sur ENTRÉE pour continuer"
read
Pas mieux. À noter que le read est juste là pour avoir une touche à presser avant que la fenêtre (qui ne s’ouvre pas
) se ferme.
Je précise aussi que quand on lance ce même script depuis un shell ouvert, tout se passe bien, le résultat s’affiche et il attend que j’appuie sur ENTREE :
$ ./test.sh toto titi
2 toto titi
Appuyer sur ENTRÉE pour continuer
$
Oui ça en a pour faire un lanceur compris par plasma.
A mon avis, il faut donner un chemin complet à ‹ output.txt › et lancer un terminal.
Tu peux créer un fichier test.desktop soit avec le contenu du script, ou appel à un script test.sh
test.desktop
[Desktop Entry]
Type=Application
Exec=xterm -hold -title "test.sh" -e bash -c 'echo "$# $@"; echo "$# $@" > /tmp/output.txt; read -p "Appuyer sur ENTRÉE pour continuer" </dev/tty'
Ah, je pensais que lancer un script shell dans bash lançait automatiquement une fenêtre de terminal (c’est l’habitude de lancer un .bat sous Windows qui ouvre automatiquement cmd.exe).
Du coup je comprends que je dois lancer explicitement un terminal (xterm dans ton example), avec le script .sh à exécuter donné en argument.
Par curiosité, je lis que xterm est un terminal pour X. Moi je suis sous Wayland, et même si je sais que Wayland a un module pour afficher les clients X, j’ai regardé quels terminaux étaient natifs Wayland : il y a konsole que j’ai déjà, mais aussi des tas d’autres. D’où ma question suivante : existe-t-il sur Debian un genre de point d’entrée « générique » pour lancer un terminal, au lieu d’en imposer un « en dur » dans mon script ? Je pense à un truc qui fonctionnerait comme editor, qui est une commande générique pour l’éditeur de texte choisi par l’utilisateur (commande update-alternatives). Histoire de faire un script qui soit portable sur un autre PC qui n’aurait pas les mêmes terminaux que moi.
foot devrait faire l’affaire en tant que terminal ultra léger.
Je l’utiliserais si j’utilisais wayland.
foot 686,0 KB
↳ Fast, lightweight and minimalistic Wayland terminal emulator
Depends: libc6 libfcft4t64 libfontconfig1 libpixman-1-0 libutf8proc3
libwayland-client0 libwayland-cursor0 libxkbcommon0 ncurses-term
Voir systemsettings > applications par défaut

Mais j’utilise konsole en terminal principal / multi-tab.
Je réponds à ma propre question, c’est la commande x-terminal-emulator. Cette commande lance l’émulateur par défaut, paramétrable par l’utilisateur grâce à la commande :
$ update-alternatives --config x-terminal-emulator
Il existe 5 choix pour l'alternative x-terminal-emulator (qui fournit /usr/bin/x-terminal-emulator).
Sélection Chemin Priorité État
------------------------------------------------------------
* 0 /usr/bin/konsole 40 mode automatique
1 /usr/bin/koi8rxterm 20 mode manuel
2 /usr/bin/konsole 40 mode manuel
3 /usr/bin/lxterm 30 mode manuel
4 /usr/bin/uxterm 20 mode manuel
5 /usr/bin/xterm 20 mode manuel
Appuyez sur <enter> pour conserver le choix actuel [*], ou tapez le numéro de sélection :
Certes, mais update-alternatives est utilisé à bas niveau pour faire pointer python sur python3 par exemple, ou autres versions java etc, mais pas utile au delà, aucun intérêt dans un environnement graphique (voir ignoré).
Pour le navigateur par défaut, c’est la variable d’environnement $BROWSER qui est utile pour man -H nano par exemple.
xterm -hold -title "Coucou" -e bash -c "echo Hello"
Si tu remplaces xterm par x-terminal-emulator, ça marche déjà moins bien !
La raison est que les options de différents terminaux ne sont elles pas portables.
Et ouvrir konsole pour faire echo 'coucou', c’est sortir un bazouka pour pas grand-chose.
J’avais essayé de me débarasser de xterm, car très difficile à configurer correctement pour obtenir un terminal correct, et m’étais intéressé à stterm
ST/Stterm - terminal petit mais costaud, évolutif - Trucs et Astuces - debian-fr.org
Mais xterm a un énorme intérêt de portabilité: on est sûr qu’il est là, installé par défaut, parce-que justement Debian a besoin d’être sûr d’avoir accès à un terminal pour différentes raisons (installations etc). xterm est compatible x11/wayland.
Donc après avoir bien sué pour configurer xterm (difficile), on finit par conclure que xterm, malgré sa vieillerie reste une valeur sûre.
En effet, j’avais pas pensé à ça…
Un problème que je n’ai jamais résolu, c’est le reflow/redraw de xterm, c’est-à-dire la capacité à conserver le contenu d’une ligne lors du redimensionnement de la fenêtre xterm / problème connu depuis 2008 - xterm: does not redraw correctly when selection exists before
xterm -hold -title 'Reflow test' -g 70x4+0+0 -fa 'Monospace' -fs 10 \
-bg '#333' -fg '#eee' -e sh -c 'printf "%4s" $(seq 20);echo'

