Attention c'est du BASH de haut niveau. Newbies passez votre chemin.
je viens de passer 24h sur un script d'une seule ligne: récupérer dans une variable la valeur de retour d un *dialog directement dans une variable.
Avec Xdialog, j'avais originalement:
r=`${DIAG} --title "Eapp editor" --fselect "" 50 100 2»ET1`
et roulez jeunesse.
Puis un mec m as dit: tu sais, Xdialog et dialog sont 100% compatibles au niveau arguments ... (mouai, vite dit ... à part --menubox , et évidement, je m'en sers .. mais passons).
Et la tout de suite, si vous lancez la même commande avec DIAG=dialog, tout de suite, ça marche beaucoup moins bien: car vous foutez dans $r toute la sortie d affichage !!! donc y a plus rien a l'écran.
Il faut savoir que dialog envoi l'affichage sur stdout, et le champ de retour sur stderr (la valeur de retour elle meme signale les erreurs internes a dialog). C est donc stderr qui contient ce que l utilisateur a saisi dans la boite ...
tous les exemples de Google font bètement:
dialog 2»/tmp/file
Oui mais, avec Xdialog, ça marche tres bien sans ficher temporaire. Donc hors de question que mon script 'de qualité' s'abaisse à ce niveau quand Xdialog permet de ne pas en creer !!!
La j ai passé une journée entière à essayer des trucs du genre
cmd 2 » $r
cmd 2 » ET $r
...
tout y est passé ...
Mais en fait, quand on fait un 2»file, tout ce que fait bash, c'est placer dans le pointeur stdout l'adresse du fichier !!!
Puis au bout de 24h, je me suis rappellé mon cours de C: pour échanger le contenu de deux variables, il faut en utiliser une 3e.
DONC: si notre problème pouvais consister à juste échanger les adresses 1 et 2, ben, il suffit d utiliser 3 !!!
r=`${DIAG} 3»ET2 2»ET1 1»ET3`
et hop ça marche !!!
n'oubliez pas de lire a l envers:
- les arguments sont traités de gauche a droite
- les assignations sont faites de droite a gauche !!! 3»ET2 signifie: je place l'adresse de 2 dans le pointeur de 3
et voila: cela échange proprement les adresse 1 et 2 sur respectivement stderr et stdout. Ainsi, r receois bien le champs utilisateur écrit sur 2, tandis que l affichage se fait sur stderr, donc bien à l'écran.
À bon entendeur, salut.
Forum général.général Interchanger les flux.
21
mai
2005
# Ouais
Posté par Ant . Évalué à 1.
Nul doute que c'est de trop haut niveau pour moi, mais qu'est-ce qu'il faut mettre dans DIAG ?
# Re: Interchanger les flux.
Posté par gros_rouge . Évalué à 7.
Circulez, y a rien à voir ! C'est sympa pour ceux ( les « Newbies » ) qui veulent apprendre quelque chose.
Sinon, pour les ceusses qui ont du mal à lire le « BASH de haut niveau », il faut remplacer les `»ET` par des `>&`.
Moi, je fais comme ça :
$ retval=`dialog --stdout --inputbox "Entrez votre prénom :" 0 0` # Notez le --stdout
$ echo $retval
fabrice
Ça marche aussi et c'est dans la page de man.
[^] # Re: Interchanger les flux.
Posté par doublehp (site web personnel) . Évalué à 0.
bon, je viens de tester:
- quand tu redige une reponse a un message contenant un '2>&1', le message s affiche bien une fois valide, ainsi que pendant la preview.
- quand tu ecris un nouveau thread de forum, le message final s affiche AUSSI bien, mais pas la preview.
Je viens de tester dans #test, le message final est bien comme il faut, par contre, la verification affiche des trucs tout chelous ...
donc quand j ai redige mon premier message ci dessus, j ai paniqué en voyant la preview, et j ai essaye de afire 'autrement'.
Quand au --stderr, je l ai essaye sous plusieur formes, et ca n a jamais rien donne de concluant dans le cadre de mon script.
[^] # Re: Interchanger les flux.
Posté par gros_rouge . Évalué à 2.
Dans le doute, tu remplaces par les entités caractères ( ou numériques ) correspondantes. Ça prend quelques secondes avec un bon éditeur de texte.
J'ai écrit "--stdout".
[^] # Re: Interchanger les flux.
Posté par doublehp (site web personnel) . Évalué à 0.
j'ai essaye les deux, séparément, ensemble, avec ou sans d'autres redirections ... dans mon script, ça donnait rien de bon.
# file descriptor 3 = danger
Posté par free2.org . Évalué à 3.
Il faut bien faire attention avec ta manipe, car si un fichier (y compris un pipe) a été ouvert en + des traditionnels sdin/stdout/stderr (0,1 et 2), alors le fd 3 peut pointer sur ce fichier, et après ta manipe il peut pointer sur l'ancien stderr.
[^] # Re: file descriptor 3 = danger pas fréquent
Posté par free2.org . Évalué à 2.
echo toto|cut -b 1 3>&1 >/tmp/toto
n'affiche rien, et /tmp/toto contient t, donc tout va bien
[^] # Re: file descriptor 3 = danger
Posté par doublehp (site web personnel) . Évalué à 0.
Read keyboard input from the given file descriptor.
effectivement, avec cette option la, il peut y avoir du danger.
Quoi que ... le fd3 n a pas d usage particulier predefinit; hors quand tu execute mon bazard, Bash effectue les transferts d addresses avant d executer la commande, donc le fd3 est alloue AVANT que dialog lui meme ne s execute. Donc si dialog n ouvre pas en dur le fd3, je serais etonne que le bug que tu evoque puisse arriver ... du moins avec dialog.
Par contre, si dans la meme ligne de flux d autres aplis ont ouvert un fichier AVANT, la ca peut devenir plus bizarre, mais ca impliquerai un truc du genre
bidule -f file | xdialog
et je ne vois pas l interret d une telle aproche.
sachant que si c est
xdialog | bazard
ca ne pose plus aucun probleme.
--
essai perso: 2>&3
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.