dispo de l'entree standard

Bonjour à tous.

Depuis quelques jours, je me pose une question existencielle à laquelle je n'ai pas encore obtenue de réponse.

En fait que désirerais écrire une fonction dont les attributs pourraient être à la fois passés en paramètre ou bien consommé via un pipe.
Un petit exemple vaut bien souvent de long discours :

Code:

---

1 2 3 4 5 6

# exemple avec passage de paramètre maFonction "unAttribut" "unAutreAttribut"   # exemple avec pipe : echo "unAttribut unAutreAttribut"|maFonction

---

Pour résoudre ce problème voici comment j'ai procédé à l'interieur de ma fonction :

Code:

---

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

function maFonction { if [[ "$#" != "0" ]] ; then mesAttributs=$* else mesAttributs=$(cat) fi echo "mesAttributs=${mesAttributs}" } # Exemples d'utilisation qui fonctionnent maFontion att1 att2 echo "att1 att2"|maFonction

---

Le problème avec cette méthode se situe lors de l'utilisation du pipe. Si la commande avant pipe ne sort rien, alors le cat situé dans la fonction se bloque en attendant indéfiniment que quelque chose arrive :
uneCommande|maFonction
Si une uneCommande n'envoit rien en sortie, cela bloque.

Mes questions :
- Ma méthode pour réaliser une telle fonction est-elle bonne ? En existe-t-il d'autre(s) ?
- Y aurait-il quelque chose d'alternatif au cat qui par exemple planterait ($? != 0) si aucun flux n'arrive ? Dans tel cas, je pourrait traiter le cas d'un flux vide à l'intérieur de la fonction.

Sinon j'ai contourné le problème en imposant l'utilisation de passage de paramètre. On peut donc dire que mon problème est fonctionnellement résolu. Mais cette question me "turlupine" depuis quelques jours, et comme je n'aime pas rester sans réponse, je fais appel à vous "o grands maîtres du développement shell" ;)

Qu'est-ce que tu espères de mesAttributs=$(cat) ?

Utilise plutôt read mesAttributs
...
?

Bonjour,

Sans changer le script, il est possible de changer simplement son appel:

Code:

---

1 2	monScript arg1 arg2 arg3 monScript <<< echo arg1 arg2 arg3

---

Citation:

---

Envoyé par N_BaH

Qu'est-ce que tu espères de mesAttributs=$(cat) ?

---

Je constate que le pipe appliqué à la fonction est "tansmis" à la première commande gérant le pipe dans la fonction. J'ai mis cat pour l'exemple. J'utilise de cette manière awk dans d'autres fonction.
En fait, je souhaite récupérer les données transmises par le pipe, en faisant ce "mesAttributs=$(cat)", ces données sont transmise au cat et récupérées par ce dernier.
S'il y avait une commande magique permettant de récupérer tout ce qui vient de ce pipe, ça solutionnerait tout problème. On pourrait imager une commande du genre "mesAttribut=$(commandeMagique)".

Citation:

---

Utilise plutôt read mesAttributs
...
?

---

Je ne suis pas au taf et n'ai donc mas les moyens de tester maintenant, mais je crains que si aucune donnée n'est transmise, le read ne bloque lui aussi ?

Citation:

---

Envoyé par jmelyn

Bonjour,

Sans changer le script, il est possible de changer simplement son appel:

Code:

---

1 2	monScript arg1 arg2 arg3 monScript <<< echo arg1 arg2 arg3

---

---

Bonjour mon problème n'est pas au niveau du passage des paramètres mais de l'utilisation du pipe qui peut être blocant si aucune donnée n'est transmise à ce pipe :

Code:

---

1 2	unScriptQuiRetourneDesChosesOuRienDuTout|maFonction

---

Le problème se pose lorsque le script/fonction de gauche ne produit rien du tout.

C'est un problème général: cat (sans argument) lit sur stdin et recopie sur stdout, et ce jusqu'à la fin de chaîne. Donc blocage tant que fin de chaîne non détectée. Pareil avec read, mais cette commande accepte plus d'arguments, notamment un timeout pour éviter ce genre de blocage intempestif (-t nSec).

Code:

---

1 2 3 4 5 6 7 8

si le nombre d'arguments est différent de zéro alors mesAttributs vaut tous les arguments passés à maFonction sinon (s'il n'y a pas d'arguments) mesAttributs vaut 'cat' #mais cat quoi? fin_si afficher mesAttributs

---

J'avais pensé que tu souhaitais que l'utilisateur entre lui-même les arguments, c'est pourquoi je proposai 'read'...

Tout dépend de ce que tu veux faire dans le cas où il n'y a pas d'arguments passés à maFonction.
Tu peux éventuellement faire afficher un message, puis quitter la fonction en utilisant 'return'

Code:

---

1 2 3 4 5 6 7 8 9 10

maFonction() { if [ $# -ne 0 ] then mesAttributs="$*" echo "$mesAttributs" else echo "Il n'y a pas d'arguments, je quitte la fonction" return 1 fi }

---

...
?

GG pour le timeout du read, c'est une solution que je qualifierais de contournement.

Prenons un exemple concret.

J'ai développé une fonction "listeUtilisateursLogiciel" qui affiche les users utilisant un certain logiciel. Ce script peut ne rien afficher du tout si personne n'utilise le logiciel donné au moment où j'exécute le script.

Je souhaite écrire une seconde fonction "envoiMessage" qui envoi un message à des utilisateurs passés en paramètre.
la solution la simple est le passage par paramètres :

Code:

---

1 2 3 4 5 6

function envoiMessage { for user in $*;do # Traitement de l'envoi du message done }

---

Cela impose l'appel à la fonction de cette manière :

Code:

---

1 2	envoiMessage $(listeUtilisateursLogiciel)

---

Maintenant comment faire pour que la syntaxe pipée suivante soit acceptable ?:

Code:

---

1 2	listeUtilisateursLogiciel|envoiMessage

---

Je modifie donc le code de ma fonction :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

function envoiMessage { if [[ "$#" != "0" ]] ; then # Les noms de user sont passés en paramètre users=$* else # Il n'y a pas de paramètre donc les noms de user doivent être passé par pipe user=$(cat) # ou bien user=$(read -t1) fi # traitement de l'envoi du message }

---

Dans le cas ou personne n'utilise le logiciel (fonction listeUtilisateursLogiciel n'affiche rien) :
- avec le cat, sa bloque indéfiniment
- avec le read et timeout, c'est un peu mieux, ça se débloque au bout d'une seconde. Mais c'est pas encore parfait.
Si je comprends bien, le pipe fait que les données (noms d'utilisateur) arrive sur l'entree standard dans ma fonction. Si on pouvait tester la présence de données sur l'entrée standard, on pourrait directement faire un return en cas d'absence et ainsi éviter l'attente liée au timeout du read.

N'y aurait-il pas une syntaxe permettant de récupérer le contenu de l'entrée standard dans une variable, un genre de "variable < &0" ?

Ce que tu veux faire est une lecture non-bloquante. C'est possible à réaliser en C grâce à la fonction select(): On lit la socket et on retourne ce qu'il y a au moment de la lecture: soit rien, soit des caractères. Mais je ne pense pas que le shell soit capable de faire cela (quelqu'un peut-il me contredire?).

Pour sortir de cette impasse, il faudrait revoir ta fonction liste-Truc-Muche(): Soit elle renvoie une liste de noms (au moins un), soit elle renvoie une chaîne vide; en fait elle devrait renvoyer une fin de ligne comme le fait la commande echo "" qui affiche '\n', c'est-à-dire un caractère qui va dire à cat d'arrêter d'attendre.

@ N_BaH: la commande cat sans argument copie stdin vers stdout, tout simplement.

Voilà tu as tout compris !
Je sais que cela serait réalisable en codant une pseudo commande cat en C.
Mais c'est une question existencielle, à savoir si c'est réalisable en shell pur. C'est juste pour prise de connaissance de savoir si cela existe, car dans le cadre professionnel, j'ai utilisé plusieurs solutions de contournement qui fonctionnent parfaitement.

Bonjour,

Pourrais-tu décrire précisemment ce que renvoie ta fonction? Quelles sont les commandes utilisées pour renvoyer les données, et notammant lorsqu'il n'y a rien?