• # Qlqs différences

    Posté par  . Évalué à 10.

    Dans un répertoire initialement vide :
     % [ foo == f* ] && echo oui || echo non
    non
     % touch foo
     % [ foo == f* ] && echo oui || echo non
    oui
     % touch foo2
     % [ foo == f* ] && echo oui || echo non
    -bash: [: too many arguments
    non
    Bref tu l'a compris, dans un [ ... ] bash fait l'expansion des jokers sur les noms de fichiers. [[ ... ]] ne le fait pas lui, il utilise les jokers comme des patterns dans la comparaison de chaine, et donc [[ foo == f* ]] sera toujours vrai. En plus, le [[ ... ]] de bash-3 introduit un opérateur très intérressant, =~, pour évaluer des regexp. Y'a pas ça dans [ ... ] :
    % [[ XXXfoo123XXX =~ "(foo)([0-9]+)" ]] && echo plop
    plop
    % echo ${BASH_REMATCH[0]}
    foo123
    % echo ${BASH_REMATCH[1]}
    foo
    % echo ${BASH_REMATCH[2]}
    123
    Et puis [[ ... ]] il est souvent plus robuste, genre il ne t'en voudra pas de ne pas quoter un variable vide :
    % unset plop
    % [ foo == $plop ] && echo plop
    -bash: [: foo: unary operator expected
    % [ foo == "$plop" ] && echo plop
    % [[ foo == $plop ]] && echo plop
    Pareil avec le "word spliting" des chaines avec des espaces :
    % foo="a b c"
    % [ "a b c" == $foo ] && echo plop
    -bash: [: too many arguments
    % [ "a b c" == "$foo" ] && echo plop
    plop
    % [[ "a b c" == $foo ]] && echo plop
    plop
    (m'enfin bon, ça reste une bonne habitude de quoter systématiquement ceci dit). En résumé, voilà les 2 différences aux quelles j'ai pensé perso :
    • expansion différente (pas de filename ou de word splitting dans le [[ ... ]], or c'est souvent ce qu'on ne veut pas justement, donc ça tombe bien)
    • un opérateur =~ qui permet d'éviter bien des forks de grep et autres sed inutiles pour les cas simples
    Comme ça là je n'en ai pas d'autre qui me vienne.
    • [^] # Re: Qlqs différences

      Posté par  . Évalué à 1.

      et pour aller plus...

      Recemment j'ai voulu comparer dans un script si le non de mon fichier faisait 8 digits dans le nom. genre 12345678.pdf est valide

      j'ai voulu ecrire quelque chose comme:

      if [ $monfichier = [0-9]{8}.pdf ] then
      echo "ok"
      else
      echo "nok"
      fi

      mais ca ne marche pas
      y compris if [ $monfichier = [0-9]\{8\}\.pdf ] then ...
      ou encore if [[ $monfichier = [0-9]\{8\}\.pdf ] ] then ...

      une idée pour avoir des expression regulieres dans le test?

      sinon j'ai du faire
      if [ `expr $pdfFile : "^[0-9]\{8\}\.pdf$"` -eq 0 ] then echo nok
      else echo ok
      • [^] # Re: Qlqs différences

        Posté par  . Évalué à 2.

        Bah comme marqué dans le commentaire auquel tu réponds :

        % [[ 12345678.pdf =~ [0-9]{8}.pdf ]] && echo "voila"
        voila

        Mais ça ne marche qu'en bash-3.0. En bash 2.x, tu n'as pas de "=~" pour faire des regexps, mais seulement des patterns testables avec "=". Ton test devient alors :

        % [[ 12345678.pdf = [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9].pdf ]] && echo "voila"
        voila

        ...et c'est sûr, c'est moins joli. Dans ce cas là, effectivement, c'est effectivement plutôt par expr ou même grep ou autre qu'il faut passer.

        Quant à utiliser des simples crochets, bah ça ne marchera de toute façon pas avec des regexp, et puis avec la version longue et moche ça ne marchera que si ton fichier est dans le répertoire courant et qu'il est le seul avec un nom de ce genre là. Bref l'expansion se fait sur les noms de fichiers, alors que tu veux un match sur une chaine. À éviter donc.
  • # glou

    Posté par  . Évalué à 4.

    au fait, pour ceux qui ne le sauraient pas,
    [ est un programme qui se trouve dans
    /usr/bin, ce qui explique que [toto=titi]
    ne fonctionne pas (le shell lance le programme [toto=titi])
    alors que [ toto=titi ] oui.
  • # petit jeu

    Posté par  . Évalué à 1.

    Dans les deux commentaires d'au-dessus, [ [ a été remplacé par [, et ] ] par ]. Saurez-vous trouver où ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.