Discussion :

[N_BaH]

qui est le couillon qui vous enseigne l'emploi systématique des accolades lors du Développement de paramètres ?
${variable} -> $variable.

c'est comme utiliser l'écriture inclusive lorsque le genre de l'objet décrit·e n'est pas ambigu·e.

[disedorgue]

Mouais, ici c'est dur de dire ça, car c'est cohérent, tout le code est implémenté de la sorte...

Je serais d'accord avec toi si c'était fait au doigt mouillé.

Et dans certaines conditions, comme du parsing depuis d'autres langages, ça simplifie énormément la chose.

[N_BaH]

"au doigt mouillé", ou systématiquement, si ça n'a pas d'utilité (concaténation, remplacement...), c'est i nu ti le (#tautologie ); et, évidemment, si c'est inutile, il n'y a pas lieu de s'en servir.

[disedorgue]

Je serais d'accord de son inutilité lorsque cela sera cohérent, c'est à dire quand on pourra écrire $array[n] sans être obligé d'écrire ${array[n]} parce que là, pour le coup, ça fait du non abouti...

[N_BaH]

c'est tout à fait cohérent : ça participe du Remplacement des paramètres.

[disedorgue]

Non, car les [] n'entre pas dans le nommage d'une variable, donc le shell pourrait avoir la facilité d'écriture sans les accolades.
Et on pourrait ainsi avoir la forme: ${!var}[n] en plus de la forme ${!var[n]}

En plus, je ne prends pas position sur le fait d'encadrer ou non une variable, je prends position sur le fait d'être cohérent tout du long, que cela soit une bêtise ou pas

[N_BaH]

donc, on pourrait écrire des ... tout au long d'une thèse et obtenir son doctorat, parce que l'ensemble est cohérent ?

je ne vois pas de différence entre la référence à un élément d'un tableau (entre[] : ${tableau[indice]}) et la référence à un certain nombres de caractères depuis un nombre de caractères donné (entre :: : ${var:début:longueur}).

[disedorgue]

donc, on pourrait écrire des ... tout au long d'une thèse et obtenir son doctorat, parce que l'ensemble est cohérent ?

Il y a tout de même une différence d'écrire sa thèse tout en majuscule et écrire des ... tout du long (en plus, sans être méchant, je pense que pour le coup, dans la thèse on trouvera plus facilement ${var} que $var).

je ne vois pas de différence entre la référence à un élément d'un tableau (entre[] : ${tableau[indice]}) et la référence à un certain nombres de caractères depuis un nombre de caractères donné (entre :: : ${var:début:longueur}).

Je ne vois pas trop le rapport, à part si tu veux dire que les tableaux deviennent inutiles () .Sinon, la différence, c'est que dans un cas on ne calcul pas la position de l'indice.

[N_BaH]

dans la thèse on trouvera plus facilement ${var} que $var

au XIXè siècle, peut-être. Maintenant, l'impression à fait suffisamment de progrès pour qu'on puisse distinguer typographiquement le texte et le code.

Je ne vois pas trop le rapport

les [] n'entre pas dans le nommage d'une variable

les : n'entrent pas non plus dans le nommage de la variable.
mais c'est valable pour tous les caractères qui indiquent une modification lors du Remplacement des paramètres.
j'ai pris les :, pour l'exemple, parce qu'ils permettent de sélectionner une partie d'une variable, comme un indice permet d'indiquer une partie d'un tableau.

[disedorgue]

Donc, pour une thèse, on peut l'écrire toute en majuscule, moi ça me va.

Concernant le ${var[n]} et le ${var:x:y}, la différence est que dans un cas on est sur un type de variable qui est un tableau dans l'autre, le :: ne dit rien du type.

D'ailleurs un exemple qui montre bien que le tableau n'est pas traité au même niveau:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
$ foo=(titi tutu toto)
$ echo ${foo[*]:0:1}
titi
$ echo ${foo[*]:0:2}
titi tutu
$ echo ${foo[*]:0:3}
titi tutu toto
$ echo ${foo[*]:1:3}
tutu toto

[N_BaH]

ça ne change rien, ce sont des variables; de "type" différent, mais des variables, dont les Remplacements sont décrits au même endroit dans le man.
les tableaux requièrent les accolades pour être développées correctement, alors que pour les variables les accolades sont inutiles par défaut.

<légère mauvaise foi>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ tablo=( abc def ghi )
$ echo ${tablo:1:1}
b

</légère mauvaise foi>

sans indice, un tableau affiche son premier élément.

[disedorgue]

C'est justement ce que je reproche: que les tableaux requièrent des accolades pour être développés alors que l'on devrait pouvoir s'en passer.

Surtout qu'il sait faire la différence quand on voit qu'il sait construire foo[1]=bar.

Pour la variable simple, je te concède que je ne mets les accolades que quand c'est obligatoire ou quand je sais que cela sera utile pour d'autres critères, comme par exemple un besoin de parsing depuis un autre langage.

[N_BaH]

besoin de parsing depuis un autre langage.

tu peux nous montrer un exemple, stp ?

[disedorgue]

J'ai des fichiers de conf tout simple en format compréhensible par le shell, donc juste à sourcer quand je suis en shell, par contre j'ai des fois besoin d'utiliser ces fichiers de conf dans un langage comme python, perl, C,...

Et comme ces fichiers ne sont pas préalablement sourcé avant, le besoin dans ces différents langages c'est de pouvoir développer les variables qui utilise d'autres variables, et donc, pour simplifier le parsing depuis ces autres langage, on a mis en place la règle que dans ces fichiers de configuration, les variables doivent être dans le format ${VAR}.

PS: ce n'est pas la seule règle que l'on a déterminé pour nos fichiers de configuration, mais elle en fait partie (et uniquement pour nos fichiers de configurations).

[N_BaH]

oui, mais là, c'est votre cuisine; ce n'est pas lié à l'emploi des variables ±directement dans le shell.
vous pourriez utiliser une autre convention, non ?
par exemple :

Code fichier de conf :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
bla bla |sh uneVar| bla bla
tralala |sh autreVar| tralala

[disedorgue]

Oui, mais on ne peut pas non plus rejeter cette forme d'écriture dans un script, elle existe, et je ne pense pas que si on doit décider un jour laquelle des deux doit perdurer, ce soit celle sans accolade qui gagnera:
la forme avec accolade prête moins à confusion que la forme sans accolade (et comme en plus, on a tendance à choisir le pire des 2 maux )

[N_BaH]

je peux imaginer, mais ça n'arrivera pas. Ce serait d'un lourdingue !

aujourd'hui, mettre des accolades tout le temps dans un shell, c'est faire du vélo avec des stabilisateurs*.

--
* des petites roues.

[hizoka]

Salut, je n'ai pas vos niveaux mais j'utilise quasiment toujours des accolades afin d'avoir un style cohérent.

Et ça évite de passer à côté d'erreur toute bête, genre il manque un espace :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
echo "$Nompense que..."
echo "${Nom}pense que..."

Je trouve que c'est une habitude visuelle car des qu'on veut développer les variables (que ce soit pour les tableaux ou // ,, /?...), il faut les {}, donc je les mets par défaut.

Et niveau temps d’exécution avec une boucle de 100 000 tours :
$x = 2.600s
${x} = 2.800s
On peut pas vraiment ire que ça a un impacte sur la charge de travail.

C'est une considération visuelle, au même titre que de sauter des lignes, de laisser plus d'espace, de mettre des tabulations...
Car c'est inutile niveau code mais pas niveau visuel.

Peut-être inutile mais sans conséquence alors que ça me plaît lorsque je lis le code, du coup je le fais :p

Mais tu as raison, je vais lancer une pétition pour obliger l'utilisation obligatoire des accolades pour que ma façon de faire devienne la norme

[N_BaH]

si ça ne sert pas, je ne m'en sers pas. je l'ai déjà dit ?
par contre, si c'est utile (remplacements, concaténation...), ça attire l'œil sur un comportement "inhabituel".