Discussion :

[jibe74]

Salut,

Un petit truc pour lequel je n'ai pas su trouver de méthode simple : j'ai plusieurs fichiers nommés toto1, toto2... totoN. Je voudrais tester si un ou plusieurs d'entre eux existe(nt).

Un truc du genre

Code :

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

if [ -e toto* ]

mais si ça fonctionne bien avec toto1 (en ne testant que lui, bien sûr), on obtient une erreur si on met un nom générique...

Bien entendu, je ne sais ni combien il y a de fichiers, ni leurs noms, simplement qu'ils commencent par "toto".

Quelle est la méthode la plus simple ?

[qqcvd]

Code :

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

if ls toto* > /dev/null 2>&1 ; then echo OK ; else echo KO ; fi

[paissad]

Bonjour,
Pour vérifier si un répertoire est vide ...

Code :

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

[ "$(ls -A /repertoire)" ] && echo "Non vide" || echo "Vide"

Cordialement,

[jibe74]

Salut,

Merci à tous les deux !

La méthode de qqcvd fonctionne bien, mais je recherchais quelque chose de plus élégant (je trouve un peu lourd les redirections de sortie).

Celle de paissad me plairait mieux, mais je n'arrive pas à la faire fonctionner dans mon cas (recherche d'existance d'un ou plusieurs fichiers toto*, et pas test si un répertoire est vide ou non). Même en corrigeant l'erreur simple/double quote... Pourrait-elle s'appliquer à mon cas, et comment ?

[N_BaH]

Bonjour,

en bash ?

Code :

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

1
2
3
shopt -s nullglob
listeTotos=( toto* )
test ${#listeTotos[@]} -gt 0 && echo "Vous avez des totos" || echo "pas de poux, pas de lentes"

et ainsi la liste des fichiers toto* est disponible dans un tableau/liste!

[qqcvd]

Bonjour,

en bash ?

Code :

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

1
2
3
shopt -s nullglob
listeTotos=( toto* )
test ${#listeTotos[@]} -gt 0 && echo "Vous avez des totos" || echo "pas de poux, pas de lentes"

et ainsi la liste des fichiers toto* est disponible dans un tableau/liste!

que signifie la 1ere ligne?

[N_BaH]

shopt: shopt [-pqsu] [-o] [nom_opt ...]
Active ou désactive des options du shell.
[...]

nullglob
Si existante, bash autorise les motifs ne correspondant à aucun fichier (voir Développement des chemins plus haut) à se développer en une chaîne vide plutôt qu'en une valeur littérale.

[jibe74]

Salut,

Super, merci !

Tout à fait ce que j'espérais trouver, et du même coup je découvre moi aussi l'utilisation et l'intérêt de cette option nullglob

[jack-ft]

Bonjour,

en bash ?

Code :

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

1
2
3
shopt -s nullglob
listeTotos=( toto* )
test ${#listeTotos[@]} -gt 0 && echo "Vous avez des totos" || echo "pas de poux, pas de lentes"

et ainsi la liste des fichiers toto* est disponible dans un tableau/liste!

N_baH, tu préconises régulièrement de ne pas utiliser "ls" dans les scripts.
Tu proposes également une élégante solution pour tester l'existence de fichiers en bash.

Je n'utilise jamais ls dans un script BASH.
si j'ai besoin de renseignements sur des fichiers, j'utiliserai plutôt stat, dont je peux contrôler complètement l'affichage, ainsi point de cut, sed, awk
si j'ai besoin de filtrer la liste, je peux utiliser les motifs génériques*, et les correspondances étendues* => grep
si j'ai besoin de la liste des fichiers d'un répertoires, j'utiliserai un tableau.

pour l'affichage en colonne : printf '%s\n' monRep/*

Et si j'ai juste simplement besoin de savoir s'il existe 0 ou bien pas 0 fichiers dont le nom correspondrait à "toto*"?

Et si, de plus, je suis (arbitrairement) limité à un ksh, qui, qui plus est, doit tourner sur toutes sortes de plateformes, que préconises-tu?

Avec utilisation de ls, on a le classique: ls toto* > /dev/null 2>&1 ; echo $? qui semble assez bien résister à la présence de fichiers contenant des espaces ou returns.

Avec le développement des chemins, j'ai trouvé ceci:

Code :

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

[ "$(echo toto*)" = 'toto*' -a ! -f 'toto*' ] ; echo $?

qui n'est vrai que lorsqu'il n'y a pas de fichier dont le nom matche "toto*"
(le test [ ! -f 'toto*' ] permettant d'éliminer le cas où il y a (comme par hasard) un fichier dont le nom serait juste(ment) 'toto*').

Merci d'avance
)jack(

[N_BaH]

Et si, de plus, je suis (arbitrairement) limité à un ksh, qui, qui plus est, doit tourner sur toutes sortes de plateformes, que préconises-tu?

je ne changerais rien : ksh (ksh93, pdksh, mksh (il y en a d'autres ?)) supporte les tableaux.

Edit: enfin, si, il faut trouver un équivalent portable de shopt.

[jack-ft]

je ne changerais rien : ksh (ksh93, pdksh, mksh (il y en a d'autres ?)) supporte les tableaux.

Mouais... je demande à voir... d'ailleurs, c'est un peu tout vu...

sous AIX 6.1:

Code :

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

1
2
3
4
5
$ shopt -s nullglob
ksh: shopt:  not found.
 
$ listeTotos=( x* )   
ksh: 0403-057 Syntax error: `(' is not expected.

Cela dit, pour être tout à fait honnête, je crois que ce n'est pas un ksh93!
mais je ne sais pas comment vérifier:

Code :

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

1
2
3
4
$ echo $KSH_VERSION
 
$ ksh --version
--version: 0403-010 A specified flag is not valid for this command.

Ah! si! J'me souviens. Y a le C-v:

Code :

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

$ Version M-11/16/88f

Bon, ben, du coup, c'est sûr: c'est un ksh88! (c'est probablement pour ça que j'ai tant de problèmes de compatibilité avec le pdksh de linux...)

Edit: enfin, si, il faut trouver un équivalent portable de shopt.

Euh... c'est jouable, ça?
J'sais pas pourquoi, mais j'ai des doutes... (surtout avec un ksh88!)
)jack(

[jack-ft]

Bonjour,
Pour vérifier si un répertoire est vide ...

Code :

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

[ "$(ls -A /repertoire)" ] && echo "Non vide" || echo 'Vide"

Cordialement,

aux guillemets près...je plussoie...

Code :

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

[ "$(ls -A /repertoire)" ] && echo "Non vide" || echo "Vide"

[Sve@r]

Code :

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

if ls toto* > /dev/null 2>&1 ; then echo OK ; else echo KO ; fi

La méthode de qqcvd fonctionne bien, mais je recherchais quelque chose de plus élégant (je trouve un peu lourd les redirections de sortie).

Code :

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

ls toto* 1>/dev/null 2>&1 && echo OK || echo KO

Salut
Personnellement je trouve cette solution très élégante. Elle résume superbement le principe de base du shell où chaque programme est un booléen et être donc utilisé comme simple palpeur. Cette solution est 100% portable tout type de shell issu du Bourne Shell originel. Elle peut même remplacer le test -e du bash (généralement c'est un exo que je donne à mes élèves => trouver un équivalent de test -e dans un environnement où cette option n'est pas connue)

De plus je n'ai jamais trouvé de cas de script où, si un ls est nécessaire, cela poserait problème de le mettre...

Autre exemple où la redirection, que tu trouves si lourde, te tirera pourtant une belle épine du pied: traiter un fichier en écrasant celui-ci par le résultat du traitement
Solution n° 1: passer par un fichier temporaire.

Code bash :

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

1
2
cat fic1 | traitement >/tmp/fic2
mv /tmp/fic2 fic1

Ca semble correct jusqu'au moment où on lance le même programme 2 fois en parallèle. Superbe collision sur /tmp/fic2. Là on cherche une solution et on pense au numéro de processus

Code bash :

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

1
2
cat fic1 | traitement >/tmp/fic$$
mv /tmp/fic$$ fic1

Dommage toutefois cette création de fichier intermédiaire.

Solution n° 2: passer par un canal numéroté associé au fichier

Code bash :

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

1
2
3
exec 3<fic1
rm -f fic1   # Impératif pour que le nom "fic1" soit déconnecté de l'inode associée sinon la redirection écrasera le contenu de cette inode
cat 0<&3 | traitement >fic1

Merci les redirections. Après tout, si elles existent, c'est qu'il y a une raison et c'est donc dommage de passer à coté...

[jibe74]

Salut,

Déterrage

Je retombe par hasard sur cette discussion : considérant mon problème résolu, je ne l'ai plus suivie

Attention de ne pas me faire dire ce que je n'ai pas dit (mais bon, c'est vrai qu'on pouvait l'interpréter de différentes manières) : je trouvais lourdes les redirections dans ce cas, et cela surtout parce que je pensais qu'une solution plus élégante pouvait être trouvée, ce qu'a fait N_BaH. Après, qu'il y ait des cas où les redirections soient une bonne, voire meilleure solution est une évidence, et tu en apportes la preuve.

Maintenant, le débat d'experts qui a eu lieu me laisse un peu sur ma faim ! Ok, si on part du principe que les redirections sont une solution élégante, on fait tout en une ligne. Mais comme il ne me semble pas que ce soit seulement un débat entre partisans d'un code compact et ceux d'un code clair et facilement lisible (je suis plutôt de la seconde catégorie), je serais volontiers preneur de quelques précisions sur les avantages et inconvénients de ces deux codes. Sachant bien sûr qu'au final, le résultat est le même, et que la méthode pour y arriver n'est souvent qu'une question de goût ou de choix. Mais justement, pour choisir, il faut bien connaître les avantages et les inconvénients de chaque méthode !

[Sve@r]

Mais comme il ne me semble pas que ce soit seulement un débat entre partisans d'un code compact et ceux d'un code clair et facilement lisible (je suis plutôt de la seconde catégorie), je serais volontiers preneur de quelques précisions sur les avantages et inconvénients de ces deux codes.

Non non, pas entre "code compact" et "code lisible" mais entre "travailler en mémoire" et "travailler avec des fichiers". Je préfère de loin travailler un max en mémoire plutôt que d'utiliser des fichiers temporaires qui ont l'inconvénient

1. de nécessiter des accès disques (donc 100 fois plus long que des accès mémoire)
2. de nécessiter des protections concernant leur nom et les collisions qui peuvent s'en suivre
3. de rester présents si le script s'interromp avant d'avoir pu les effacer (bon si on travaille dans /tmp ce problème est moindre car il est cleané au démarrage mais tous ne le font pas)

Ensuite tu as aussi d'autres contraintes. Par exemple je travaille sur de multi-environnements (Linux, Aix, Unix). Je n'ai pas forcément toutes les dernières options et donc j'essaye d'éviter les trucs exotiques (je travaillais en Bourne Shell de base et ce n'est que dernièrement que j'ai décidé de passer à bash considérant que je le trouverais maintenant de partout). Donc forcément mes méthodes et exemples sont issus de mes habitudes...

Concernant la compacité et la lisibilité, c'est un peu un faux débat. Prenons mon premier exemple; ls toto* 1>/dev/null 2>&1 && echo OK || echo KO. Je joue ici avec un raccourci parfaitement légal basé sur cmd1 && cmd2 et cmd1 || cmd3 que je pense assez clair pour qui connait ces deux outils et leurs rôles respectifs. On peut avoir un souci de lisibilité quand les commandes sont très très longues, style

Code bash :

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

commande_super_super_longue_avec_plein_d_options  1>/dev/null 2>&1 && autre_commande_super_super_longue_avec_plein_d_options || encore_autre_commande_super_super_longue_avec_plein_d_options

Mais dans ce cas, tu as une astuce permettant d'avoir la même chose en plus clair: le backslash qui inhibe l'effet spécial du caractère qui le suit. Par exemple qu'est-ce qui fait que le shell exécute une instruction ? C'est quand il rencontre soit un point-virgule , soit un retour à la ligne. Si on veut donc utiliser l'un ou l'autre de ces caractères sans qu'ils produisent cet effet, suffit de les backslasher. Ce qui donnera dans mon exemple

Code bash :

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

1
2
3
commande_super_super_longue_avec_plein_d_options 1>/dev/null 2>&1\
    && autre_commande_super_super_longue_avec_plein_d_options\
    || encore_autre_commande_super_super_longue_avec_plein_d_options

Et tu te retrouves avec un résultat identique mais avec un code un peu plus aéré donc un peu plus clair.

je trouvais lourdes les redirections dans ce cas, et cela surtout parce que je pensais qu'une solution plus élégante pouvait être trouvée, ce qu'a fait N_BaH

Question de choix. Il active une option particulière (qui pourrait avoir un effet indésirable dans une autre partie de ton code) et génère ensuite un tableau pour compter son nombre d'éléments. Ceci dit, effectivement il ne fait pas appel à une commande externe et sera alors (je pense) plus rapide. Mais comme il le dit, ça ne peut tourner dans un shell qui accepte shopt et les tableaux. Donc encore une fois, question de choix (avantages/inconvénients/environnements/portabilité, etc etc etc...)

[disedorgue]

Bonjour,

Pour moi, l'une des syntaxes les plus propres et suffisamment portable quelque soit le shell:

Code :

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

1
2
3
4
5
6
7
8
$ ls totp*
ls: impossible d accéder à totp*: Aucun fichier ou dossier de ce type
$ ls toto*
toto1
$ if [ "$(echo toto*)" = "toto*" ] ; then echo KO ; else echo OK ; fi
OK
$ if [ "$(echo totp*)" = "totp*" ] ; then echo KO ; else echo OK ; fi
KO

En fait, je n'aime pas la syntaxe cmd1 && cmd2 || cmd3 car même si elle se prête bien à la résolution de ce problème particulier, on est sur un cas particulier, on considère que le echo OK ne tombe jamais en erreur.
Il ne faut pas oublier que la cmd3 s’exécutera si cmd1 ou cmd2 sortent en erreur.

[Sve@r]

Code bash :

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

1
2
3
4
$ if [ "$(echo toto*)" = "toto*" ] ; then echo KO ; else echo OK ; fi
OK
$ if [ "$(echo totp*)" = "totp*" ] ; then echo KO ; else echo OK ; fi
KO

Arf là je n'aime pas. Passer par un sous-shell (avec tous son mécanisme) juste pour comparer ce qu'il affiche avec une chaine attendue ça me choque. C'est tellement sympa ce fait de pouvoir tester la commande elle-même..., pourquoi donc l'encapsuler dans un autre mécanisme aussi lourd...?

En fait, je n'aime pas la syntaxe cmd1 && cmd2 || cmd3 car même si elle se prête bien à la résolution de ce problème particulier, on est sur un cas particulier, on considère que le echo OK ne tombe jamais en erreur.
Il ne faut pas oublier que la cmd3 s’exécutera si cmd1 ou cmd2 sortent en erreur.

Yep c'est vrai que cmd3 s'exécutera si la dernière commande exécutée avant le "||" sort en erreur. Et effectivement je me base sur le fait que echo est une commande toujours vraie (et jusqu'à présent, je n'ai jamais trouvé de contre-exemple
Une autre possibilité qui résout ce souci (mais juste pour l'exemple): ls toto* 1>/dev/null 2>&1 && (echo OK; true) || echo KO...

[N_BaH]

petite piqûre de rappel (si vous avez oublié) :

Code :

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

if command; then true; else false; fi

où command peut être test, ou une autre commande !

[disedorgue]

Je sais, mais je ne voulais pas utiliser ls, je voulais rester builtin, après pour éviter le sous-shell et la redirection de ls, on peut passer par un echo toto* | grep -q 'toto\*' dans le if mais là aussi on fait de la redirection, de plus l'option -q de grep n'est pas standard...

[jack-ft]

Pour moi, l'une des syntaxes les plus propres et suffisamment portable quelque soit le shell:

[HS grammaire]
L'expression "quel que soit" s'écrit TOUJOURS en 3 mots
(sauf dans une phrase comme "ce cochon a quelques soies utiles pour peindre" ).

"quel que soit le shell" veut dire "que le shell soit n'importe quel (shell)"

[/HS grammaire]