J'ai une question bête, et je cherche une solution ... qui ne me viens pas:
Dans un de mes shell je liste les fichiers d'un repertoire, et j'effectue un traitmement:  
 

 
là sa marche on a la liste des fichiers
 
Mais, si un fichier contient un espace par exemple "fichier con.txt" ... sa me fera deux lignes.  
Avez vous une solution élegante, simplissime, pour l'avoir sur une seule ligne ?

Evidemment, "for" utilise l'espace pour séparer ses éléments !!!
 

Le "read" utilise le "return" pour séparer ses éléments... et renvoie "faux" quand il ne lit plus rien. D'où la solution élégante et simplissime suivante :

 
Seul danger: si tu implémentes une variable dans la boucle (style un compteur), elle est perdue à la fin du "done" (hé oui, pipe => nouveau processus). Il y a des moyens élégants mais moins simplissimes de pallier à ce problème...

arglll... trop facile... je la met de côté celle-là...

 
 
je viens de faire le test, voici mon code
 

 
et bien ca me renvoie ttttttttttt sous AIX 3 5    et    HP-UX B.11.00 U
et sdfgsfd sous Cygwin  
 
c'est en contradiction avec ce que tu dis, malgré que je comprend tout a fait ton raisonnement,
 
et ca m'interpelle ............ :-(
 
d'ailleurs je suis persuadé que j'avais ce probleme sur HP il y a 10 sur une plus vielle version donc ....
 
 
 
qu'en penses tu ?

tiens, j'avais tellement confiance au code que je me l'etait mis de coté... et puis je viens de verifier, sous mon sh [debian/sarge] sa roule. j'ai pas d'autre environnement pour le tester à l'instant. ça serais une spécificité là dessus, ou une implentation d'une certaines normes (que je ne connais pas) ???

j'ai pas saisi comment ca reagit sur sarge, tu as "sdgfdfgsdf" ou "tttttttt" ?

oups, j'ai "sdgfdfgsdf"  
 
comme pour cyg... un linux quoi pour moi c'est sans doute des subtilités des shell

 
Je suis HYPER heureux que t'aies testé. Parce que j'ai testé ce genre de code dans différents shells et j'ai remarqué qu'en ksh, on a effectivement remontée de la valeur (à moins qu'il n'y ait pas de sous-processus).
Mais dans les autres Bourne shells (sh, bash), TOTO sera vide.
 
J'avais déjà posé la question sur des forums Unix mais j'ai jamais eu de vraie réponse expliquant la raison de cette différence en ksh
 
Mais c'est bien de tester des trucs comme ça. Ca montre qu'on est "aware"  

qq tests :
 
a votre avis, qu'affiche ceci :
 

 
et bien ca affiche "A"  !!!! meme sur mon AIX (en ksh) !!!
donc effectivement, on a logiquement 2 processus fils et on perd la nouvelle affectation de toto.
 
test N°2 :

le resultat est "A" sur AIX (en ksh) et cygwin
 
test N°3 :

 
ca repond "A" en cygwin et en bsh sous AIX
et B en AIX (ksh ,sh, tsh)
 
 
c'estquand meme delirant, considerons le ksh du AIX : si l'affectation est au debut (test 2) je la perds, et si l'affectation est dans le do/done du while (test 3) je la conserve !!!!!!
 
Franchement, j'aimerais bien avoir une explication... je ne sais pas ou la chercher .....
 
et ben c est un beau bordel....

J'aime bien tes tests... surtout les 2 premiers où tu pipes aucun flux. Mais tu as effectivement mis le doigt sur de curieuses trouvailles... surtout que dans les 2 premiers tests, l'affectation "toto=B" se fait avant chaque pipe.
 

Moi je comprends que dalle. Ptet poser la question à Steve Bourne (oui, je l'appelle Steve en privé mais il veut pas que cela se sache   )

ok, de mon coté j'appelle David Korn ...  
 
ce WE j essaierai en pdksh sur cygwin...

 
 
vachement interessant ces problèmes de "portabilité" de script.... j'appel balmer en sms/private, je suis  sur de le faire triper