Bon sang mais c'est bien sûr ! :mouarf:
je l'avais vu passer cette syntaxe du <> (lecture - écriture) mais j'avais pas fait le rapprochement avec mon souci , ballot.
Merci beaucoup, je vais tester ça mais je sens que c'est résolu.
Cordialement. :P
Version imprimable
Bon sang mais c'est bien sûr ! :mouarf:
je l'avais vu passer cette syntaxe du <> (lecture - écriture) mais j'avais pas fait le rapprochement avec mon souci , ballot.
Merci beaucoup, je vais tester ça mais je sens que c'est résolu.
Cordialement. :P
je maintiens que ça peut être sujet à discussion, mais des constantes, des variables exportées, mise en majuscules (dixit), n'est pas forcément une bonne idée pour tous les projets. Cependant j'essaie de lire le Shell Style Guide de Google mais la page ne se charge pas. Je trouve qu'on peut avoir besoin de placer soi-même des variables d'environnement du shell, qui donc se propage partout, dans des cas spécifiques.Citation:
Envoyé par N_BaH
En outre, j'aimerais bien savoir comment lister toutes les variables Bash, du Shell pour éviter les collisions de noms, toutes c'est à dire y compris celles (réservées) qui ne sont pas attribuées dans le shell courant, car sinon, un simple
suffit à prévenir l'incident.Code:grep "MYTMPFS" < <(env) # check
Ceci dit je suis bien disposé à me plier aux "conventions" immuables tant que je n'ai pas de bonnes raisons de les outrepasser ^^ :mrgreen:
:aie: Malheureusement la solution #20 ne fonctionne pas Disedorgue :( ... même dans un terminal, ça bloque (un truc nous échappe)
Non, il faut juste respecter:
- que la dernière ligne insérée finisse bien avec un newline (\n)
- ne pas fermer le descripteur temps que l'on a pas vidé la fifo
ah, mais là, ça dépasse le cadre d'un script, on serait dans la configuration de l'environnement.Citation:
placer soi-même des variables d'environnement du shell, qui donc se propage partout, dans des cas spécifiques
C'est autre chose, mais même alors, je ne suis pas convaincu que ce soit une bonne idée de mélanger la personnalisation de son environnement avec le travail encadré de personnes chargées de l'environnement de l'OS*. Donc, "panachage" !
et, pour prévenir tout incident : "panachage" !
je ne vais pas vérifier qu'une variable environnement ne porte pas le même nom, à chaque fois que je définis une variable.
donc (encore) : "panachage" !
--
* donc, à moins d'une action concertée pour configurer l'environnement dans le cadre du déploiement d'un programme : "panachageuuh" !
quels sont donc ces termes usuellement réservés (dans mon environnement) à la concoction d'une mixture à base de houblon et de liquide protogazeux et citronné ? :ptdr:Citation:
Envoyé par N_BaH
NB: je n'aurais pas le toupet de défier un développeur, encore moins une équipe qui me donne à utiliser un si bel outil :aie:
Disedorgue je suis interloqué et circonspect, car j'ai bien une new line à la fin, et je ferme le descripteur correctement il me semble, (j'ai testé en modifiant les exit 1 de la fonction, faits précédés de la fermeture du descripteur) ...
je vais peut-être un peu dormir ...
j'arrive à quelques solutions bof (au moins quelque chose) en testant les trucs décrits : ICI mais je peine à saisir le fonctionnement
Bah un jour je tomberai sur un truc et j'aurai le déclic, laissez tomber.
En attendant une fonction qui me vide le fichier texte où j'aurais redirigé &1 après l'avoir lu et traité fera très très bien l'affaire ;)
Moi, ce que je ne comprends pas dans ta démarche de "fainéant", pourquoi faire :
au lieu d'un simple:Code:
2
3
4
5
6
pour ensuite traiter le fichier fic (pas un fifo)Code:init_stuff test >fic
Citation:
Envoyé par Dens1
moi ce que je comprends pas c'est pourquoi tu me paraphrases en plus long en disant que tu comprends pas :ptdr:Citation:
Envoyé par disedorgue
Dommage j'aurais bien aimé comprendre et mettre en application les fifos, ça peut toujours servir mais dans l'attente de tomber sur un exemple qui illustre comment je veux m'en servir (si possible), je me passerai de fifo
Merci quand même, on apprend, on avance, on avance ;-)
Un fifo sert à faire de la communication inter-process, d'où son coté bloquant...
Voici une autre méthode sans fichier du tout:
Dans la fonction fx1, le sync final est obligatoire, si tu veux garder un semblant de synchronisation dans l'affichage.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
ou plus simplement:
Donc, dans ton cas, fx1 serait la fonction init_stuff et fx2, celle qui traite l'affichage.Code:
2
3
4
5
6
7
8
9
10
11
12
Bien, j'ai suffisamment avancer pour faire un petit résumé en ce qui concerne mes interrogations du début, zé les choses captées.
- les tubes nommés je n'en ai pas l'utilité, dans la mesure où c'est pratique pour faire communiquer en entrée - sortie des processus (+des scripts) distincts (pas mon cas). De plus c'est un peu délicat à maîtriser (pour moi) et ça ne comporte pas l'avantage qui m'avait à la base attiré, celui de ne pas être un fichier normal, je veux dire écrits en dur sur le DD. (pour faire communiquer des fonctions entre elles ça ne m'intéresse pas, il y a tout ce qui faut dans le traditionnel je pense).
Car si je fais transiter les milliers de lignes (puis à force des millions, ... au moins pendant l'écriture du script) je voulais soulager le matériel, à la base. Or c'est un fichier particulier, mais en dur.
Ce que j'ai compris aussi, j'ai vu la syntaxe(fic étant un fifo), c'est adapté si on veut à la fois lire et écrire dedans par le même processus, sans que le fifo se vide, car sinon la moindre opération sur fic viderait fic.Code:exec 1<>fic
- pour ce qui est des redirections je ne jongle pas avec mais j'ai à peu prés capté. Je retiens donc l'usage, puisque ça m'évite de finir mes echo par un pointage vers le fichier où je veux rediriger. Je choisis un simple fichier, mais que je monte en ram, voilà comme ça ça écrit dans la ram, et pas en dur (évidement, en cas de fusible défectueux, ou départ de feu dans l'alimentation, je perds, mais vraiment rien que je ne puisse retrouver).
J'ai compris un truc intéressant, c'est qu'un simple fichier, dès lors qu'on fait (comme je le montre après dans le détail des modifs du script et des fonctions) un redirection de fd vers lui, se comporte aussi vraisemblablement comme un tampon, un fifo, c'est à dire que la moindre opération sur le fichier vide le fichier, de même que la fermeture du file descriptor auquel il était associé, vide le fichier.
Donc, j'ai rajouté ces petite choses dans les fichiers script.sh, des_fonctions.sh et des variables.sh (page 1)
Je ferme pour l'exemple, mais en fait pour éviter de le réouvrir dans le script, et vu que fic est maintenant vide, je pourrais me contenter de remettre stdout > fic en fin de fonction, pour la suite.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34trap "sync" RETURN EXIT # en tête d'init_stuff trap "sync" EXIT # en tête de config_tmpfs # le script proprement dit qui fonctionne comme je veux exec 3>&1 # sauvegarde de stdout dans 3 (ou {var}, sauf que j'ai d'abord testé ainsi, de peur que {var} ne soit pas compris dans la fonction qui le referme exec 1>fic # j'associe stdout à fic (un fichier normal) init_stuff "$1" | renvoie_string # envoie du bins dans une foncion de traitement # le fichier des variables (dsl j'ai pas encore modifié les noms en pachaché d'upper-lowercase hiha) export linemodel="Lorem ipsum dolor sit amet, consectetur adipisicing elit, dolor sit amet|ncididunt ut" # le patron, comme on dit en coutûre # dans les fonctions, renvoie_string devient: exec 1>&3 # je rétablis stdout, dès lors tout sortira comme avant sur l'écran, le terminal # ( si je veux écrire "$linemodel ici, ou même avant le rétablissement stdout, je vide le fichier même si j'append (>>) # qu'il ne reste que la dernière ligne, linemodel, écrite. # echo "$linemodel" >> ou > fic # exec 1>&3 # cat fic affiche linemodel, et c'est tout ) while read line; do # préformate ici un peu mais bon ... à la va-vite, je verrai à l'usage # pour ce qui est des couleurs comme je voulais, je le fais en amont, ici j'ai tout le loisir de travailler sur la chaîne # mais il me manque une info pour la première colonne, renvoie_string ignore comment je la voulais (gras, italique, quelle couleur, underline ...) echo "$line" | sed -e 's/OK/|OK/g' -e 's/NO/|NO/g' -e 's/Echec/|Echec/g' # l'essentiel c'est de diviser les lignes en colonnes à l'aide du séparateur '|' done >> fic1 # mais je copie tout ça dans un fichier normal echo "$linemodel" >> fic1 # là je peux ajouter le model de formatage sans tout effacer (autre fichier normal) column -t -s '|' fic1 # et là column fonctionne nickel (pas de message "column too long" à cause d'une echo -n en amont) # je peux envoyer column dans une boucle while read line pour temporiser l'affichage, pour le confort des yeux (parce que là ça défile vitesse pas humaine quoi). exec 3>&- # et je ferme le descripteur.
Voilà voilà, merci à vous pour vos éclaircissement, comme quoi on part de "tiens j'afficherais bien cette ligne en blanc, celle là en rouge, pour voir les étapes qui couinent ..." et on explore les fifos, les redirections, les fd, column, sync (sync je ne suis pas certain que ce soit utile ici, à voir à l'usage quand ça va se corser en terme de tâches et de volume d'affichage), les LS_COLORS, etc ... :zoubi::P