Discussion :

[disedorgue]

Pour moi, c'est plus 2 et 3 dans cette formulation pour test -v <-- ici on interroge l'ensemble pas le sujet lui-même
et le 3b devrait passer en 4 pour test -n <-- ici on interroge le sujet lui même

[jack-ft]

test -v est un "bashisme".

Ah bon ?

Code :

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

1
2
3
4
5
6
7
8
9
10
% ksh
$ echo $0
ksh
$ unset x; if test -v x; then echo 'x set'; else echo 'x unset'; fi
x unset
$ declare x; if test -v x; then echo 'x set'; else echo 'x unset'; fi
ksh: declare: not found
x unset
$ x=''; if test -v x; then echo 'x set'; else echo 'x unset'; fi     
x set

Si ça se trouve, mon ksh fait de la bashite aiguë...

[jack-ft]

Pour moi, '' est une chaine vide.
Et, pour moi, une chaine vide est une valeur. Vide, mais une valeur quand même...

Dans d'autres langages, il y a vraiment une différence entre x=NULL (pointeur vers rien) et x="" (pointeur vers une chaine vide allouée quelque part).

Pour moi, le test shell test -n "$v" est vrai lorsque la variable est assignée et son contenu est "une valeur non vide".

Ou bien il est faux lorsque soit la variable n'est pas assignée (unset) soit la variable est assignée, mais contient une chaine vide.

Code :

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

1
2
3
4
5
6
$ unset x; if test -n "$x"; then echo 'x set'; else echo 'x unset or empty'; fi
x unset or empty
$ x=''; if test -n "$x"; then echo 'x set'; else echo 'x unset or empty'; fi   
x unset or empty
$ x='y'; if test -n "$x"; then echo 'x set'; else echo 'x unset or empty'; fi
x set

[Sve@r]

Et, pour moi, une chaine vide est une valeur. Vide, mais une valeur quand même...

Effectivement là tu mets le doigt sur un détail important.
Jusqu'à hier, je ne voyais pas (en shell) comment dire "cette variable existe mais n'a pas de valeur". Car écrire var="" crée une chaine vide mais qui correspond à quelque chose. Si je devais faire le parallèle avec la bdd, une colonne avec contrainte unique peut avoir plein de null dans les différentes lignes qui remplissent la table mais n'aura qu'une et une seule chaine vide.

Or hier, N_Bah a donné cette instruction declare var (je la connaissais pour les tableaux mais je n'avais jamais songé à l'utliser directement de cette façon). Et il semble donc que cette instruction permette de faire la différence entre "variable contenant chaine vide" et "variable ne contenant rien".

Ceci dit, comme je l'ai dit hier, je ne vois pas encore dans quelle situation cela pourrait me servir. Surtout que même un test -z $var ne permet pas de distinguer le cas "variable ne contenant rien" et "variable contenant une chaine vide".

[disedorgue]

normal, le '-z' et le '-n' vérifie l'état d'une string pas d'une variable

[jack-ft]

Pour moi, c'est plus 2 et 3 dans cette formulation pour test -v <-- ici on interroge l'ensemble pas le sujet lui-même
et le 3b devrait passer en 4 pour test -n <-- ici on interroge le sujet lui même

Ben oui.

[partiellement HS]
La plupart du temps, j'ai travaillé avec des langages à pointeurs (lisp, LOGO, smalltalk, Objective-C, java, etc.).

Dans certains de ces langages, une variable est une entité de première classe, elle peut être manipulée comme un élément du langage.

Ainsi, en lisp, on peut demander à une variable son nom, sa valeur, sa plist, etc.
On peut mettre une variable (un symbole, et non la "valeur" de la variable) en contenu d'une autre variable.

Souvent le langage offre des raccourcis pour accéder à la valeur d'une variable. Ainsi, pour accéder à la valeur contenue dans la variable dont le nom est "x", en lisp, on écrit beaucoup plus souvent x que (symbol-value 'x) (ou que (symbol-value (intern "x")) !)

De même pour l'affectation, on écrira plus (setq x (quelque chose)) que (set 'x (quelque chose)). Entre autres, parce que ça aide considérablement les compilateurs dans un contexte lexical pour produire du code efficace.

Du coup, il faut que le langage ait des formes spéciales (comme les macros, par exemple), de manière à ce que certains morceaux ne soient pas évalués. Dans (setq x (quelque chose)), la forme spéciale "setq" prend son premier argument tel quel, non évalué, l'objet "la variable x", vérifie que c'est bien un symbole, puis évalue le deuxième argument (quelque chose), qui doit retourner quelque chose, et enfin met cette valeur retournée dans le slot "symbol-value" de la variable x.

En LOGO, on n'a pas de SETQ. Du coup, on doit bien distinguer les variables de leur contenu, par exemple (SET "X :Y) met dans la variable dont le nom est "X" le contenu de la variable dont le nom est "Y".

En bash et dans d'autres langages, on distingue les l-value (grosso modo à gauche du signe "=") des r-values (grosso modo à droite du signe "=").

J'imagine que le test test -v v considère l'argument suivant le "-v" comme le nom d'une variable et va chercher, quelque part dans l'environnement du shell, s'il y a une assignation/correspondance entre ce nom de variable et une valeur (même une chaine vide).

Alors que le test test -n "$v" commence probablement par construire une chaine (délimitée par les guillemets) dans laquelle il fait l'expansion des variables. J'imagine que, voyant la "chaine" de 2 caractères $v, il se rend compte qu'il doit trouver la valeur de la variable dont le nom est "v" et, pour ce faire, il va chercher quelque part dans l'environnement du shell, s'il y a une assignation/correspondance entre ce nom de variable et une valeur, puis, s'il n'y en a pas et que l'option "nounset" est positionnée par set -u, il déclenche une erreur ou bien sinon il remplace la "chaine" de 2 caractères $v par la valeur contenue dans la variable dont le nom est "v" (ou par une chaine vide s'il ne trouve pas de correspondance) et ensuite il fait le test correspondant à l'option "-n", c'est-à-dire vérifier si cette chaine est vide... Ouf !

Félicitations à ceux qui ont réussi à perdre leur temps à tout lire !
[/partiellement HS]

[disedorgue]

Pour la dernière partie de ton commentaire HS sur le shell et les variables, en fait le shell interprète d'abord les variables de la ligne puis ensuite il interprète le reste, ce que je veux dire par là, c'est qu'il n'a auncune notion de la commande qui va s'éxécuter lorsqu'il interprète les variables.

Bon après, j'ai lu ton message en diagonale, c'est peut-être ce que tu disais.

[N_BaH]

test -v est un "bashisme".

Ah bon ?
Si ça se trouve, mon ksh fait de la bashite aiguë...

beaucoup de "bashismes" (d'où les guillemets ) existaient au préalable dans d'autres interpréteurs de commande.
je dis "bashisme" par opposition à POSIXsms

[jack-ft]

Pour la dernière partie de ton commentaire HS sur le shell et les variables, en fait le shell interprète d'abord les variables de la ligne puis ensuite il interprète le reste, ce que je veux dire par là, c'est qu'il n'a auncune notion de la commande qui va s'éxécuter lorsqu'il interprète les variables.

Oui, tu as certainement raison. Je ne connais pas du tout l'implémentation (ni les spécifications détaillées) de l'interprète shell (bash ou autre), mais j'imagine que, lors de la phase d'analyse lexicale, le parser doit quand même générer des tokens différents pour '$v' et "$v", avant de remplacer, à bon escient, le bout de chaine $v par la valeur de la variable v...

[Sve@r]

mais j'imagine que, lors de la phase d'analyse lexicale, le parser doit quand même générer des tokens différents pour '$v' et "$v"

Surtout que les quotes simples inhibent l'action du $ => '$v' est donc simplement "caractère dollar + caractère v"...