LibreSSL 2.3.3

Posté par (page perso) . Édité par Davy Defaud et Benoît Sibaud. Modéré par patrick_g. Licence CC by-sa
60
11
avr.
2016
OpenBSD

LibreSSL 2.3.3 est disponible depuis le 22 mars 2016. Ce projet, démarré par des développeurs d’OpenBSD, vise à proposer une alternative sécurisée et moderne à OpenSSL, suite notamment aux failles Heartbleed et Poodle.

Logo LibreSSL

À propos

LibreSSL consiste en quatre parties :

  • l’outil en ligne de commande openssl(1), qui permet de gérer entre autres, clés et certificats ;
  • libcrypto, une bibliothèque cryptographique ;
  • libssl, une bibliothèque TLS rétrocompatible avec OpenSSL ;
  • et enfin, libtls, une bibliothèque plus récente, pensée pour faciliter l’écriture d’applications « foolproof ».

Comme beaucoup d’autres projets de la fondation OpenBSD, LibreSSL est développé d’abord pour ce système. Une version dite « portable » est ensuite créée, via un ensemble de correctifs, pour fonctionner sur plus de systèmes d’exploitation. Actuellement, LibreSSL fonctionne sur les plates‐formes suivantes :

  • GNU/Linux (Linux 3.17 et suivants préférés) ;
  • FreeBSD (testé sur 9.2 et après) ;
  • NetBSD (7.0 et suivants préférés) ;
  • HP-UX (11i) ;
  • Solaris (11 et suivants préférés) ;
  • OS X (testé sur 10.8 et suivants) ;
  • AIX (5.3 et suivants) ;
  • Windows (XP et suivants, x86 et x64) ;
  • Wine (32 bits et 64 bits).

Sur le plan technique

Cette version de LibreSSL apporte les changements suivants :

  • les scripts de compilations ont été retravaillés afin de mieux se synchroniser avec OpenNTPD-portable ;
  • correction de liens cassés dans la page de manuel ;
  • correction d’un problème de compatibilité avec le serveur Web Nginx, en ajoutant un alias make nommé install_sw ;
  • des corrections de compilation pour HP-UX ;
  • pour la version Windows, le répertoire de configuration par défaut est maintenant C:\LibreSSL\ssl ;
  • cert.pem a été réorganisé et synchronisé avec le magasin de certificats de Mozilla.

Sur le plan organisationnel

À partir de cette version, les développeurs de LibreSSL considèrent maintenant la branche 2.3 comme stable, et annoncent d’ailleurs que la branche 2.1 ne sera plus maintenue lors de la sortie d’OpenBSD 5.9 (initialement prévue pour mai 2016, sorti finalement le 29 mars 2016).

Avec la sortie avancée d’OpenBSD 5.9, rien ne dit pour le moment si cette branche 2.1 restera maintenue jusqu’à mai ou si elle est déjà en fin de vie. Les notes de version mentionnent par ailleurs que LibreSSL 2.3.3 est identique à la version livrée dans OpenBSD 5.9, alors que ce dernier annonce LibreSSL 2.3.2.

Côté calendrier, la page listant les versions publiées annonce une transition vers la publication d’une version stable tous les six mois, en coordination avec le calendrier de développement d’OpenBSD. Les branches stables de LibreSSL sont maintenues pendant un an après que leur version correspondante dans OpenBSD a été étiquetée pour livraison.

  • # Wine ?

    Posté par . Évalué à 6.

    Je suis surpris de voir Wine en temps que plateforme/OS. Même se ce n’est pas un émulateur, c’est un wrapper d’appel système Windows pour Unix.

    • [^] # Re: Wine ?

      Posté par (page perso) . Évalué à 2.

      Il existe tout de même https://wiki.winehq.org/Winelib

    • [^] # Re: Wine ?

      Posté par (page perso) . Évalué à 10.

      J'ai été aussi surpris que toi en écrivant l'article. Mon hypothèse est que certains développeurs ou contributeurs utilisent Wine pour compiler/tester les binaires Windows. Je ne serais pas surpris que cela se fasse aussi par manque de licence Windows (volontaire ou non).

    • [^] # Re: Wine ?

      Posté par . Évalué à 4.

      Personnellement ça ne m'a pas surpris car Wine est bien une plateforme mais pas un OS, tout comme le support JAVA est également considéré comme une plateforme.

  • # A tester

    Posté par . Évalué à 4.

    On attend ça avec impatience malheureusement ça ne semble pas encore disponible pour Linux (dans le sens où c'est pas packagé). Par contre c'est installable assez facilement pour les ports FreeBSD.

    • [^] # Re: A tester

      Posté par . Évalué à 6. Dernière modification le 12/04/16 à 00:51.

      J'avais installé une Gentoo avec LibreSSL pleinement fonctionnelle avec les dépôts officiels instables, en septembre dernier. Ça fait au moins une distribution où c'est « packagé ».

    • [^] # C’est une question de distribution

      Posté par . Évalué à 6.

      On attend ça avec impatience malheureusement ça ne semble pas encore disponible pour Linux (dans le sens où c'est pas packagé).

      Void est passé à LibreSSL par défaut.
      Après, c’est un choix de chaque distribution de rester avec OpenSSL ou de passer à LibreSSL (et quand)…

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

  • # sécurisée et moderne

    Posté par (page perso) . Évalué à -10.

    Je ne sais pas trop pourquoi, mais je n'ai pas trop aimé la vitesse où les gens ont rejeté openSSL , et la création de cette alternative ne m'a pas plût …
    Pour moi, "une alternative sécurisée et moderne à OpenSSL" sonnerait mieux avec Rust :P , dans ce cas là je testerai ( ça sera peut-être aussi l'occasion de contribuer ^ ) et ça aurai à ma vue plus de sens.

    Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote

    • [^] # Re: sécurisée et moderne

      Posté par . Évalué à 10.

      Moi aussi je trouve ça nul, ils auraient dû le faire en OCaml. Là j'aurais contribué !

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

      • [^] # Re: sécurisée et moderne

        Posté par . Évalué à 4. Dernière modification le 12/04/16 à 21:50.

        Ça existe déjà, et c'est prouvé en plus : mitls.org

        Par contre il faut accepter d'écrire trois fois plus d'annotations que de code.

      • [^] # Re: sécurisée et moderne

        Posté par . Évalué à 5. Dernière modification le 13/04/16 à 14:12.

        ça existe, et ça s'appelle ocaml-tls

      • [^] # Re: sécurisée et moderne

        Posté par (page perso) . Évalué à 2.

        On code dans les langages qu'on connait, pour ma part, j'essaie d'apprendre les Rust (je dis j'essaie, car je n'ai pas trop de temps) . Et c'était une boutade par rapport au fait que "moderne et sécurisé" sont un peu l'étiquette que se veut Rust.
        Mon commentaire était surtout sur le fait de lyncher une équipe qui distribue du code librement depuis plus de 15ans au moindre faux pas … Plutôt leur filer un coup de main et refondre le code ensemble (ok, vive les bisounours) que de forker directement ou mettre en place des alternatives … (disons que la vague de rejet qu'il y a eu envers eux qui distribuent du code depuis longue date ne me paraissait pas respectueuse …)

        Essaie pour vivre sans brider les utilisateurs https://www.indiegogo.com/projects/iwinote

    • [^] # Re: sécurisée et moderne

      Posté par . Évalué à 10.

      je n'ai pas trop aimé la vitesse où les gens ont rejeté openSSL

      Ah, c'est sûr que rejeter une tonne de code spaghetti merdique, obsolète, peu maintenu, et bourré de failles, c'est rageant…

      Ou pas…

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: sécurisée et moderne

      Posté par . Évalué à 7.

      On a bien fait la même chose avec LibreOffice et quand on voit ce que ça donne perso je trouve pas gênant d'abandonner des projets mort et les forker si ça devient vitale.

      • [^] # Re: sécurisée et moderne

        Posté par (page perso) . Évalué à 2.

        Oui enfin, on peut aussi dire le contraire avec mate, ou le fork de gnome à l'époque de gnome 2, ou trinity, qui sont globalement comme apache openoffice, pas mort mais avec un niveau d'activité pas non plus énorme.

        • [^] # Re: sécurisée et moderne

          Posté par . Évalué à 2.

          C'est des projets zombie ?

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: sécurisée et moderne

          Posté par . Évalué à 7. Dernière modification le 12/04/16 à 13:18.

          Je suis d'accord par contre malheureusement tous ne partage pas notre avis et continue leurs supports. Quand on voit le nombre de distributions qui utilise Mate, on voit que certains on l'air de l’apprécier. Moi personnellement j'utilise Xfce (qui a été créé bien avant gnome 3) et le projet avance doucement mais est très stable.

        • [^] # Re: sécurisée et moderne

          Posté par . Évalué à 10.

          C'est très positif ! Quand on découvre qu'un projet important de l'écosystème a un problème chercher à résoudre ce problème ne me paraît pas choquant. La linux fondation a mandaté des audits du code, OpenBSD se lance dans une alternative,… Lancer plusieurs solutions et voir la quelle va émerger n'est pas délirant. D'autant plus que ce sont des gens qui n'auraient probablement pas réussi à collaborer pour choisir une solution et travailler de concert donc ça n'éparpille pas une force de travail.

          Quand un projet fais un choix critique, le fait d'avoir des alternatives qui se créent n'est pas un problème à mon humble avis.

          Ça me fait penser que Devuan a l'air très très calme (je peux me tromper).

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

          • [^] # Re: sécurisée et moderne

            Posté par (page perso) . Évalué à 3.

            Le souci n'est pas de forker, mais de croire que parce qu'un truc est un fork, alors c'est meilleur, et de croire que tout les forks vont faire mieux que l'original.

            Il y a tout un tas de facteurs à prendre en compte pour voir si c'est opportun ou pas, et si j'osais faire un début d’hypothèse, le facteur le plus important, c'est de voir ou les développeurs de longue date du projet vont. Dans le cas d'Openoffice et de Mandrake, les forks sont ceux qui ont globalement survécus. Dans le cadre de certains forks de gnome, kde ou debian, c'est globalement pas le cas (Ubuntu étant une des exceptions à mon hypothèse, tout comme Libressl).

            • [^] # Re: sécurisée et moderne

              Posté par . Évalué à 4.

              Ubuntu étant une des exceptions à mon hypothèse, tout comme Libressl

              Ubuntu n'est pas un fork mais une dérivée. Ubuntu a besoin de Debain pour exister.
              Le fork d'OS qui correspond à ce que tu dis serait plutôt DragonflyBSD.

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

    • [^] # Re: sécurisée et moderne

      Posté par . Évalué à 5.

      Rust n'est pas aussi portable que le C (pour l'instant) et si on veut quelque chose d'utilisable (compilable à peu prés partout x86/POWER/SPARC/ARM/MIPS/AVR/…) le C est encore pour longtemps un (le seul?) choix pragmatique.

      Ce que je ne comprend pas, c'est pourquoi il n'y a pas eu plus de fuite vers PolarSSL, comme Hiwatha web server avait eu la bonne idée de le faire avant l'apparition des problèmes de sécurité d'OpenSSL.

      • [^] # Re: sécurisée et moderne

        Posté par . Évalué à 3.

        Ou comme l'on fait les gens de Belldonne Communication pour leur soft SIP ? ;)

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

      • [^] # Re: sécurisée et moderne

        Posté par . Évalué à 6.

        On connaît l'état du code OpenSSL qui a été très audité, mais la robustesse de concurrents tels que PolarSSL n'est pas forcément établie.

        Par ailleurs, si PolarSSL ne propose pas une API similaire à celle d'OpenSSL, il y a un coût de migration important.

        • [^] # Re: sécurisée et moderne

          Posté par . Évalué à 1.

          Par ailleurs, si PolarSSL ne propose pas une API similaire à celle d'OpenSSL, il y a un coût de migration important.

          https://github.com/cesanta/polar ?

          • [^] # Re: sécurisée et moderne

            Posté par . Évalué à 5.

            Si j'en crois le README, c'est un jeu de fonctions très réduit qui ne permet que des cas d'usage triviaux. Par exemple, aucun moyen d'activer ou désactiver certaines versions de TLS, de choisir les algorithmes de chiffrement autorisés, de prendre en charge le SNI, et tant d'autres besoins assez courants.

            (je passe sur le fait que cette bibliothèque est sous licence GPL…)

        • [^] # Re: sécurisée et moderne

          Posté par . Évalué à 7.

          Moi je suis surpris que gnutls n'ai pas sorti son épingle du jeu

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

          • [^] # Re: sécurisée et moderne

            Posté par . Évalué à 3.

            J'ai volontairement cité PolarSSL et pas GnuTLS qui n'avait (selon certain ouï-dire) pas bonne réputation niveau sécurité/audit.

            Pour l'API incompatible, j'entends bien par "fuite vers PolarSSL" fuir le code et également l'API de OpenSSL, qui n'a pas bonne réputation et apparemment la doc c'est pire (le mainteneur d'hiwatha justifiait la migration à cause de la documentation d'OpenSSL). Donc oui, ça a un coût, mais justement je suis étonné que si peu de personne aient trouvé que ce coût en vaille la peine.

            Surtout que depuis que ARM a repris PolarSSL pour en faire mbedTLS, ils y ont ajouté la licence Apache qui, à mon sens, rend possible l'utilisation partout où OpenSSL est utilisé (ils sont d’ailleurs pas tendre avec OpenSSL).

            [mes 2cts d'expérience]
            Lorsqu'une bibliothèque logiciel employable pour l'embarqué entre en concurrence avec une autre inutilisable pour l’embarqué, c'est très souvent celle pour l'embarqué qui devient la solution technique supérieur; bien que son développement soit plus lent au début.
            [/mes 2cts d'expérience]

        • [^] # Re: sécurisée et moderne

          Posté par (page perso) . Évalué à 5.

          Une partie de PolarSSL a été formellement prouvé par les ptits gars de chez TrustInSoft (un outil qui se base sur l'excellent outil Frama-C), avec en prime un kit de vérification :

          http://trust-in-soft.com/polarssl-verification-kit/

          C'est déjà bien plus qu'OpenSSL, en un sens :)

          Mes messages engagent qui je veux.

      • [^] # Re: sécurisée et moderne

        Posté par (page perso) . Évalué à 5.

        Ce que je ne comprend pas, c'est pourquoi il n'y a pas eu plus de fuite vers PolarSSL

        L'avantage de LibreSSL, c'est que c'est globalement compatible avec l'existant. De plus, il y a la critique facile contre OpenSSL mais tout le monde l'utilisait avant, cela montre bien qu'il est relativement developper friendly.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: sécurisée et moderne

          Posté par . Évalué à 10.

          L'API d'OpenSSL est une merde très loin d'être developer friendly. Et ne parlons de la doc longtemps rachitique…

          • [^] # Re: sécurisée et moderne

            Posté par (page perso) . Évalué à 3.

            Sans parler des API bas niveau de libcrypto. Je me suis souvent retrouver à fouiller le code source pour comprendre comment utiliser correctement l'API. Certaines sections ont 0 docs, le code source est pourris et remplis de #ifdef (donc le code du très important mt_rand()).

  • # choix de dossier

    Posté par . Évalué à 10.

    pour la version Windows, le répertoire de configuration par défaut est maintenant c:\LibreSSL\ssl ;

    Je sais bien que Windows est pas le coeur de cible, mais c'est quand même curieux ce choix de dossier. C'est un peu comme si sous linux la conf par défaut était dans /LibreSSL/ssl.

    • [^] # Re: choix de dossier

      Posté par . Évalué à -7.

      Et tu proposes quoi ?
      Entre les noms de répertoires avec des espaces qui font tout péter à tel point qu'ils portent deux noms ou plus et le répertoire système qu'il n'est pas recommander de polluer (le système s'en charge lui même), tu n'as pas vraiment de choix.
      Est ce que MS produit un guide line pour bien choisir ce dossier ?

      • [^] # Re: choix de dossier

        Posté par . Évalué à 10. Dernière modification le 12/04/16 à 11:27.

        oui

        Et le dossier ProgramData est tout indiqué (il existe depuis Vista)

        %SYSTEMDRIVE%\ProgramData\LibreSSL aurait suffit.

        Sous XP, ça aurait été %SYSTEMDRIVE%\Documents and Settings\All Users\Application Data\LibreSSL

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: choix de dossier

          Posté par . Évalué à 6.

          %SYSTEMDRIVE%\ProgramData\LibreSSL aurait suffit.

          Même %PROGRAMDATA%\LibreSSL.

      • [^] # Re: choix de dossier

        Posté par (page perso) . Évalué à 6.

        Entre les noms de répertoires avec des espaces qui font tout péter

        Mauvais code, changer code.
        Sérieux si en 2016 tu n'es pas capable de gérer un nom de fichier avec un espace, c'est grave.

        Non, ici c'est juste considérer les Windowsiens comme de la merde (car ils ne font pas la même chose chez eux à coup de /LibreSSL/ssl, ils font attention à respecter les us et coutumes sur ce qui leur plait).

        Note : bon, c'est le même respect pour d'autres style Python, Ruby… Pour citer les derniers que j'ai installé. Même Oracle est plus correct avec Java bien placé, c'est dire le niveau de respect des autres.

        Est ce que MS produit un guide line pour bien choisir ce dossier ?

        Et même une API!

        SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, 0, szPath)
        pour une config par appli (globale à la machine)

        SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szPath)
        pour une config par user (et qui se balade, indépendant de la machine,

        En fait, ça dépend de ce que tu veux faire (machine locale uniquement, par user et local, par user en roaming…), le problème est peut-être que Microsoft offre trop de choix? Moi qui croyais que le proprio était horrible car trop limité…

        https://msdn.microsoft.com/en-us/library/windows/desktop/bb776911%28v=vs.85%29.aspx
        https://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx


        bref, rien de compliqué pour qui souhaite le faire. Excuser est juste "protéger" la flemmardise.

        à tel point qu'ils portent deux noms

        Salaud de gens qui fournissent de la compatibilité. Note : si tu programmes en 2016, tu n'as rien à faire du deuxième nom.

        Bref, en fait tu ne connais pas mais critique (faussement du coup), ça vais vachement sérieux… Parce que bon, perso j'en conclue que quand on a besoin de critiquer faussement, c'est qu'on ne crois pas en ce qu'on aime (pas besoin de tromper les gens sur le concurrent si on y croit dans ses choix).

        • [^] # Re: choix de dossier

          Posté par . Évalué à 5.

          Sérieux si en 2016 tu n'es pas capable de gérer un nom de fichier avec un espace, c'est grave.

          Avec un système datant de 2011 (Seven SP1), j'essaie:

          C:\> cd My Program Files
          C:\My Program Files>
          

          ça fonctionne, et je dois avouer que j'ai été surpris, je ne m'y attendais pas.
          Essayons autre chose:

          C:\> dir  My Program Files
           Le volume dans le lecteur C s'appelle System
           Le numéro de série du volume est 2B78-CB34
           Répertoire de C:\
           Répertoire de C:\
           Répertoire de C:\
          Fichier introuvable
          

          et ce n'est pas la bonne réponse. Recommençons avec des guillemets:

          C:\> dir  "My Program Files"
           Le volume dans le lecteur C s'appelle System
           Le numéro de série du volume est 2B78-CB34
          
           Répertoire de C:\My Program Files
          
          12/04/2016  09:08    <REP>          .
          12/04/2016  09:08    <REP>          ..
          03/12/2015  10:09    <REP>          PortableWindirstat
          03/12/2015  10:09    <REP>          PuTTY
          [...]
                         0 fichier(s)                0 octets
                        17 Rép(s)   5 248 425 984 octets libres
          

          Et voila la réponse attendue.

          J'ai hâte d'avoir sous la main un système de 2016, histoire de voir si la gestion des nom de fichiers avec espace est devenue cohérente.

          • [^] # Re: choix de dossier

            Posté par . Évalué à 8.

            Euh, tu mets des guillemets dès qu'il a des espaces. C'est comme ça depuis Windows 95 OSR 2 (sortie en Août 1996).

            C'est pourtant pas compliqué…

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: choix de dossier

            Posté par (page perso) . Évalué à 7.

            tu vois en négatif quelque chose de positif.

            Si tu es curieux :
            "cd" n'accepte qu'un champs, si il y en a plusieurs ça veut dire que les guillemets ont été oubliés et l'OS "corrige" ton erreur. Il est sympa l'OS, il corrige tes bêtises, toi tu l'insultes.
            "dir" accepte plusieurs champs, si il y en a plusieurs l'OS ne peut pas (ou moins facilement) savoir si tu as fait une erreur ou si c'est la commande que tu voulais, donc il ne corrige pas et préfère te laisser gérer l'erreur.

            Tu fais une erreur, l'OS corrige quand il peut, et tu fais d'une fonctionnalité un défaut juste pour pouvoir cracher sur l'OS. C'est d'une objectivité…

            A la base, tu es juste mauvais, et tu dois mettre des guillemets quand il y a des espaces (comme… Sous Linux). J'appelle ça de la mauvaise foi ;-).

            (tu veux qu'on parle de la logique globale des commandes Linux, vraiment?)

            • [^] # Re: choix de dossier

              Posté par . Évalué à 4.

              l'OS "corrige" ton erreur. Il est sympa l'OS

              Je pense plutôt que c'est le programme qui corrige.

              • [^] # Re: choix de dossier

                Posté par . Évalué à 7.

                C'est plus précis, mais inclure le shell et ces éventuels programmes associés dans ce que l'on appel OS ça n'a rien de choquant.

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

              • [^] # Re: choix de dossier

                Posté par . Évalué à 3.

                Je ne voudrais pas reprendre les trolls Linux contre GNU/Linux, mais quand même, penser que le shell de base (cmd.exe) ou les commandes bas niveau (cd) ne font pas partie de l'OS parce que ce n'est pas dans le noyau, c'est soit de la mauvaise foi, soit un truc de gros noob.

                • [^] # Re: choix de dossier

                  Posté par . Évalué à 3.

                  Ce que je souligne, c'est que deux programmes d'une même suite de logiciel peuvent avoir les mêmes comportements. Ce comportement ne dépends pas de son origine. Et que ce comportement dépend bien du programme, qu'il fasse partie d'une suite, d'un OS, d'un dépot github abandonné ou vu dans une série americaine.

            • [^] # Re: choix de dossier

              Posté par . Évalué à 4.

              J'assume la mauvaise foi, et je préfère effectivement un système cohérent avec des guillemets partout. Ca te pose un problème ?

              Intéressant le choix de ton vocabulaire : "insulter", "cracher sur", "tu est mauvais" … tu t'ennuies ?

              • [^] # Re: choix de dossier

                Posté par . Évalué à 10.

                Intéressant le choix de ton vocabulaire : "insulter", "cracher sur", "tu est mauvais" … tu t'ennuies ?

                Tu es nouveau ici ?

        • [^] # Re: choix de dossier

          Posté par . Évalué à 1.

          cd C:\program files
          

          fonctionne

          dir C:\program files

          plante.

          Deux commandes systèmes, deux comportements.

          • [^] # Re: choix de dossier

            Posté par . Évalué à 5.

            cmd.exe est le pire shell de la création, c'est un fait, mais c'est la ligne de commande Windows qui est incohérente, quand t'attaques programmatiquement (par API) les noms de fichiers avec espaces ça marche nickel de façon cohérente depuis Windows 95

            soit depuis 20 ans

            donc t'es au même niveau de mauvaise foi que les gens qui reprochent à Linux en 2016 les défauts qu'il avait en 1995, genre la gestion des threads lamentable, le support matériel de niche, l'interface graphique des années 70, la nécessité de recompiler le noyau pour ajouter un driver ou changer un paramètre, etc.

        • [^] # Re: choix de dossier

          Posté par . Évalué à 6.

          MS a parfois du mal avec lui même ;)
          Renommer des répertoires pour faire fonctionner des compilations, c'est pas top en 2016.
          cf. https://github.com/Microsoft/msbuild/issues/53

          • [^] # Re: choix de dossier

            Posté par (page perso) . Évalué à -2. Dernière modification le 12/04/16 à 22:42.

            Encore un procès d'intention un peu facile ;-).
            - Pour les "fous" aimant les répertoires de plus de 260 caractères (noter le mot, ce n'est pas octets), certains outils ont du mal sous Windows, pas d'autres (ça dépend de savoir si ils utilisent l'API étendue ou pas). Donc avec Windows, tu peux si tu codes pour. Visual Studio n'est pas prévu, mais tu peux faire ton logiciel compatible si tu veux.
            - Pour les utilisateurs Linux… Ben ce n'est jamais possible! Ext4, Btrfs, ZFS… sont tous limités à 255 octets (noter le mot, ça veut dire qu'on peut tomber à une limite de 63 caractères si ont s'amuse avec des caractères dans la plage très étendue Unicode, youpi!)

            Qui est le pire? J'ai l'impression que vous n'êtes pas trop au point sur vos connaissances des limites de votre OS préféré ;-)

            ne pas pouvoir stocker un nom de fichier de 64 caractères en 2016, c'est moins top que de ne pas pouvoir stocker un nom de fichier de 250 caractères en 2016.

            $ echo a >᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿᧿

            marche sous ligne de commande Windows (qui est le soucis pour ton bug report, utilisé l'API limitant à 260 caractères), pas sous Linux (qui limite à 255 octets, j'ai pris un caractères sur 2 octets ayant la flemme d'en chercher un sur 4 octets, bam la honte de ne pas pouvoir stocker ça).

            PS : bon, à décharge de Windows, Windows dit "file not found" pas logique de tout, Linux dit "File name too long" soit le bon message. 1 point pour Linux. Et surtout Linux sait afficher le nom en ligne de commande pas de "?", 2 points pour Linux (et des importants, plus que la limite à 255 octets, la phrase au dessus était surtout pour troller :) )

            • [^] # Re: choix de dossier

              Posté par (page perso) . Évalué à 1.

              Pour les utilisateurs Linux… Ben ce n'est jamais possible! Ext4, Btrfs, ZFS… sont tous limités à 255 octets (noter le mot, ça veut dire qu'on peut tomber à une limite de 63 caractères si ont s'amuse avec des caractères dans la plage très étendue Unicode, youpi!)

              Tu m'as mis un doute à l'esprit.
              Donc test.

              $ pwd     # tmpfs
              /tmp/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789
              
              $ pwd       # zfs
              /srv/HDD/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789/01234567890123456789012345678901234567890123456789
              • [^] # Re: choix de dossier

                Posté par (page perso) . Évalué à 7.

                Tu m'as mis un doute à l'esprit.

                En ext4, c'est le nom du fichier qui est limité à 255 octets, pas le chemin d'accès.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: choix de dossier

                  Posté par (page perso) . Évalué à 7.

                  J'ai testé pour être sûr:

                  #!/bin/bash
                  
                  name=a
                  for i in $(seq 1 260)  ; do 
                          name="a$name"
                  done
                  
                  touch $name
                  
                  $ LANG=C bash filename.sh 
                  touch: cannot touch 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': File name too long
                  

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: choix de dossier

              Posté par . Évalué à 10.

              Sur Linux et Windows, on a la même limite à 255/260 octets pour un nom (basename) de fichier ou de répertoire. Dans le cas d'une compilation, ce n'est généralement pas un problème parce que les nom de fichier/répertoire (basename) aussi longs, ça ne court pas les rues.

              La limite qui devient vite génante pour une compilation, c'est celle du chemin complet depuis la racine (readlink -f), c'est facile de constuire un chemin absolu trop long si l'arborescence du code source est un peu profonde. Et le probleme sous windows, c'est que la limite à 260 porte sur le chemin complet, alors que sous Linux ca doit plutot être 4096 (à verifier).

              Par exemple, sur un Linux:

              ~$ a=0123456789ABCDEF
              ~$ b=$a$a$a$a$a$a$a$a
              ~$ mkdir -p /tmp/$b/$b/$b
              

              on vient de créer un répertoire dont le chemin absolu est long de 391 octets, chaque element étant <= 128 octets.
              La même chose sous Seven SP1 :

              c:\> set a=0123456789ABCDEF
              c:\> set b=%a%%a%%a%%a%%a%%a%%a%%a%
              c:\> mkdir c:\temp\%b%
              c:\> mkdir c:\temp\%b%\%b
              c:\> mkdir c:\temp\%b%\%b\%b
              Le chemin d'accès complet c:\temp\0123456789...ABCDEF est trop long.
              

              Et c'est bien un problème d'API, pas du filesystem, les trois premieres lignes de bash passent très bien sous Cygwin et le répertoire est accessible dans l'explorateur.

              • [^] # Re: choix de dossier

                Posté par (page perso) . Évalué à -4.

                Et le probleme sous windows, c'est que la limite à 260 porte sur le chemin complet

                Dans ma tentative de troll, j'ai zappé cette différence, bon point!
                Reste qu'il y a des limites un peu partout ;-).

                c'est facile de constuire un chemin absolu trop long si l'arborescence du code source est un peu profonde.

                J'avoue avoir eu le problème une fois. Mais fallait que ce soit vraiment tarabiscoté (moi qui mettait un chemin super long avant), si on ne veut pas troller ça reste rare comme problème (sur tous les OS)…

                • [^] # Re: choix de dossier

                  Posté par (page perso) . Évalué à 2.

                  Problème pas si rare que ça, tu as créé le chemin trop long sous linux, copié/collé ou logiciel sans la limitation.

                  Quand tu vas tenter de supprimer l'arborescence, windows 7 par exemple va échouer.

                  Tu vas devoir couper des branches de l'arborescence à la racine pour pouvoir finir de supprimer tout l'arbre…

            • [^] # Re: choix de dossier

              Posté par . Évalué à 9.

              Pour les "fous" aimant les répertoires de plus de 260 caractères (noter le mot, ce n'est pas octets),

              […]

              Pour les utilisateurs Linux… Ben ce n'est jamais possible! Ext4, Btrfs, ZFS… sont tous limités à 255 octets

              Grosse confusion ici. Sous Windows, c'est le chemin entier qui est limité à 260 caractères. Sous Linux, c'est la longueur de chaque composant qui est limitée à 255, mais un chemin peut faire jusqu'à 4096 octets (d'après les quelques sources que je trouve sur le Web).

              Or, 260 caractères dans un chemin, ça s'atteint assez vite (ça m'est arrivé plusieurs fois sur divers systèmes d'intégration continue), alors que 4096 laisse beaucoup plus de marge.

              (quant à la distinction octets <-> caractères, elle a peu d'impact puisque la plupart des chemins, que ce soit sous Windows ou Unix, sont majoritairement ASCII)

              ça dépend de savoir si ils utilisent l'API étendue ou pas

              Ce n'est pas une "API étendue", c'est la même API mais avec une convention de nommage différente pour les chemins. Par exemple, C:\Foo\Bar sera soumis à la limite de 260 caractères, pour y échapper il faut écrire \\?\C:\Foo\Bar. Malheureusement cette syntaxe ne permet que les chemins absolus, ce qui limite la possibilité de l'utiliser toujours.

              • [^] # Re: choix de dossier

                Posté par (page perso) . Évalué à 8.

                (d'après les quelques sources que je trouve sur le Web).

                On le retrouve aussi dans un fichier limits.h (/usr/src/linux-headers-4.4.0-1-common/include/uapi/linux/limits.h chez moi)

                #ifndef _LINUX_LIMITS_H
                #define _LINUX_LIMITS_H
                
                #define NR_OPEN         1024
                
                #define NGROUPS_MAX    65536    /* supplemental group IDs are available */
                #define ARG_MAX       131072    /* # bytes of args + environ for exec() */
                #define LINK_MAX         127    /* # links a file may have */
                #define MAX_CANON        255    /* size of the canonical input queue */
                #define MAX_INPUT        255    /* size of the type-ahead buffer */
                #define NAME_MAX         255    /* # chars in a file name */
                #define PATH_MAX        4096    /* # chars in a path name including nul */
                #define PIPE_BUF        4096    /* # bytes in atomic write to a pipe */
                #define XATTR_NAME_MAX   255    /* # chars in an extended attribute name */
                #define XATTR_SIZE_MAX 65536    /* size of an extended attribute value (64k) */
                #define XATTR_LIST_MAX 65536    /* size of extended attribute namelist (64k) */
                
                #define RTSIG_MAX         32
                
                #endif
                

                On peut imaginer que les sources ne sont pas tordues et utilisent bien cette valeur.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: choix de dossier

                Posté par (page perso) . Évalué à 8.

                Sous Linux, c'est la longueur de chaque composant qui est limitée à 255, mais un chemin peut faire jusqu'à 4096 octets (d'après les quelques sources que je trouve sur le Web).

                En fait c’est un peu plus compliqué que ça. POSIX définit la « valeur minimale acceptable » à 256 (_POSIX_PATH_MAX), mais explique que la limite réelle peut être supérieure et surtout qu’elle n’est pas nécessairement constante (par exemple, elle peut varier selon le système de fichiers utilisé).

                Du coup, la limite réelle n’est pas à chercher dans un fichier d’en-tête, mais doit être obtenue à l’exécution avec pathconf(3).

            • [^] # Re: choix de dossier

              Posté par . Évalué à -8.

              D'abord, c'est faux : UTF8, chaque caractère prend deux octets, tu peux donc créer en ext4 un fichier avec 128 caractères.
              Faut tester avant de dire n'importe quoi.

              Ensuite, quelle rapport avec le fait que sous cmd.exe, deux commandes aient un comportement différent vis à vis des noms avec espaces ?

              • [^] # Re: choix de dossier

                Posté par (page perso) . Évalué à 3. Dernière modification le 13/04/16 à 11:23.

                UTF8, chaque caractère prend deux octets, (…) Faut tester avant de dire n'importe quoi.

                Je te conseille de te renseigner sur UTF-8 et Unicode avant de dire n'importe quoi…
                Ta phrase est simplement fausse (la bonne est : UTF8, chaque caractère prend 1, 2, 3, 4, 5 ou 6 octets, j'ai été gentil et me suis arrêté à 4 car l'IETF a fait une RFC limitant à 4 et a viré les 5 et 6 octets de la proposition initiale, et eu la flemme de trouver un caractère de 4 certes, mais ça ne rend pas ta phrase juste)

                tu peux donc créer en ext4 un fichier avec 128 caractères.

                Faux dans le cas général, vrai dans des cas particuliers (les plus utilisés, certes) : ça dépend des caractères choisis.
                La bonne phrase est : tu peux très souvent créer en ext4 un fichier avec 255 caractères, parfois ça limite à 127, parfois à 63 si tu utilises des trucs vraiment bizarre qui sont que sur 4 octets par caractères, bref ça dépend des caractères que tu choisis, tu peux juste être sûr pour 63 caractères, pas un de plus (si tu dis plus, tu assumes quelque chose de l'utilisateur).

                Note : c'est rare, c'est pour troller, mais dire que Linux accepte tout nom de fichier (sans path, j'ai compris :) ) de 64 caractères est simplement faux (sur la partie "tout"), le maximum "pour sûr quoi que l'utilisateur fait) est de 63 caractères, et certains nom de fichiers seront acceptés par Windows même un vieux quand ils seront refusés par Linux.

                quelle rapport avec le fait que sous cmd.exe, deux commandes aient un comportement différent vis à vis des noms avec espaces ?

                C'était ce qu'on appelle une aparté.

                • [^] # Re: choix de dossier

                  Posté par (page perso) . Évalué à 8.

                  Faux dans le cas général, vrai dans des cas particuliers (les plus utilisés, certes) : ça dépend des caractères choisis.

                  Après, si je ne me trompe pas, dans les langues encodées sur 4 octets dans Unicode ou les langues asiatiques ne sont pas des alphabets mais des idéogrammes. Et tu as besoin de moins d'idéogrammes normalement que de lettre d'un alphabet quelconque pour exprimer la même idée.

                  Résultat, si en effet le nom sera plus court, en terme d'informations stockées utiles il n'est pas dit que ce soit très limitant pour ces langues là.

                  Je ne suis pas spécialiste de ces langues là, je peux dire des conneries sur le sujet.

                  • [^] # Re: choix de dossier

                    Posté par . Évalué à 3.

                    Je ne suis pas spécialiste non plus, mais ça ne me parait pas si évident.

                    En japonais, il y a des idéogrammes mais aussi 2 syllabaires. Ça fait certes toujours moins de caractères pour un mot aussi long. Mais il faudrait savoir si en moyenne les mots sont plus ou moins long, ou s'il faut plus ou moins de mots pour exprimer la même idée.

                    • [^] # Re: choix de dossier

                      Posté par . Évalué à 4.

                      Les deux syllabaires, les ~10000 idéogrammes du chinois simplifié, etc., n'entrent en compte que pour le nombre de combinaisons possibles (sans tenir compte de la grammaire ou de la logique inhérentes à ces langues). Oui, les deux syllabaires du japonais peuvent (et sont) être mélangés dans une même phrase, mais au final, ça ne fait que 2×46 symboles avec la ponctuation et le chiffres en plus. Et tout ne sera pas utilisé en même temps.

                      Au final, si j'écris « わたしはラシャーと私はのフランスアム » (mélange d'hiragana et katakana, avec un idéogramme, car j'ai oublié tout mon japonais et j'ai laissé google traduire), je me retrouve avec 18 caractères, donc la plupart sont sans doute codés sur deux octets, et un peut-être sur plus, soit ~40 octets pour une phrase simple, mais comme on parle de noms de fichiers, ça devrait aller. :-)

        • [^] # Re: choix de dossier

          Posté par . Évalué à 5.

          "Sérieux si en 2016 tu n'es pas capable de gérer un nom de fichier avec un espace, c'est grave"

          Ça dépend de ce qu'on appelle gérer, sous Linux ça peut passer avec des guillemets (comme sous Windows pour une commande "Dir") en shell, mais je ne mets jamais d'espace dans un nom de fichier, je les remplace par des "_" qui sont faits pour ça (sinon à quoi sert ce caractère d'ailleurs ?).

          Quand on est un habitué de la ligne de commande pour faire des recherches ou des mini-traitements, avec par exemple des "find" ou des "locate" qui sont tubés (pipe) dans une commande qui suit, les espaces très franchement c'est ch*ant (même si en écrivant ses scripts ou commandes d'une certaines façon ça peut passer).

          • [^] # Re: choix de dossier

            Posté par (page perso) . Évalué à -10.

            je les remplace par des "_" qui sont faits pour ça

            J'adore les excuses des "vieux" : on a appris à souffrir et s'interdire l'espace dans le nom de fichier, donc ce n'est pas gênant. Les nouveaux ne comprennent tout simplement pas "" (comme "|" qu'ils n'utilisent jamais non plus) et mettent des espaces pour désigner un espace dans leur nom de fichier (est-ce si anormal?). Avoir un "" est juste moche.

            Franchement, que ce soit chiant pour ta ligne de commande à toi, ce n'est pas la priorité pour le cas général, où l'humain "normal" doit plutôt être au centre des préoccupation. Si même Linus dit que pour le desktop c'est pas terrible avec Linux, peut-être que ça vient de la publicité de gens mettant des "_" à la place de " " dans les noms de fichiers?

            • [^] # Re: choix de dossier

              Posté par . Évalué à 6.

              Je n'ai pas "moinssé" ton commentaire mais je cherche encore le rapport entre le fait que Linux n'a pas encore pris sur le Desktop, et le fait de préférer mettre des "_" dans les noms fichiers quand on est utilisateur.

              Par ailleurs je viens d'y penser, sur les sites de téléchargement (et sur la Mule) étrangement les espaces sont remplacés non pas par des "_" mais par des ".", exemple : Weeds.6x13.Theoretical.Love.Is.Not.Dead.Vostfr.Hdtv-Ghost-Team.avi . Finalement les Windowsiens (très forte majorité d'utilisateurs de ces sites) savent remplacer les espaces quand ça facilite le fonctionnement :-) .

              • [^] # Re: choix de dossier

                Posté par (page perso) . Évalué à -7. Dernière modification le 13/04/16 à 11:09.

                je cherche encore le rapport entre le fait que Linux n'a pas encore pris sur le Desktop, et le fait de préférer mettre des "_" dans les noms fichiers quand on est utilisateur.

                C'est "l'esprit" des gens conseillant. Si pour une personne qui a un problème avec des espaces dans un nom de fichier, on lui sort "tu as tort, remplace par des underscores, comme moi", ça ne donne franchement pas envie de rester sur cet OS. C'est un "détail", mais détail+détail+…

                Finalement les Windowsiens (très forte majorité d'utilisateurs de ces sites) savent remplacer les espaces quand ça facilite le fonctionnement :-) .

                Ton exemple est pris de gens assez conservateurs (pas les "clients finaux", mais les "sources" qui votent pour des règles et qui décident du nom). Et on voit aussi que chacun y va de son délire (underscore par ci, point par la… amusant).

                Bref, juste pour dire qu'il va falloir vivre avec les espaces, car de plus en plus d'utilisateurs ne connaissent pas ces "caractères de remplacement" (et non, tout le monde n'est pas sur les site de téléchargement non plus…), et je suis plutôt dans l'idée que la machine doit s'adapter à l'homme et pas l'homme qui doit s'adapter à la machine.

                • [^] # Re: choix de dossier

                  Posté par . Évalué à 7.

                  C'est "l'esprit" des gens conseillant. Si pour une personne qui a un problème avec des espaces dans un nom de fichier, on lui sort "tu as tort, remplace par des underscores, comme moi", ça ne donne franchement pas envie de rester sur cet OS. C'est un "détail", mais détail+détail+…

                  Pour le coup je suis assez d'accord. Gamin, j'utilisais DOS, puis quand Windows 95 est arrivé, j'ai usé et abusé des noms avec espaces (malgré l'abstraction un peu ratée, vu qu'utiliser un terminal DOS pouvait parfois toujours être nécessaire, et du coup on se retrouvait avec monfic~1.txt au lieu de monfichieràmoiquejaime.txt). Avec bash_completion je peux facilement utiliser des espaces en ligne de commande (il rajoute les guillemets tout seul, et je suis sûr que zsh peut faire pareil), mais c'est vrai que mon réflexe est d'utiliser des underscores, et c'est vrai que je peste un peu contre les espaces dans les noms de fichiers, mais je me rends bien compte que c'est un réflexe de vieuxcon™®©.

                  En règle générale, les espaces dans les noms de fichiers ne gênent absolument pas lorsqu'on utilise une GUI (je n'ai pas trouvé d'exemple gênant en tout cas), mais en ligne de commande ça force juste à rajouter quelques symboles (guillemets), mais bon, on s'y fait. :-)

                • [^] # Re: choix de dossier

                  Posté par . Évalué à 2. Dernière modification le 14/04/16 à 10:59.

                  Je ne conseille l'absence d'espace que si quelqu'un veut utiliser des scripts ou faire des commandes rapides en bash. Si je mets un nouveau sous Linux je lui dis que ça peut être plus pratique d'éviter les espaces, après ce n'est pas une contrainte s'il n'utilise jamais la ligne de commande.

                  Je me sers aussi de l'interface graphique quand c'est plus pratique que la ligne de commande, mais quand tu vois le nombre de gens qui ont installé Cygwin rien que pour pouvoir utiliser la ligne de commande pour des petites manips, c'est qu'il y a un besoin. Et là, les espaces font vite ch*er alors que franchement avoir des " _ " dans les noms à la place des espaces je vois pas le souci, d'ailleurs j'utilise régulièrement la commande « rename 's/ /_/g' toto* tata* » quand j'ai récupéré des fichiers avec des espaces (exemple typique avec youtube-dl sur les replay TV), c'est vite réglé.

                  Sinon on est d'accord que la machine doit s'adapter à l'homme, mais la solution aux espaces dans les noms de fichiers et les petites manips en bash n'est pas encore satisfaisante.

                • [^] # Re: choix de dossier

                  Posté par . Évalué à 9.

                  C'est "l'esprit" des gens conseillant. Si pour une personne qui a un problème avec des espaces dans un nom de fichier, on lui sort "tu as tort, remplace par des underscores, comme moi", ça ne donne franchement pas envie de rester sur cet OS. C'est un "détail", mais détail+détail+…

                  Je suis tout à fait d'accord avec toi concernant la gestion des espaces qui de toute façon est assez bien gérée même en ligne de commande, à condition de penser à les prendre en compte.

                  En revanche moi que je me retrouve sur un windows, que j'ai besoin de faire un Ç ou un É et qu'on me répond qu'il faut passer par une combinaison de touche impliquant un ALT + un nombre à connaitre par cœur et que le reste me dis que ça va plus vite de faire un google c cédille majuscule et un copier coller…j'ai tendance à pouffer sur le Qui est prêt pour le desktop ?

                  • [^] # Re: choix de dossier

                    Posté par . Évalué à 4.

                    prends le clavier fr_oss pour Windows.

                    Ça change la vie.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: choix de dossier

                    Posté par (page perso) . Évalué à 3.

                    j'ai tendance à pouffer sur le Qui est prêt pour le desktop

                    Ceux qui ont un modèle économique attirant pour les éditeurs ? Non ?

                  • [^] # Re: choix de dossier

                    Posté par . Évalué à 3.

                    j'ai tendance à pouffer sur le Qui est prêt pour le desktop ?

                    Haha bien vu :-) .

                    J'ai découvert il y a longtemps le clavier x-fr-latin9 (super aussi pour taper les guillemets français « » ) mais comme l'a dit quelqu'un on n'est pas toujours admin sous son poste Windows.

                    (PS : j'ai beau être tout ce qu'il y a d'expérimenté en bash (et tous les petits programmes genre awk sed et compagnie) et en d'autres langages, c'est quand même vachement mieux d'éviter les espaces dans les noms de fichiers parce que de temps à autre ça complique inutilement les recherches que je fais.

            • [^] # Re: choix de dossier

              Posté par . Évalué à 6.

              J'adore les excuses des "vieux"

              Je te conseille la lecture de Path Name Portability, par des gens qui savent de quoi ils parlent (notamment concernant les limites). Tu y apprendras notamment que la norme POSIX elle-même considère qu'un nom portable, c'est uniquement des lettres, des chiffres et -, _ et . (et donc, pas d'espace).

        • [^] # Re: choix de dossier

          Posté par . Évalué à 3.

          Sérieux si en 2016 tu n'es pas capable de gérer un nom de fichier avec un espace, c'est grave.

          C'est vrai mais restons simples et homogènes autant que possibles. On serait sans doutes tous surpris du cumul des temps perdus par l'ensemble des développeurs et autres sysadmin de la planète à cause de l'espace entre Program et Files. Ça doit se chiffrer en années..

          • [^] # Re: choix de dossier

            Posté par . Évalué à 6.

            "%PROGRAMFILES%", c'est pas pour les pigeons.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: choix de dossier

              Posté par . Évalué à 0.

              Merci pour l'info mais hélas encore aujourd'hui, une telle variable dans les fichiers de configurations ne donne pas le résultat escompté. Alors tu cherches, tu ne comprends pas et tu perds ton temps cf.mon commentaire du dessus. Et puis bon, ce n'était qu'un exemple. Je crois pas que %MONREPERTOIRE% existe.

      • [^] # Re: choix de dossier

        Posté par . Évalué à 8.

        Entre les noms de répertoires avec des espaces qui font tout péter

        On est en 2016 (et Linux permet d'ailleurs aussi les noms de fichiers/répertoire avec des espaces). Je n'en suis pas fan, mais si "ça fait tout péter" comme tu dis, c'est un bug qui se doit donc d'être corrigé côté LibreSSL ! Je ne suis pas familier de la base de code LibreSSL, mais il me semble que gérer les espaces ne devrait quand même pas être la mer à boire…

Suivre le flux des commentaires

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