Problème redirection et descripteurs de fichier, et 'exec', et même fifo

Bonsoir,

j'ai vraiment du mal à comprendre comment fonctionne les redirections, en dehors du basique > 2>&1 ça se corse. :(

Dans une fonction, qui déroule des étapes, je veux que soit redirigé stdout vers un fichier (que ce soit fifo ou pas, pour l'instant peu importe).
À la fin de cette fonction, j'imagine rétablir stdout dans le descripteur dédié: 1
je voyais ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

function une { # début de fonction exec 3>&1 # sauvegarde de 1 dans 3 nouvellement créé exec > fic # ou "$fic_version_variable" # là, le moindre echo devrait aller dans fic echo "mais comment ça marche ?!" echo "tout est tellement puissant en prog, mais en bourne shell aussi pas mal ... si on maîtrise" # ci-dessous fin de fonction exec 1>&3 # récupère 1 à partir de &3 exec 3>&- # ferme &3 # fin de l'histoire, ressort sur le terminal et pas dans fic ! echo "bingo ?" }

---

Je voudrais déjà être sûr d'avoir bien compris qu'en théorie, cette syntaxe là fonctionne, qu'elle veut bien dire ce que j'ai compris qu'elle disait.

Après j'approfondirai parce que je ne fais pas de simple echo, j'envoie une chaîne dans une autre fonction, et en plus idéalement dans un fichier fifo. (Et je me demande si les exec se répercutent dans la fonction appelée (une fonction deux) de par les exec (redirections) exécuter dans la fonction mère ou pas, mais d'abord, tel quel est ce que ça doit fonctionner ?).

Bonjour,

il manque un exec à la première redirection.
après...
je n'ai pas approfondi les redirections, mais ça me semble correct.

Citation:

---

Envoyé par N_BaH

il manque un exec à la première redirection.
après...

---

Au temps pour moi, je rectifie, je l'ai oublié; il y est dans ma fonction, ça commence par exec.

Difficile de voir l’intérêt de faire ça...

C'est juste pour l'exercice ou c'est pour un cas réel (dans ce cas détail bien ton besoin) ?

car tu peux très bien appeler ta fonction en redirigeant le std(in,out,err) et dans ce cas pas besoin d'une telle moulinette.

j'ai pensé à une fonction appelée plusieurs fois, à des endroits différents d'un script...

bonsoir,
et bien je voulais (évidemment on peut faire beaucoup plus simple) à la base une fonction init qui va me checker, me créer, l'espace de travail. Comme il y a différentes étapes j'envoie des echos au fur et à mesure de celle ci, soit ça défile à l'écran en temps réel, soit en différé, capté dans un fichier qui me restitue le check/config des étapes.
Un peu comme quand on fait un make où il y a des tas de trucs à vérifier, et où ça défile à l'écran avec des OK ou des Echec pour cloturer chaque ligne.

En plus ces lignes je veux les justifier, (donc prise de tête avec `column` je veux que les "ok" et les "No" (en rouge en plus) soient alignés. Voilà je me demande comment faire, c'est tout. (pour ce qui est de colors, c'est bon, justifier j'y arrive avec une chaîne "patron" de la taille de mes colonnes (avec un délimiteur défini) et un pti sed pour éliminer la ligne modèle etc ça roule.
Je voudrais juste que quand je dis stdout part dans ce fichier , et stdout revient, puis je lis le fichier, ça sorte comme je souhaite, juste ça à la base, que ça se porte d'une fonction à l'autre. Maintenant si la fonction fille est un processus à part qui a sa sortie en &1, dans l'ignorance de ce que dit la fonction une qui a dit que stdout jusqu'à nouvel ordre c'est fic, j'envisage pourquoi ça marche pas comme je veux.

Bref en clair, si vous avez une methode pour justifer en temps réel une ligne (label, intitulé de la commande en cours) sans retour à la ligne (!), puis un "ok" ou "no" en fin de cette ligne rajouté en fin d'exécution de la commande (+\n) et ainsi de suit (mettons 20 commandes) toutes alignées pareil , je suis preneur grave :P

Du coup, j'imaginais (de fil en aiguille) diriger &1 vers un fifo. La fonction écrit dedans, tout au long du déroulement, puis quand je sors de la fonction en aillant remis les descripteurs tels quels, dans le script là où j'ai appelé init(), je lis ligne par ligne le fifo, un truc dans le genre (c'est en différé, mais j'ai pas encore trouvé mieux).

ou alors je (ça j'y suis arrivé) , chaque fois que je vais un echo, je > une ligne modèle (au début par exemple, parce que column traite des fichiers terminés, sans possibilité de spécifier un largeur et un nombre de colonne, hyper dommage) dans le fichier, suivie de la ligne "label de la commande/intitulé" sans retour à la ligne, puis le résultat de la commande "ok ou "no", et ensuite je fais column sur le fichier (column prend comme "patron" la ligne la plus longue) et je zappe cette ligne modèle à la sortie. Ou paste j'ai vu, avec plusieurs fichiers, pas encore exploré, pas adéquat.

Faudrait que je vois comment c'est écrit un script make avec les lignes qui défilent et le résultat de la commande ... Mais il y a tellement de choses à voir non ? que .... je pensais poser une question simple sauf pour moi ^^

un des buts de la redirection étant qu'elle dure pendant un temps, pour pas avoir à écrire en fin de chaque écho : >> fic (pénible) si en 2 ou 3 exec c'est réglé

Citation:

---

Envoyé par N_BaH

j'ai pensé à une fonction appelée plusieurs fois, à des endroits différents d'un script...

---

effectivement j'ai fait ça aussi, en tout cas j'ai pas poussé, pensant à plus simple (or je m'enlise) mais ça marche aussi, mais pas super adapté pour moi sur ce coup. Ça veut dire appeler la fonction (ou qui s'appelle elle-même selon une liste de tâches à faire, mais je ne veux pas d'interruption si une chose échoue, je veux la liste de ce qui a échoué et des ok.).

je ne proposais pas une solution.
je répondais au questionnement de disedorgue quant à l'utilité de la manip'.

entre parenthèses, j'aurais plus vite fait de "décompiler" un script typique pour voir comment c'est fait, que de chercher dans tous les sens (je parle pas de chercher votre aide, ça ça a un sens). Mais j'ai bien exploré avant et de fil encore en aiguille on découvre des trucs supers, passionnant, mais éloignent peut-être du centre, de l'objectif.
je cherchais à "décompiler" et j'ai trouvé shm (?) qui ne fait que compiler, pourtant dans mes souvenirs il y avait une commande un pgk un deb pour rendre humain à l'oeil un binaire (j'ai pas trouvé ce matin).
Ma question porte sur les redirections comme exposée au début, mais comme j'ai développé, je veux bien entendre la solution qui fait le bilan en tant réel des commandes et leurs statut, c'est clair, cette fonction n'est qu'un détail, je peux m'en passer (tout en silence echec ou ok bastan exit ou ready for the next).

tu t'égares, là.

le sujet porte sur les redirections.

après test, si on ne définit pas de variable globale dans la fonction, on peut simplifier :

Code:

---

maFonc() (exec 1>monFichier.stdout; echo "bla bla")

---

la fonction étant exécutée dans un sous-shell, la redirection n'altérera pas l'environnement courant (le scriptt).

C'est un peu simpliste. Comment faire ça, j'avais capté. On me demande de développer ce que je veux précisément, je développe, mais à la base, ma question porte bien sur les redirections, vers un fichier, (c'est la première brique et c'est celle là que je pose) tout au long d'une fonction, rétablissement des descripteurs,( et affichage du tampon mais ça c'est un autre sujet ok)

nb: tu fais une fonction avec ()() au lieu de () { } ? j'ignorais. Je sais que () c'est un sous-shell, je croyais que { } ça n'étais pas tout à fait pareil.

Citation:

---

Envoyé par N_BaH

après test, si on ne définit pas de variable globale dans la fonction, on peut simplifier :

Code:

---

maFonc() (exec 1>monFichier.stdout; echo "bla bla")

---

la fonction étant exécutée dans un sous-shell, la redirection n'altérera pas l'environnement courant (le scriptt).

---

mais justement il y a des variables globales, et ça m'arrange qu'elles soient affectées :aie::calim2:8O

Ou sinon en propre dans ta fonction:

Code:

---

1 2 3 4 5 6 7

exec {var}>&1 exec 1>fichier   le corps de ta fonction   exec 1>&$var exec {var}>&-

---

Ici, le but de passer par une variable (var) , c'est le système qui gérera le descripteur de fichier et non toi. L'avantage, c'est que par exemple si le fd 3 est déjà utilisé, il en utilisera un autre.

Intéressant mais je trouvais que fondamentalement ça ne change pas le problème, que je le nomme (ou que je laisse le système gérer,sauf si tu sous-entends que le &3 va paraître occupé dans une fonction appelée depuis ma fonction, mais j'aurais eu un message d'erreur bad descriptor un truc du genre...). Toutefois je teste ça dès demain en simplifiant, en repartant de la base, En repartant de ce qui marche et bien voir là où je perds le fil, merci. La suite bientôt ;)

pour l'instant, on ne sait rien de ton fichier de départ et de ton fichier d'arrivée (en supposant que ton fichier de départ, c'est tous les echo de ta fonction)

En général, pour que l'on puisse aider, faut mettre le code qui pose problème, ce que l'on a au départ et ce que l'on veut au final histoire que l'on puisse reproduire.

Bonjour,
j'entends bien, je prépare une version typique pour dans la matinée, pas tout de suite, (je pensais que décrire suffirait).

Voilà ce que j'ai à la base :

Code:

---

1 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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70

#!/bin/bash   function config_tmpfs {   if [ "$(ls -al $MYTMPFS | awk '{ print $1}')" != "drwxrwxrwt" ]; then echo "NO" echo -n "Correction des permissions ... " { sudo chmod 1777 "$MYTMPFS" && echo "OK" ;} || { echo "Echec" ; echo "1/ Abandon: voir logs !" && return 1 } else echo "OK" fi echo -n "Montage du répertoire en RAM ... " if sudo mount -t tmpfs -o size=512M tmpfs "$MYTMPFS"; then echo "OK" echo -n "Config XTRACE ... " F_XTRACE_LOGS="$MYTMPFS/f_xtrace.logs" touch "$F_XTRACE_LOGS" exec {BASH_XTRACEFD}>>"$F_XTRACE_LOGS" # redirige xtrace vers un fichier de logs temporaire ! set -x echo "OK" echo -n "Création arborescence dans $MYTMPFS ... " if ! rsync -avR "sql_rep" "$MYTMPFS/"; then echo "Echec" echo "2/ Abandon: voir logs !" && return 1 else echo "OK" fi else echo "Echec" echo "3/ Abandon: voir logs !" && return 1 fi return 0 }   function init_stuff { if [ -z "$1" ]; then echo "argument bof" # voire perrave return 1 else # source variables et fonctions source ./des_fonctions.sh source ./des_variables.sh echo "MYTMPFS: $MYTMPFS" echo -n "Check: existence $MYTMPFS ... " if [ ! -d "$MYTMPFS" ]; then echo "NO" echo -n "Création du répertoire $MYTMPFS ... " if ! sudo mkdir "$MYTMPFS"; then echo "Echec" echo "0/ Abandon: voir logs !" && exit 1 else echo "OK" echo -n "Check droits sur répertoire $MYTMPFS ... " config_tmpfs || exit 1 fi else echo "OK" echo -n "Check droits sur répertoire $MYTMPFS ... " config_tmpfs || exit 1 fi fi   }     init_stuff test exit 0

---

1/ mon premier souci qui m'a mené à explorer les redirections, c'était de contrôler l'affichage sur stdout :
- j'ai mis du temps à trouver la variable BASH_XTRACEFD pour que les traces aillent dans un fichier à part, ça c'est fait
- de là j'ai voulu mettre en forme la sortie standard, en alignant les lignes "label" + "resultat" sur 2 colonnes, basique. Plutôt que de faire une fonction bourrine qui me remplit "label" d'espace jusqu'à length max, je souhaite utiliser column (mais column ne prend pas d'argument de taille, juste un séparateur de champs, ça c'est utile)
- je peux me dire qu'au lieu d'appeler echo, j'appelle une fonction de des_fonctions.sh qui me revoie la string "label" en concaténant un '|' comme séparateur (ici je l'ai pas inscrit mais en gros c'est l'idée)

2/ Maintenant s'il y a une solution beaucoup plus simple que ce que je décris, pour contrôler la sortie et la formater à mon goût, je suis clairement preneur.

3/ Donc je vais un peu regarder dans la matinée, comment en redirigeant les echo dans un fichier, je peux mettre les chaînes au format voulu. Évidemment je ne m'intéresse là aux redirections que parce que ça me parait propre (je me vois pas rajouter en fin de chaque "echo bidule" un >fic_bidule. Mieux vaut faire un exec une bonne fois et être tranquille jusqu'à ce que j'ai besoin de rétablir les directions.
Ici dans l'exemple je ne gère pas stderr mais c'est prévu que &2 aille dans un autre fichier de logs.

NB: peu important pour l'exemple, mais les fichiers sourcés sont du genre

Code:

---

1 2 3 4 5

#!/bin/bash #des_fonctions.sh: function renvoie_string { echo "$*" ;} function special_renvoi_string { echo "$*|" ;}

---

Code:

---

1 2 3 4 5 6

#!/bin/bash # des_variables.sh export THE_FIC=./the_fic export OTHER_FIC=./other_fic export MYTMPFS=./MYTMPFS

---

Imaginons que le script soit ceci:

Code:

---

1 2 3 4 5 6 7

[ ! -p fipe ] && mkfifo fipe exec {var}>&1 exec 1>fipe & # esperluette ou il ne me rend jamais la main init_stuff test exec 1>&$var exec {var}>&-

---

Ceci ne marche pas, il lit le pipe sans même que je le demande (comme si stdout était normal, et là je comprends pas pourquoi. Dans mon esprit, il fallait que je fasse un `cat fipe` pour lire tout en vidant ce satané tampon. D'AILLEURS JE NE SUIS MÊME PAS SÛR QU'IL LE LISE, JE CROIS QUE RIEN NE S'ÉCRIT DEDANS EN FAIT

NB: si je redirige dans un fichier normal, ça marche impecc, je capture mon texte et je peux le traiter tranquille en suite. C'est déjà une bonne chose, je peux m'en contenter ;)

C'est donc le fonctionnement de fifo que je comprends le moins là...

<hs>
ls -al $MYTMPFS | awk '{ print $1}' non.

Code:

---

stat -c %A "$myTmpFS"

---

parce qu'il est piégeux de parser ls, et parce que les noms de variables tout en majuscules sont réservés, par convention, aux variables d'environnement (HOME, PATH, ...).
</hs>

Citation:

---

Envoyé par N_BaH

<hs>
ls -al $MYTMPFS | awk '{ print $1}' non.

Code:

---

stat -c %A "$myTmpFS"

---

parce qu'il est piégeux de parser ls,[/B]

---

Ah oui merci j'attendais de tomber sur une autre solution, effectivement ls m'a réservé quelques surprises lol qui auraient pu s'avérer sytèmement cataclysmiques

Citation:

---

Envoyé par N_BaH

[B]
et parce que les noms de variables tout en majuscules sont réservés, par convention, aux variables d'environnement (HOME, PATH, ...).
</hs>

---

Ça par contre ça se discute , les points de vue diverge selon les sources. Je prends peu de risque si je personnalise le nom de la variable et moi j'y vois plus clair, ( no way ? )

NB: cela dit, "$myTmpFS" c'est joli à l'oeil, le seul inconvénient c'est que ça m'oblige à toucher deux fois la touche maj hihi

non, non. ça ne se discute pas : c'est une convention.
parce qu'on ne connait pas toutes les variables d'environnement, on évite ainsi de les écraser.

le "panachage" permet, àmha, une meilleure lisibilité et compréhension de ce que contient l'élément (variable, fonction, alias,..) (puisque le nom doit être évocateur de ce que c'est).

Citation:

---

Envoyé par Dens1

Imaginons que le script soit ceci:

Code:

---

1 2 3 4 5 6 7

[ ! -p fipe ] && mkfifo fipe exec {var}>&1 exec 1>fipe & # esperluette ou il ne me rend jamais la main init_stuff test exec 1>&$var exec {var}>&-

---

Ceci ne marche pas, il lit le pipe sans même que je le demande (comme si stdout était normal, et là je comprends pas pourquoi. Dans mon esprit, il fallait que je fasse un `cat fipe` pour lire tout en vidant ce satané tampon. D'AILLEURS JE NE SUIS MÊME PAS SÛR QU'IL LE LISE, JE CROIS QUE RIEN NE S'ÉCRIT DEDANS EN FAIT

NB: si je redirige dans un fichier normal, ça marche impecc, je capture mon texte et je peux le traiter tranquille en suite. C'est déjà une bonne chose, je peux m'en contenter ;)

C'est donc le fonctionnement de fifo que je comprends le moins là...

---

Ok, la fifo, c'est plus vicieux, pour l'utiliser c'est plus du genre:

Code:

---

1 2 3 4 5 6 7 8

$ mkfifo fic $ exec {var}>&1 $ exec 1<>fic $ echo foobar $ exec 1>&$var $ read xx <fic $ echo $xx foobar

---

Comme tu peux le voir, la fifo est à la fois une entrée et une sortie, d'où le exec 1<>fic pour que cela ne soit pas bloquant, ensuite pour l'écriture, pas de soucis, par contre la lecture de la fifo est plus compliqué, car les commande tel que cat reste bloqué à la fin.
C'est la raison pour laquelle, dans l'exemple, j'utilise la commande read qui ici ne bloque pas car il y a bien une ligne à récupérer, mais si la fifo est vide, alors le read restera bloquant aussi.
Par chance, au moins sous bash, le read possède une option de timeout qui renvoie un code erreur.
Donc, pour vider la fifo, un simple code du genre:

Code:

---

while read -t 3 xx ; do echo $xx ; done <fic

---

devrait fonctionner ( sauf s'il lui faut plus de 3 secondes pour lire une ligne)

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

Citation:

---

Envoyé par N_BaH

non, non. ça ne se discute pas : c'est une convention.
parce qu'on ne connait pas toutes les variables d'environnement, on évite ainsi de les écraser..

---

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.
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

Code:

---

grep "MYTMPFS" < <(env) # check

---

suffit à prévenir l'incident.
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

Citation:

---

placer soi-même des variables d'environnement du shell, qui donc se propage partout, dans des cas spécifiques

---

ah, mais là, ça dépasse le cadre d'un script, on serait dans la configuration de l'environnement.
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" !

Citation:

---

Envoyé par N_BaH

"panachage" !.."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:
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 :

Code:

---

1 2 3 4 5 6

[ ! -p fipe ] && mkfifo fipe exec {var}>&1 exec 1>fipe & # esperluette ou il ne me rend jamais la main init_stuff test exec 1>&$var exec {var}>&-

---

au lieu d'un simple:

Code:

---

init_stuff test >fic

---

pour ensuite traiter le fichier fic (pas un fifo)

Citation:

---

Envoyé par Dens1

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 ;)

---

Citation:

---

Envoyé par disedorgue

Moi, ce que je ne comprends pas dans ta démarche de "fainéant", pourquoi faire :

Code:

---

1 2 3 4 5 6

[ ! -p fipe ] && mkfifo fipe exec {var}>&1 exec 1>fipe & # esperluette ou il ne me rend jamais la main init_stuff test exec 1>&$var exec {var}>&-

---

au lieu d'un simple:

Code:

---

init_stuff test >fic

---

pour ensuite traiter le fichier fic (pas un fifo)

---

moi ce que je comprends pas c'est pourquoi tu me paraphrases en plus long en disant que tu comprends pas :ptdr:

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:

Code:

---

1 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

$ fx1 () { for i in {1..10}; do echo bob $i; done; sync } $ fx2 () { while read xx; do echo "xx=$xx"; done } $ fx1 > >(fx2) xx=bob 1 xx=bob 2 xx=bob 3 xx=bob 4 xx=bob 5 xx=bob 6 xx=bob 7 xx=bob 8 xx=bob 9 xx=bob 10 $

---

Dans la fonction fx1, le sync final est obligatoire, si tu veux garder un semblant de synchronisation dans l'affichage.
ou plus simplement:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

$ fx1 | fx2 xx=bob 1 xx=bob 2 xx=bob 3 xx=bob 4 xx=bob 5 xx=bob 6 xx=bob 7 xx=bob 8 xx=bob 9 xx=bob 10 $

---

Donc, dans ton cas, fx1 serait la fonction init_stuff et fx2, celle qui traite l'affichage.

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

Code:

---

exec 1<>fic

---

(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.

- 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)

Code:

---

1 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 34

trap "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.

---

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.

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