Pourquoi mes scripts shell sont par défaut en non-interactif?

Tags: #<Tag:0x00007f575570cd68>

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 :laughing:) 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
xterm

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 :
1 J'aime

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'

xterm1
xterm2