Journal La sortie de `ls` vient de changer

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
38
20
fév.
2016

Bonjour à tous,

Avec la mise à jour de coreutils 8.25, la sortie par défaut de ls change un peu quand la sortie est un terminal (donc pas dans les pipes).

Voyez plutôt :

$ touch un
$ touch 'mes notes.org'
$ touch 'fichier@bin'

# Avant la version 8.25
$ command ls -l
total 0
-rw-r--r-- 1 user users 0 Feb 20 09:31 fichier@bin
-rw-r--r-- 1 user users 0 Feb 20 09:31 mes notes.org
-rw-r--r-- 1 user users 0 Feb 20 09:31 un

# Si version ≥ 8.25
$ command ls -l
total 0
-rw-r--r-- 1 user users 0 Feb 20 09:31 fichier@bin
-rw-r--r-- 1 user users 0 Feb 20 09:31 'mes notes.org'
-rw-r--r-- 1 user users 0 Feb 20 09:31 un

$ command ls -lF
total 0
-rw-r--r-- 1 user users 0 Feb 20 09:31 'fichier@bin'
-rw-r--r-- 1 user users 0 Feb 20 09:31 'mes notes.org'
-rw-r--r-- 1 user users 0 Feb 20 09:31 un

# Avec un pipe, rien ne change
$ command ls -l | cat
total 0
-rw-r--r-- 1 user users 0 Feb 20 09:31 fichier@bin
-rw-r--r-- 1 user users 0 Feb 20 09:31 mes notes.org
-rw-r--r-- 1 user users 0 Feb 20 09:31 un

Ceci ayant sûrement été décidé pour faciliter le copier-coller, puisqu'il faut rajouter des apostrophes droites (simples ou doubles) pour éviter que le shell ne coupe les noms.

Néanmoins, je n'ai pas trop vu de communications à ce sujet, et ça a été une surprise !

Si vous souhaitez revenir à l'ancien comportement, il y a plusieurs manières de faire :

ls -N
# ou
ls --quoting-style=literal # c'est la version longue du précédent
# ou
export QUOTING_STYLE=literal

  • # Beurk

    Posté par  . Évalué à 10.

    On peut maintenant croire que le fichier s'appelle 'mes notes.org' et non pas mes notes.org. Je n'aime pas cette façon de faire qui ajoute soi-disant de la facilité et va générer plein d'erreurs d'interprétation derrière.

    • [^] # Re: Beurk

      Posté par  (site web personnel) . Évalué à 8.

      Tout à fait. Soit on « quote » tout, soit rien, mais juste certains trucs c'est vraiment bizarre. D'ailleurs, ma première réaction a été de vérifier que le nom des fichiers n'avait pas changé !

      • [^] # Re: Beurk

        Posté par  . Évalué à 10.

        Et surtout les noms de fichiers sont affichés en rouge. Ça attire l'attention sur… le fait qu'ils contiennent une espace.
        Sérieux, chef de projet en mode boulet.

        Je propose que si un non ne contient pas d'extension du genre .xxx alors il est affiché en rouge clignotant.
        Et si le nom de fichier est en majuscule, il faut envoyer un email contenant un lien de validation nécessaire au déblocage de la commande ls.

        • [^] # Re: Beurk

          Posté par  . Évalué à 3.

          Qu'ils contiennent des caractères spéciaux, manifestement, pas juste un espace. Enfin, avec -lF.

  • # C'est mettre cette sortie par défaut qui me gène ..

    Posté par  . Évalué à 10.

    Que cette fonctioalité soit utile pour certains, je le conçois Mais mettre ça par défaut, c'est complètement ridiule. Il aurait fallu faire l'inverse : ajouter l'opton pour ceux qui la veulent.

  • # Source

    Posté par  (site web personnel) . Évalué à 4.

    Et parce qu'une bonne info ne vient pas sans source, voici :
    http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=08e8fd7e38f2dae7c69c54eb22d508b6517e66e5
    http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=109b9220cead6e979d22d16327c4d9f8350431cc

    • [^] # Re: Source

      Posté par  (site web personnel) . Évalué à 5.

      Ce qui manque c'est plutôt le bug ou fil de messages qui a abouti à la conclusion qu'il faut activer cette fonctionnalité par défaut.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # D'autres cas

    Posté par  (site web personnel) . Évalué à 8.

    Espace, retour chariot, multi-lignes :

    $ ls -ln
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 10:07 ' '
-rw-r--r-- 1 1000 1000 0 févr. 20 10:08 ''$'\n'
-rw-r--r-- 1 1000 1000 0 févr. 20 10:09 'a'$'\n''b'$'\n''c'


$ ls -lnN
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 10:07  
-rw-r--r-- 1 1000 1000 0 févr. 20 10:08 ?
-rw-r--r-- 1 1000 1000 0 févr. 20 10:09 a?b?c

    • [^] # Re: D'autres cas

      Posté par  (site web personnel) . Évalué à 5.

      Autant sur ce genre de cas je trouve ça génial de pouvoir avoir une version copiable facilement (on a tous eut un jour un nom de fichier venu d'un utilisateur avec les pires caractère du monde dans son nom), autant je rejoins les autres sur le fait qu'il ne faut pas foutre un truc pareil par défaut mais seulement avec une option.

      Au pire on a la possibilité d'inonder le bug tracker :D

    • [^] # Re: D'autres cas

      Posté par  (site web personnel) . Évalué à 10. 

      $ for style in literal locale shell shell-always c escape ; do echo $style; ls --quoting-style=$style -ln ; done
literal
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11  
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 ?
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 a?b?c
locale
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 «   »
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 « \n »
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 « a\nb\nc »
shell
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 ' '
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 '?'
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 'a?b?c'
shell-always
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 ' '
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 '?'
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 'a?b?c'
c
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 " "
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 "\n"
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 "a\nb\nc"
escape
total 0
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 \ 
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 \n
-rw-r--r-- 1 1000 1000 0 févr. 20 11:11 a\nb\nc

      • [^] # Re: D'autres cas

        Posté par  (site web personnel) . Évalué à 2.

        Dans le man, je vois ça :

        use quoting style WORD for entry names: literal, locale, shell, shell-always, shell-escape, shell-escape-always, c, escape

        Donc il y en a quelques uns en plus.

        Je vois que locale n'est pas forcément super pratique.

        Une idée de la différence entre shell, shell-always, shell-escape et shell-escape-always ? Elles sembles toutes les quater retourner la même chose.

        • [^] # Re: D'autres cas

          Posté par  (site web personnel) . Évalué à 4.

          Je me suis fait avoir par les locales, sachant que la page en anglais vient du paquet Debian coreutils 8.25-2 et la page en français de manpages-fr-extra version 20151231 :

                 --quoting-style=WORD
              use  quoting  style   WORD   for   entry   names:   literal,   locale,   shell,   shell-always,   shell-escape,
              shell-escape-always, c, escape

          et

                 --quoting-style=MOT_CLÉ
              utiliser le style d'encapsulation selon le MOT_CLÉ literal, locale, shell, shell-always, c ou escape

  • # shell touch

    Posté par  . Évalué à 2.

    Je n'ai pas d'avis à propos de cette évolution, par contre il y a quelque chose qui m'interpelle dans ce journal que j'ai déjà vu chez des collègues et que je n'explique pas : d'où vient cette idée d'utiliser touch pour créer des fichiers ? Le plus drôle est que certains croient que ça ne sert qu'à ça et ne comprennent pas quand ils voient cette commande dans un script.

    Si quelqu'un a une explication historique, ça m'intéresse.

    Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

    • [^] # Re: shell touch

      Posté par  . Évalué à 2.

      Salut,

      d'où vient cette idée d'utiliser touch pour créer des fichiers ?

      man touch :

      Update the access and modification times of each FILE to the current time.
      […]
      A FILE argument that does not exist is created empty, unless -c or -h is supplied.

      C'est fait pour ça.

      Matricule 23415

      • [^] # Re: shell touch

        Posté par  . Évalué à 6.

        Utilisation de très mauvaise foi du […] dans la citation de la page de manuel pour faire croire que c'est fait pour ça, j'ai failli y croire :) J'ai quand même vérifié, et c'est écrit clairement en titre

        touch - change file timestamps

        http://linux.die.net/man/1/touch

        On peut trouver au moins une douzaine de commandes de base qui créeront un fichier, la question est pourquoi touch est autant utilisé pour ça ?

        Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

        • [^] # Re: shell touch

          Posté par  (site web personnel) . Évalué à 6.

          Comme je l'ai dis plus bas, je pense que cela viens de la compilation et des Makefile. touch permet de créer facilement un fichier ayant la même date qu'un autre fichier, ou la date actuelle. C'est donc devenu un outil très pratique pour créer des fichiers vides qui est un des effet secondaires.

          Bref, c'est une commande assez simple dans la tradition des commandes UNIX. Leurs noms témoignent d'une certaine histoire et d'un coté humain. C'est moins fun que Fichier, Photo, Mail… à la mode actuellement mais tellement plus poétique !

        • [^] # Re: shell touch

          Posté par  . Évalué à 1.

          Salut,

          Utilisation de très mauvaise foi du […] dans la citation de la page de manuel

          Ok, c'était juste pour mettre l'accent sur la description initiale.

          On peut trouver au moins une douzaine de commandes de base qui créeront un fichier

          Sous quel encodage ? Là, touch fait un fichier vide. Il n'y a pas de BOM par exemple, rien, juste un fichier vide.

          C'est la philosophie UNIX qui sous-tend le principe. Une tâche, mais bien.

          Matricule 23415

          • [^] # Re: shell touch

            Posté par  . Évalué à 2.

            Zut, j'aurais dû prendre patience l'édition n'est plus possible.

            Un petit lmgtfy sur stackexchange.

            Mon point de vue est :
            touch
            - modifie la date de modification si le fichier existe, ou
            - crée le fichier s'il n'existe pas

            Et c'est tout.

            Et c'est super pratique de faire ça comme ça, car ça évite plein de problèmes (sensation de déjà vu).

            Matricule 23415

        • [^] # Re: shell touch

          Posté par  . Évalué à 10.

          Voici les outils de coreutils :

          [ base32 base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes

          Quel est la demi-douzaine qui permettent de créer un fichier vide là dedans ? Je vois dd if=/dev/zero of=file count=0, echo -n >> file et truncate -s +0 file. Les trois sont casse-gueule dans le sens où si tu te plantes dans les arguments (> au lieu de >>, oublier count=0, 0 au lieu de +0) et que le fichier existe déjà, ben paf le fichier.

        • [^] # Re: shell touch

          Posté par  (site web personnel) . Évalué à 6.

          Son comportement prévoit explicitement de créer un fichier s'il n'existe pas: C'est fait pour ça!

          On peut trouver au moins une douzaine de commandes de base qui créeront un fichier

          J'ai du mal à croire que vous trouverez six commandes qui ont ce comportement, la plupart vont écraser le contenu d'un fichier existant. Sur le nombre, combien seront portable?

          Pour créer un fichier vide, ou plutôt vider un fichier j'utilise aussi:¹

          cat /dev/null > ~/Mail

          Et encore, cat n'est pas fait pour ça si l'on suit votre raisonnement, pas plus que pour lister le contenu d'un fichier d'ailleurs; puisqu'il est fait pour concaténer deux fichiers selon son titre et son nom.

          ¹: pour les fichiers destinés à être très gros seulement, sinon j'utilise touch: Y a -t-il un psy dans la salle ?

          • [^] # Re: shell touch

            Posté par  . Évalué à 3.

            Pour créer un fichier vide, ou plutôt vider un fichier

            :>~/Mail fait économiser quelques frappes ;-)

            (: = true)

            • [^] # Re: shell touch

              Posté par  (site web personnel) . Évalué à 9.

              Tu n'as même pas besoin du : (deux points)

              > fichier

              ça suffit pour créer un fichier.

              « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

              • [^] # Re: shell touch

                Posté par  . Évalué à 0.

                +1 (j'économise mes touches ;-))

              • [^] # Re: shell touch

                Posté par  . Évalué à 5.

                Pas avec zsh, car > fichier redirige l'entrée standard vers fichier, et il est possible d'entrée des données (comme si l'on avait utilisé cat comme commande). En revanche, : > fichier redirige la commande :, qui n'écrit rien, et la redirection se termine quand : se termine.

                • [^] # Re: shell touch

                  Posté par  . Évalué à 7.

                  Maintenant reproduire l'équivalent de sudo touch /root/foo n'est pas aussi fun avec des redirections de la sortie standard.

                  Une autre commande qui crée des fichiers est tee. Tu peut faire un : | tee fichier.

                  Au final, touch est juste clairement le plus simple parce qu'il est très simple à comprendre et ne dépend pas d'un comportement du shell.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: shell touch

              Posté par  . Évalué à 2. Dernière modification le 20 février 2016 à 19:34.

              Le : n'est même pas nécessaire, un simple >fichier_vide aura pour effet de créer (ou vider) le fichier donné.

              Mais l'inconvénient par rapport à touch, c'est que justement cette forme videra un fichier existant sans avertissement, là ou touch se contentera de changer sa date de modification.

              Edit: oups, pas vu que ça avait déjà été répondu par d'autres…

              • [^] # Re: shell touch

                Posté par  (site web personnel) . Évalué à 4.

                Sinon, :>>fichier. mais comme dit précédemment, cela a l'inconvénient d'être une syntaxe du shell et pas une commande système. (ne fonctionne pas facilement avec sudo par exemple)

        • [^] # Re: shell touch

          Posté par  . Évalué à 4.

          Comme son nom l'indique, « touch » sert à « toucher au fichier ».

          Autrement dit, cela sert à obtenir le même comportement qu'en faisant un « open » dessus, à l'exclusion de toute autre opération associée. Donc, formellement, ça crée le fichier s'il n'existe pas et ça met à jour les timestamps dans tous les cas.

          Par défaut, la valeur des nouveaux timestamps correspondent à l'heure courant mais il est possible de passer une option pour antidater un fichier (ou le dater dans le futur), parce qu'il aurait été idiot de définir une autre commande rien que pour ce cas.

          Si tu utilises « > fichier » à la place, non seulement ça ne marchera pas en zsh mais en plus ça tronquera ton fichier s'il existe déjà (= le videra entièrement).

    • [^] # Re: shell touch

      Posté par  (site web personnel) . Évalué à 4.

      d'où vient cette idée d'utiliser touch pour créer des fichiers ?

      A mon avis, cela viens des Makefile. Cela permet de poser une date via un fichier temporaire donc de séquencer des opérations complexes…

      Ceci dis, c'est très utile pour créer un fichier vide. Je n'ai pas personnellement trouvé plus simple.

      • [^] # Re: shell touch

        Posté par  . Évalué à 2. Dernière modification le 20 février 2016 à 11:21.

        plus simple :

        # > fichier

        On économise 4 caractères :)

        Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr

        • [^] # Re: shell touch

          Posté par  (site web personnel) . Évalué à 3.

          Dans zsh, > fichier est bloquant puisqu'il attend des choses sur stdin.

          Du coup, il faut faire > fichier suivi de Ctrl-D. C'est carrément moins pratique que touch fichier.

        • [^] # Re: shell touch

          Posté par  (site web personnel) . Évalué à 4.

          C'est pas du tout beau et en plus, tu crée toujours un nouveau fichier alors que touch ne crée un nouveau fichier QUE si celui-ci n'existe pas. En plus, cela semble vachement sh dépendant (cf zsh ci dessus). Du coup, j'ai partiellement regardé le man de bash

          "
          If the redirection operator is >, and the noclobber option to the set builtin has been enabled, the redirection will fail if the file whose name results from the expansion of word exists and is a regular file. If the redirection operator is >|, or the redirection operator is > and the noclobber option to the set builtin command is not enabled, the redirection is attempted even if the file named by word exists.
          "

          Bon, je vais rester avec mes "touch" ;-)

          • [^] # Re: shell touch

            Posté par  . Évalué à 0.

            on peut utiliser
            : > titi

            • [^] # Re: shell touch

              Posté par  (site web personnel) . Évalué à 2.

              Denis disait qu'il y avait des dizaines de manière de faire, on peut s'amuser à les regrouper ici. J'ai testé tes deux commandes, elle garde bien le même inode de fichier si celui-ci existe déjà. Je me suis amusé à les lancer sous dash et non bash, cela marche aussi. La version courte '> titi' ne fonctionne pas sous 'csh', mais la longue est OK.

              A noter que 'touch', à des avantages ou inconvénients. C'est une commande indépendante du shell dans lequel il est lancé (donc un sous processus est lancé).

              • [^] # Re: shell touch

                Posté par  (site web personnel) . Évalué à 8. Dernière modification le 20 février 2016 à 17:37.

                Denis disait qu'il y avait des dizaines de manière de faire.

                Attention, il faut que ces manières de faire soient «faites pour ça».

                Parce que si ce n'est pas le cas de touch, il faut être sacrément chargé en mauvaise foi pour accepter la redirection >, surtout avec un : ésotérique devant…

                • [^] # Re: shell touch

                  Posté par  (site web personnel) . Évalué à 1.

                  Surtout que les deux-points "c'est pas fait pour ça" mais pour une énumération par exemple :)

                • [^] # Re: shell touch

                  Posté par  . Évalué à 0.

                  surtout avec un : ésotérique devant…

                  Ésotérique ? : est dans le standard POSIX.

                  • [^] # Re: shell touch

                    Posté par  . Évalué à 1.

                    Ça correspond magnifiquement à la définition d'ésotérique, justement:

                    Se dit d'un mode d'expression, d'une œuvre qui n'est compréhensible que des initiés ; hermétique, abstrus, abscons : Langage ésotérique.

                    En gros, ça veut dire que ce qui n'est pas compréhensible des initiés est ésotérique. Techniquement parlant, touch l'es aussi, mais il y a quand même un plus grand pourcentage de gens connaissant cette technique que les trucs à base de redirection, donc, même si touch reste ésotérique, ça l'est moins que les-dites bidouilles de redirection.

                    • [^] # Re: shell touch

                      Posté par  . Évalué à 3.

                      C'est standard donc c'est ésotérique ? Je crois qu'on marche sur la tête là…

                      • [^] # Re: shell touch

                        Posté par  . Évalué à 0.

                        Rien à voir.

                        C'est juste que ceux qui connaissent le standard sur le bout des doigts sont, au minimum, des initiés, et que certains constructions standards sont absolument illisibles, non-intuitives, ou incompréhensibles, l'un de ces termes n'excluant pas nécessairement les autres.

                        Tu as besoin d'une preuve?
                        En voici une:

                        #define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
        _-_-_-_-_-_-_-_
            _-_-_-_
}

                        Que fait ce code source?
                        Ma foi, c'est standard, donc c'est pas ésotérique, donc tu devrais connaître un dev C capable de te dire en moins de 5 minutes (et je suis large, y'a meme pas 100 lignes bon dieu) ce que ça fait.

                        • [^] # Re: shell touch

                          Posté par  . Évalué à 3.

                          Vous êtes d'une mauvaise foi abyssale, ce code source est volontairement compliqué pour dérouter et j'ajouterai qu'il contient aussi plus de 150 opérations, à comparer avec : > toto, qui contient au maximum 3 opérations.

                          • [^] # Re: shell touch

                            Posté par  . Évalué à 2.

                            Par curiosité, continuons :

                            % cpp < fichier | indent
#1 "<stdin>"
#1 "<built-in>"
#1 "<command-line>"
#1 "/usr/include/stdc-predef.h" 1 3 4
#1 "<command-line>" 2
#1 "<stdin>"

int F = 00, OO = 00;
main ()
{
  F_OO ();
  printf ("%1.3f\n", 4. * -F / OO / OO);
} F_OO ()
{
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
  - -F < 00 || --F - OO--;
}

                            Les types et les déclarations manquent, mais passons.

                            Dans le premier -F < 00 || --F - OO--;, F vaut 0, donc la condition est fausse et la seconde partie s’exécute, donnant F == -1 et OO == -1.
                            Dans les - -F < 00 || --F - OO--; suivants, le premier test est vrai, donc aucune opération n'est faite.
                            -F < 00 || --F - OO--; revient, la condition est encore fausse, donc F == -2 et OO == -2 aussi.
                            Tout le reste est répété 16 fois, donnant F == -16 et OO == -16.
                            La fonction main poursuit donc, 4. * -F / OO / OO ce qui donne 4*--16/-16/-16, ce qui donne 0.25.

                          • [^] # Re: shell touch

                            Posté par  . Évalué à 2.

                            Je réponds juste au "le standard ne peut être ésotérique". Oui, j'ai pris un exemple de code obfusqué, mais ce code est-il standard, ou non?
                            J'ai vu des scripts shell très difficiles a lire, tout comme de l'asm lisible, pourtant l'asm n'est pas un langage standardisé, contrairement au shell.
                            Si on doit parler de langage informatique ésotérique, je trouve que le shell se pose bien, même si la doc abonde (encore faut-il trouver, parce que les moteurs de recherches tendent à me corriger quand je tape sh, et si je tape bash j'ai pas de preuve que l'on ne parle pas de bashisme, justement…). Et certaines instructions du shell, telles que ": > toto" sont justement tout sauf lisible.
                            Si je demande à ma mère… oh, allez, à mon père, il a fait un peu d'asm motorola au lycées… de me dire ce que fait cette ligne, ou ce que fait une ligne de C équivalent qui ne montrerait pas ma mauvaise foi, je parie qu'il galérera moins à lire la ligne de C. Pourtant, c'est le shell qui est censé manipuler le mieux le système de fichiers (le C est conçu pour être bas niveau, d'ailleurs les outils C pour manipuler le système de fichier ne sont pas dans le standard iso me semble). À côté, en shell, on peut utiliser touch toto. Bon, toujours pas parlant, mais au moins, c'est lisible, et il y a même un man.
                            Donc, oui, : > toto est ésotérique, malgré que ce soit standard.

      • [^] # Re: shell touch

        Posté par  (site web personnel) . Évalué à 3.

        A mon avis, cela viens des Makefile.

        On y trouves aussi un bon usage de install (qui permet en plus de spécifier le propriétaire et les droits).

        install -o user -g group -m 600 /dev/null fichier

  • # Désactivé dans Debian unstable Sid

    Posté par  (site web personnel) . Évalué à 9.

    Vient d'être désactivée par défaut dans Debian Sid (d'ailleurs j'ai mis à jour entre mon commentaire plus haut et celui-là, et j'ai dû cherché la cause du changement de comportement) :

    coreutils (8.25-2) unstable; urgency=medium

  * Disable default ls quoting for now to get the rest of 8.25 into testing.
    (Closes: #813164)

 -- Michael Stone <mstone@debian.org>  Tue, 16 Feb 2016 09:02:12 -0500

    • [^] # Re: Désactivé dans Debian unstable Sid

      Posté par  . Évalué à -3.

      C'est pour les scripts utilisants la sotie de ls que ça va être drôle…
      Debian a bien réagit je pense

      • [^] # Re: Désactivé dans Debian unstable Sid

        Posté par  (site web personnel) . Évalué à 4.

        La sortie via un pipe n'avait pas été modifié.

        On aurait aussi pu imaginer ne pas modifier la sortie en cas de LANG=C or tout script qui se veut un peu robuste le place au début ou jsute devant certaines commandes…

      • [^] # Re: Désactivé dans Debian unstable Sid

        Posté par  . Évalué à 3.

        C'est pour les scripts utilisants la sotie de ls que ça va être drôle…

        Une petite lecture s'impose : https://linuxfr.org/news/revue-des-techniques-de-programmation-en-shell

        0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0

      • [^] # Re: Désactivé dans Debian unstable Sid

        Posté par  . Évalué à 4.

        C'est pour les scripts utilisants la sotie de ls que ça va être drôle…

        En même temps, utiliser la sortie de ls dans un script, c'est casse-gueule.
        Il me semble, justement, que la sortie de ls n'est définie par aucun standard (ce qui fait que le nouveau comportement ne pose en théorie pas de problème) et dès qu'il y à des espaces dans le nom de fichier, c'est juste plus possible d'utiliser des trucs comme cut. Je ne parle pas du cas des colonnes alignées par des suites d'espaces plutôt que par des tabulations. D'ailleurs, une fin de ligne dans ls, c'est représenté par '\0' ou '\n'?

        Je ne dirais pas que ça ne m'arrive pas de parser la sortie de ls, mais c'est quand j'ai la flemme ou en dernier recours. Et le nom de fichier que je récupère est destiné à un humain avec un minimum de neurones, pas à une machine, parce que je sais qu'il à de grandes chances de ne pas être exact.

        • [^] # Re: Désactivé dans Debian unstable Sid

          Posté par  (site web personnel) . Évalué à 3.

          Tu peux utiliser la sortie de "ls" mais avec juste l'option -1, c'est déjà bien plus robuste.

          • [^] # Re: Désactivé dans Debian unstable Sid

            Posté par  . Évalué à 2.

            Si c'est juste pour afficher des noms de fichiers, je n'utilise pas ls, find est bien intéressant (si j'ai besoin de filtrer) ou simplement *.
            La seule chose qui fait qu'il m'arrive d'utiliser ls pour des scripts, c'est qu'en une commande de 5 caractères, on peut avoir la taille des fichiers et le nom. Accessoirement, on se retrouve avec d'autres infos plus ou moins utiles selon le contexte.
            Avec find, il faut jouer de l'-exec pour avoir ces infos la.

            Ou alors j'ai raté un épisode (ça ne serait pas la première fois).

        • [^] # FTP?

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          Il me semble que FTP ne spécifie pas vraiment de format pour la liste des fichiers que le serveur doit envoyer, et qu'en général ça ressemble franchement à un ls -l. Alors, est-ce qu'il y a des clients/serveurs FTP qui vont avoir des problèmes avec ces quotes inattendues?

          • [^] # Re: FTP?

            Posté par  . Évalué à 2.

            Alors, est-ce qu'il y a des clients/serveurs FTP qui vont avoir des problèmes avec ces quotes inattendues?

            Tout ceux qui se basent sur des fonctions non standard ne peuvent que révéler leurs bugs.

      • [^] # Re: Désactivé dans Debian unstable Sid

        Posté par  (site web personnel) . Évalué à 5.

        C'est pour les scripts utilisants la sotie de ls que ça va être drôle…

        Analyser la sortie de la commande ls c'est le mal absolu: il faut utiliser la commande find ou les globbing patterns du shell, mais la commande ls est à réserver à l'usage interactif. (Et pour ls -l il faut utiliser stat ou bien une combinaison de find et stat.)

        • [^] # Re: Désactivé dans Debian unstable Sid

          Posté par  . Évalué à 5.

          Juste parce que j'aime pas les discours absolutistes. La commande stat n'a rien d'amusant à parser. Pour l'exercice, tu peux t'amuser à réécrire un script shell qui fait l'équivalent du ls -l du dossier courant. Avec bash, je ne sais pas mais avec zsh tu as un builtin zstat qui te renvoie directement un tableau ou un dictionnaire avec tout ce qui va bien. Ce qui permet d'écrire ça :

          zmodload -F zsh/stat b:zstat

for entry in * ; do
    zstat -sH dataStat "${entry}"
    print -- "${dataStat[mode]} ${dataStat[uid]} ${dataStat[gid]} ${dataStat[ctime]} ${entry}"
done

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Désactivé dans Debian unstable Sid

            Posté par  (site web personnel) . Évalué à 5.

            Juste parce que j'aime pas les discours absolutistes.

            Et tu as bien raison. Seulement la différence entre toi et les débutants, c'est que tu sais très bien programmer le shell, mais c'est souvent utile aux débutants d'avoir des panneaux d'avertissement “si tu mets le doigt là-dedans, ça risque de faire mal. :)” Du coup souvent je force le trait.

            Pour la commande stat le seul truc casse-pied c'est le format des dates. Je travaille le plus possible avec ISO8601 (genre 2016-02-23T02:23:09Z) qui a deux avantages: pas d'espaces et l'ordre lexicographique coïncide avec l'ordre du temps.

Suivre le flux des commentaires

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