Vous n'êtes pas identifié(e).
-s fichier vrai si le fichier est non vide.
Pourtant dans un répertoire j'ai deux fichiers, l'un nommé fichier qui est non vide et l'autre nommé fichiervide qui ne l'ai pas.
Eh bien quand je lance :
J'ai le retour :
Pourtant c'est non vrai, puisque le fichier est vide, ça devrait donc rentrer dans le else !
Quelqu'un comprend-il pourquoi ça ne marche pas ?
Merci
Dernière modification par Hypathie (15-03-2014 12:27:03)
Hors ligne
Hors ligne
donc, ton soucis se situe au niveau de $fichiervide qui pointe ailleurs que voulu.
en effet $fichiervide représente une variable et non le nom de ton fichier.
edit : je n'ai pas pu m'en empêcher http://ensiwiki.ensimag.fr/index.php/Er … ipts_shell
c'est le genre de lecture que je ne pratique pas assez.
Hors ligne
Hors ligne
On peut aussi vérifier si le paramètre existe avec -z (vérifie si la chaîne est vide). En effet, si une variable n'est pas définie, elle est considérée comme vide par bash.
Pour ma part, j'ai déduis qu'être considérée comme vide par bash implique qu'elle est considérée comme vide mais existante.
L'exemple donné (qui fonctionne chez moi) :
#!/bin/bash
if [ -z $1 ]
then
echo "Pas de paramètre"
else
echo "Paramètre présent"
fi
Ce qui me fait penser que $ devant quelque chose dans les crochet d'un IF ne renvoie pas à une variable mais on contenu (valeur) de cette variable.
me le confirme encore le tableau de la même page qui présente les tests par exemple :
Condition Signification
-e $nomfichier Vérifie si le fichier existe.
Et effectivement comme dans mon #1 le test fonctionne ainsi :
Mais pas comme ceci :
Pourtant à la même page de ce site on a :
Inverser un test
Il est possible d'inverser un test en utilisant la négation. En bash, celle-ci est exprimée par le point d'exclamation « ! ».
Avec l'exemple :
Et là plus de $ devant fichier et moi du coup je me dis soit s'est un oubli soit j'ai rien compris !
Hors ligne
Hors ligne
Et là plus de $ devant fichier et moi du coup je me dis soit s'est un oubli soit j'ai rien compris !
N'utilisant pas (ou très peu) bash, je ne peux pas te dire pour l'instant.
J'ai essayé les différentes possibilités : fichiervide, $fichiervide, "$fichiervide".
Dans mon #4, je ne mets pas les guillemets pour -e mais je les mets pour -s
Hors ligne
avec le retour :
Pour le deuxième j'ai du mal à interpréter la réponse :
J'ai un retour de prompt : je crois que ça veut dire qu'il ne rentre pas dans le IF alors qu'il est vide. je dirais qu'il ne marche pas chez moi.
(ATA je crois que j'ai compris par rapport à mon #5 qu'il faut bien $ devant fichier dans le dernier exemple de la page openclassrooms à propos d'inverser le test. Et aussi pourquoi l'option -s ne marche pas. Je poste ce que j'ai compris pour vérifier auprès de toi ou ceux qui voudront bien si mon raisonnement est juste.)
Hors ligne
Pour le deuxième j'ai du mal à interpréter la réponse :
#!/bin/bash
vide=$1
test -s $vide || echo "$vide : fichier vide"
J'ai un retour de prompt
Sans doute que tu lui passes en paramètre un fichier non-vide (vérifie sa taille)
Dans le cas seulement d'un fichier vide, tu auras le retour nomfichier : fichier vide
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
En principe, il faut toujours mettre les guillemets à l'intérieur d'un [ ] autour les variables qui peuvent potentiellement être vides. Sinon, le shell peut estimer qu'il lui manque le paramètre (là encore, c'est sans doute dépendant du shell, mais mettre les guillemets est POSIX-compliant ).
Pour moi, ça l'fait pas :
me renvoie "ce fichier n'existe pas" dans tous les cas.
Hors ligne
-s la taille de ce fichier est supérieure à zéro
Donc je crois qu'on peut dire que -s se lit "vérifie que le fichier existe et qu'il est de taille supérieur à 0 octet. Donc un fichier vide fait plus de 0 octet même si il est vide et -s ne peut pas servir à vérifier si un fichier est vide. A moins de savoir combien fait en octet un fichier avec un seul caractère et de faire un truc (qui n'est pas de mon niveau) mais qui testerait si fichier vide est strictement inférieur à la taille que fait un fichier qui à un seul caractère. En priant que tout caractère à la même taille... ce que je ne sais pas non plus. Bref, dur de faire un test pour vérifier qu'un fichier est vide ou non vide !
Pour ce qui est de l'histoire du $ devant le non du fichier dans un teste sur ce fichier avec IF. Ce site confirme plutôt que le $ est nécessaire pour que cela marche, et qu'il renvoie bien à la valeur d'une variable considérée comme vraie je dirais par défaut.
Ou mieux dit même référence :
Commençons par distinguer soigneusement le nom d'une variable de sa valeur. Si variable1 est le nom d'une variable, alors $variable1 désigne une référence à sa valeur, la donnée qu'elle contient.
puis :
Attention
Une variable non initialisée a une valeur « vide (en anglais 'NULL') » - pas de valeur assignée du tout (mais pas zéro !).
if [ -z "$non_initialisee" ]
then
echo "\$non_initialisee est NULL."
fi # $non_initialisee est NULL.
Bien qu'il soit dangereux d'utiliser une variable avant de lui avoir assigné une valeur, il est possible de réaliser des opérations arithmétiques avec une variable non initialisée.
Bah alors tous les tests sur fichiers ou dossiers présentés dans le site openclassrooms sont dangereux alors ?
Sinon je ne sais pas si comme cela c'est moins dangereux mais ça marche :
Je ne comprends pas pourquoi chez toi certaine choses fonctionnent et pas sur ma machine ; il y a peut-être des versions différentes de Bash et on a pas la même ?
Dernière modification par Hypathie (13-03-2014 10:25:13)
Hors ligne
Hors ligne
marche dans les deux cas.
Hors ligne
Donc un fichier vide fait plus de 0 octet même si il est vide et -s ne peut pas servir à vérifier si un fichier est vide.
Hors ligne
Le set +u vous enverra ballader à chaque fois que vous utilisez une variable non-affectée, utile pour débugguer.
Le set +e arrêtera le script à la moindre erreur détectée, utile pour débugger et se forcer à écrire des scripts propes.
Le set +x affiche toutes les ligner exécutées, utile pour débugger.
Exemple :
Je ne sais pas si c'est dans le wiki, mais ça aussi mériterait d'y être
@Hypathie: OpenClassRoom, c'est bien, mais ça ne veut pas dire que les tutos sont parfaits
Sur le wiki DF aussi il y a plein d'erreurs…
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
puis ouvre un terminal et tape le chemin du script... et ENTER
Slyfox
Dernière modification par Slyfox (13-03-2014 19:28:35)
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Encore un bashisme : [[ ]] n'est pas une syntaxe posix valide Blblbl
Ah bon ??? t'as une source ... Blblbl
Slyfox
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
je ne vois de posix ?
Dernière modification par Hypathie (14-03-2014 15:20:56)
Hors ligne
Bash c'est bien le shell par défaut,
Il n'y a pas si longtemps, je me suis retrouvé avec une installation neuve dont le shell n'était pas bash.
des posix, ici ? Oh !
Hors ligne
Retour :
Et
Retour :
Voilà mais je ne sais pas si POSIX
Hors ligne
Voilà mais je ne sais pas si POSIX
Très franchement je me suis pas vraimement inquiter de savoir si mes scripts étaient POXIS ou non... il faut dire que j'ai appris le Bash de manière autodidacte et j'ai peut-être appris des choses pas tout à fait correct. (on trouve de tout sur le net...)
Maintenant je pense que des sites comme ceux-ci doivent être fiable : http://abs.traduc.org/abs-6.4.05-fr/ ou http://fr.openclassrooms.com/informatiq … ipts-shell après en cherchant on peut en trouvé d'autres.
Sinon concernant POSIX j'ai fait une recherche car cela m'intéresse aussi d'avoir plus d'info là dessus : http://linuxfr.org/users/patrick_g/jour … x-ou-posix
Sinon je pense que man bash dans un terminal doit pouvoir répondre à notre question... lien de man bash : http://www.linux-france.org/article/man … ash-1.html
Slyfox
Dernière modification par Slyfox (15-03-2014 16:31:23)
Hors ligne
Maintenant je pense que des sites comme ceux-ci doivent être fiable
Il en est des sites internet comme de la vie courante : on se doit d'adopter une certaines réserve quant à l'information dispensée.
C'est aussi ça se prendre en main et pouvoir agir en connaissance de cause.
Hors ligne