Journal Une alternative à make(1)

Posté par  (site web personnel) .
Étiquettes : aucune
4
22
juil.
2009
J'aimerais vous présenter un projet que je suis en train de développer, et qui est une nième alternative à la commande make que nous connaissons tous. Je l'ai nommé TBuild, le T étant là pour indiquer que j'utilise le langage Tcl.

Alors, qu'est-ce que je reproche à make ?

- il est trop rudimentaire (c'est la raison de vivre d'automake)

- il est trop lié à la plateforme cible (on écrit des lignes de commande shell, et le shell, ça change pas mal selon la plateforme, de même, les options des compilateurs changent, on a créé autoconf et mingw pour ça)

- il ne gère pas bien les fichiers avec des noms particuliers (avec des espaces surtout). Souvent, même, les alternatives à make ont les mêmes problèmes car elles fonctionnent (comme make) par remplacement de variables dans du code shell. Si j'écris par exemple:

$(GENPDF) -o $@ $+

et que le fichier cible ($@) est par exemple mon joli document.pdf et que mon fichier source ($+) est ma jolie source.in, j'ai la ligne de commande suivante (par exemple):

genpdf -o mon joli document.pdf ma jolie source.in

Le shell va comprendre tout ça de travers et découper en mots selon les espaces. Si je met des guillemets dans ma commande, je pourrais m'en sortir jusqu'à ce que je rencontre un nom de fichier avec des guillemets ou une apostrophe. Pour le code source c'est rare, mais si on s'occupe de documents rédigés, ça peut arriver plus souvent.

Ce qui serait bien d'avoir :

- la puissance d'un langage de script complet pour pouvoir entre autre faire de la détection de plateforme au démarrage et adapter ce qu'on compile à l'environnement

- une syntaxe proche du shell pour ne pas avoir à se baser sur l'interprétation de notre commande par un shell. Il s'agit de pouvoir faire un fork()+exec("gcc", "-o", ...) de la commande a exécuter directement plutôt que un appel de system("gcc -o ...") qui est interpréta par le shell.

Et je n'ai rien trouvé.
Donc, j'ai créé mon propre système.

TBuild

J'avais besoin d'un langage de programmation évolué proche de la syntaxe shell, le choix s'est donc naturellement porté vers Tcl (je n'en connais pas d'autres avec ces caractéristiques).

Après, je devais me décider sur une sémantique. Comment décrire avec Tcl les étapes de compilation ? Je me suis basée sur une alternative à make que je connaissait bien: Jam.

Voir un exemple de TBuildfile.tcl

Pour le moment, les fonctionnalités restent très simples, et pas encore toutes testées. Il n'est pas encore possible de construire des fichiers en parallèle (mais c'est prévu).

Il est aussi prévu que ce système soit sécurisé. C'est à dire qu'il serait possible de lancer tbuild sur un projet qu'on vient de télécharger et d'être sûr qu'il ne posera pas de problèmes. Tant que gcc n'a pas de failles de sécurité bien sûr :)

L'idée est que le support des langages sur fait dans des packages (par exemple le support du langage C). Ces packages seraient préinstallés, et sont a priori sécurisés (Clang ne pourra par exemple que lancer gcc sur des fichiers ne sortant pas du répertoire source). Il sera possible d'importer un package non sécurisé, mais l'utilisateur sera averti et aura la possibilité d'annuler l'opération.


Voir le code: http://gitorious.org/tbuild/tbuild
  • # cmake, scons ?

    Posté par  . Évalué à 2.

    Tu as regardé Cmake et Scons ?
    Qu'est-ce qui ne te plait pas chez eux ?

    http://www.cmake.org/
    http://www.scons.org/
    • [^] # Re: cmake, scons ?

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

      cmake n'est pas un remplaçant de make, mais des autotools, donc sauf hack particulier ils doivent souffrir du même problème.
      Sinon pour scons, il devrait effectivement pouvoir répondre au problème.
      • [^] # Re: cmake, scons ?

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

        Je suppose que scons est pas mal, mais je trouve que la syntaxe python n'est pas forcément appropriée pour lancer des commandes systèmes. De plus, du peu que j'ai pu voir, je n'ai pas l'impression que les commandes a executer sont générées en faisant attention aux noms de fichiers.
        • [^] # Re: cmake, scons ?

          Posté par  . Évalué à 2.

          Tu ne lances pas de commandes directement avec SCons. Tu donnes la liste des fichiers, tu donnes la classe de l'outil à utiliser et il lance les commandes tout seul... dans le cas où ton outil fait parti des classes prédéfinies, ce qui est le cas de la plupart des compilos. Et même si il faut ré écrire une classe, c'est assez simple en se basant sur celles existantes.

          Pour les noms de fichiers, en python tu es forcé de déclarer une string avec des guillemets autour, donc tous les noms de fichier sont à la même enseigne, espace ou non.

          J'utilise SCons au boulot pour un projet assez complexe, qui compile sous windows/cygwin/linux, pour plusieurs type de processeurs, avec différents compilos sélectionnables, des milliers de fichiers, des .h générés par script, et on est globalement assez content de ce choix.

          Grosso modo, les plus, c'est déjà que tout est en python, et ça, c'est énorme, surtout quand on compare avec cette daube infâme d'autotools. Par ailleurs, c'est puissant, il y a plein de fonctionnalités, les scripts sont concis et c'est relativement rapide. De plus la mailing list est très active et on reçoit vite de l'aide.

          Les moins, c'est que ça n'est pas intuitif au début, ensuite que c'est peu machine à gaz par en dessous, cad que quand y a un bug dans des cas tordus, pour débugger le bordel il faut s'accrocher serieusement.
          • [^] # Re: cmake, scons ?

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

            Que scons gère les noms de fichiers particuliers, je n'en doute pas, par contre ça ne veux pas dire que les lignes de commande sont générées correctement. C'est la même chose avec Jam. Aucun problème avec Jam, mais lorsque les commandes sont générées, il peut y avoir des problèmes
      • [^] # Re: cmake, scons ?

        Posté par  . Évalué à 1.

        Tu as aussi waf (http://code.google.com/p/waf/ ), qui est un peu dans le même esprit que scons (mais apparemment plus simple, léger et rapide).
      • [^] # Re: cmake, scons ?

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

        Je suppose que scons est pas mal, mais je trouve que la syntaxe python n'est pas forcément appropriée pour lancer des commandes systèmes. De plus, du peu que j'ai pu voir, je n'ai pas l'impression que les commandes a executer sont générées en faisant attention aux noms de fichiers.
  • # Et les guillemets ?

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

    Ça marche pas mieux en mettant les guillemets ?


    psy@tarasque:/tmp% cat "mon fichier"
    tada !
    psy@tarasque:/tmp% cat Makefile
    FICHIER=mon fichier
    FICHIER2="mon fichier"
    ALL:
    echo "${FICHIER} :" && cat "${FICHIER}"
    echo ${FICHIER2}\ : && cat ${FICHIER2}
    psy@tarasque:/tmp% make
    echo "mon fichier :" && cat "mon fichier"
    mon fichier :
    tada !
    echo "mon fichier"\ : && cat "mon fichier"
    mon fichier :
    tada !


    Donc je pense que

    $(GENPDF) -o "$@" "$+"

    devrait donner le résultat escompté, mais je peux me tromper. Avant de réinventer la roue, faudrait s'assurer qu'on utilise correctement celle qui existe.
    • [^] # C'est du poulet !

      Posté par  . Évalué à 6.

      J'ai beau relire ton commentaire (et constater qu'il est pertinenté) je crois ne pas saisir de quoi tu parles.

      Quand je lis (dans le journal) :

      Le shell va comprendre tout ça de travers et découper en mots selon les espaces. Si je met des guillemets dans ma commande, je pourrais m'en sortir jusqu'à ce que je rencontre un nom de fichier avec des guillemets ou une apostrophe. Pour le code source c'est rare, mais si on s'occupe de documents rédigés, ça peut arriver plus souvent.

      J'ai envie de te dire qu'avant de commenter il faut lire ce que l'on commente.
      Ce journal est clair et argumenté et en plus je te trouve bien agressif sur la réutilisation alors que le journal décrit ce qui a été réutilisé ou ce dont il s'est inspiré.

      Pourrais-tu préciser (merci d'avance) en quoi l'argument
      problèmes car elles fonctionnent (comme make) par remplacement de variables dans du code shell
      n'est pas recevable ?
      • [^] # Re: C'est du poulet !

        Posté par  . Évalué à 1.

        genpdf -o mon joli document.pdf ma jolie source.in
        genpdf -o mon joli document.pdf "ma jolie source.in"
        • [^] # Re: C'est du poulet !

          Posté par  . Évalué à 2.

          un nom de fichier avec des guillemetsgenpdf -o mon "joli" document.pdf ma "jolie" source.inJe demande juste une explication.
          C'est pas agressif.
          Vous avez peut-être raison.
          Mais là c'est loin d'être évident pour moi.
          • [^] # Re: C'est du poulet !

            Posté par  . Évalué à 1.

            En gros le shell utilise les blancs pour séparer les "mots".
            Ce qui est entre les quotes est considéré comme un seul mot.
            • [^] # Re: C'est du poulet !

              Posté par  . Évalué à 1.

              Raaah !
              Mais lis un peu avant d'écrire.

              L'auteur du journal sait bien que les espaces posent problème et que les guillemets sont la solution à ce problème (et moi aussi au passage).
              citation :
              ...un nom de fichier avec des guillemets...

              Le problème est :
              Et si le mot contient des guillemets tu fais comment ?

              Perso, pour mes insignifiants petits scripts, quand il y a des guillemets, j'utilise un "vrai" langage (perl,python,java... peu importe) mais s'il existe une solution en shell/make, ça m'intéresse vraiment de le savoir.

              Note :
              Quand le texte est comme ça : un nom de fichier avec des guillemets cela veut dire que c'est une citation. Peut-être que la CSS que tu utilises ne t'as pas permis de voir que je citais ?
              • [^] # Re: C'est du poulet !

                Posté par  . Évalué à 5.

                > mais s'il existe une solution en shell/make, ça m'intéresse vraiment de le savoir.

                pour le bash
                ptit test :
                touch 'plop"tak tar'
                for i in *
                do
                echo "$i"
                done
                aucun problèmes
                le for i in $(ls ) pose évidemment problème(l'espace, pas le ")
                si c'est une affectation de variable
                PLOP='plop"tak tar' (marche aussi dans make)

                Le point important est dès l'utilisation de variable, ne pas oublier les "" autour
                pour le make un
                TONK= 'plop" par'
                passe sans soucis.

                cependant j'aime bien le perl aussi (ne serai ce que pour son qw )

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: C'est du poulet !

                  Posté par  . Évalué à 2.

                  Enfin une vraie réponse ;) merci.

                  Ce que tu dis marche mais tu utilises les cotes simples car tu sais que le fichier contient une quote double.

                  Si tu ne sais pas (a priori) si le fichier a une simple cote ou une double cote, tu fais comment ?
                  pire :
                  Si il y a les deux sortes de guillemets dans le nom du fichier tu fais comment ?
                  • [^] # Re: C'est du poulet !

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

                    Tu renommes tes fichiers ! \o/

                    Si vraiment tu tiens à garder un fichier

                    psy@tarasque:/tmp% touch «\"\'».ex
                    psy@tarasque:/tmp% for i in *.ex;do echo "$i";done
                    «"'».ex


                    Donc ça à l'ai de passer en shell (zsh).
                  • [^] # Re: C'est du poulet !

                    Posté par  . Évalué à 5.

                    touch "plop\"plor ' tiar"

                    for i in *
                    do
                    a="$i"
                    echo "$a"
                    done
                    ça ne pose pas de problèmes
                    pour l'affectation de variable il faut utiliser les "" et protéger les " par un \ (de même si il y a un \ ) (là on commence à jouer un peu)


                    pour le résultat d'un find, dans ce cas il vaut mieux utiliser -print0 et xargs juste derrière (avec un -0 )

                    dans une variable make
                    PLOP="plop \"ecrou 'ar plor"

                    Mais fort heureusement je ne tombe pas souvent sur ce genre de cas.

                    à noter cependant qu'en shell il y a une différence majeur entre " et '; dans l'un on interprète les $ $( `` (") \ et l'autre on donne une chaine brute (équivalent du qw en perl)

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                  • [^] # Re: C'est du poulet !

                    Posté par  . Évalué à 3.

                    quand on utilise un système unix et donc la ligne de commande, pourquoi ne pas essayer d'utiliser des caractères standards au lieu de s'embêter avec des espaces ou des guillemets ?

                    Pour éviter les problèmes (déplacement sur clé usb en fat32 etc), chez moi tous les fichiers ont un _ à la place des espaces, pas d'accent, et surtout pas des caractères spécifiques types apostrophes, guillemets, arobases etc

                    Si on souhaite retirer ces caractères (parce qu'ils viennent d'ailleur), il y a detox : http://detox.sourceforge.net/

                    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                    • [^] # Re: C'est du poulet !

                      Posté par  . Évalué à 3.

                      Pour moi Linux n'est pas synonyme de ligne de commande.
                      Par l'IHM j'arrive facilement à donner comme nom de mes document, le titre de leur contenu et c'est bien.
                      Je ne veux pas avoir à intégrer le fait que je vais peut-être scripter un jour quand j'utilise mon ordi.
                      De plus, je suis pas seul au monde et les fichiers que je reçois je veux pouvoir les traiter aussi.
                      Alors le coup des _ c'est limité à tes fichiers donc bof.
                      detox ça change le nom du fichier. Si ce fichier vient de l'extérieur, tu n'as pas forcément intérêt à en modifier le nom.

                      UTF8 est un standard, je le veux pour mes nom de fichiers ;)
                      • [^] # Re: C'est du poulet !

                        Posté par  . Évalué à 0.

                        Tu portes bien ton pseudo :p

                        Un standard est un standard, il se doit d'être respecté.
                        Si certaines de tes IHM marchent, rien ne te garantie que ce sera toujours le cas, ni pour toutes.

                        Unix est conçu comme ça. Point.

                        Vouloir des guillemets dans les noms de fichiers c'est comme vouloit mettre des nom longs sous DOS (ou des ~) ou des accents dans les noms de domaines, c'est une mauvaise idée.
                        Si tu veux absolument le faire, libre à toi, mais ne te plaint pas.
                        • [^] # Re: C'est du poulet !

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

                          Autant je ne suis pas pour réinventer la roue, autant je pense que c'est à l'outil d'être adapté à ce qu'on veux faire, et pas adapté ce qu'on veut faire à ce que permet l'outil.
                          • [^] # Re: C'est du poulet !

                            Posté par  . Évalué à 1.

                            En théorie, oui,

                            En pratique, un outil ne peut pas être adaptés à tous les cas d'utilisations,
                            Encore moins aux plus idiots (désolé pour le idiot mais des guillemets dans les noms de fichiers...),
                            Imagines la tronche de ton Unix ou d'internet sinon.
                            • [^] # Re: C'est du poulet !

                              Posté par  . Évalué à 4.

                              Question bete.

                              Ca a quoi d'"idiot"?
                              Un nom de fichier a une semantique particuliere (decrire le fichier).

                              Moi ce que je trouve idiot, c'est de se trainer des problemes qui sont du a des "best practices" des annees 70 qui n'ont plus aucun sens aujourd'hui.

                              Si le guillemet est un caractere legal dans un nom de fichier, qu'il apporte un plus a la description du fichier, que le systeme a prevu et meme mit en place un moyen de l'utiliser dans les nom de fichier, ca a quoi d'idiot?

                              Ce qui est tres tres tres idiot par contre, c'est que le systeme ne propose rien pour resoudre efficacement ce probleme .

                              On peut imaginer plusieurs solutions pour regler ca, a divers niveaux (la comme ca, sans vraiment reflechir, un ls particulier qui te retourne un nom de fichier echappe par exemple, ca serait deja tres bien), mais non, l'utilisateur est livre a lui meme, oblige de prier pour ne pas avoir de simple (ou double) quote dans ses noms de fichier ou se fader des solutions incongrues a base de sed/awk
                              • [^] # Re: C'est du poulet !

                                Posté par  . Évalué à 4.

                                Je suis d'accord avec Geb.

                                Ce n'est pas à l'homme de s'adapter à l'outil informatique, mais néanmoins cela n'excuse pas n'importe quel caprice par rapport à ce qui est pratique ou pas.

                                Les espaces dans les noms de fichiers c'est possible mais en réalité c'est une horreur puisqu'il n'y a pas moyen de savoir ce qui délimite la fin d'un fichier ou pas. C'est forcément source d'erreur dès qu'on a besoin de faire des opérations de fichiers avancées. La secrétaire qui utilise windows et word n'aura pas de problème, mais le geek qui devra faire de la programmation ou du traitement de fichiers par lots aura des soucis.

                                Pour l'unicode, cela fonctionne bien sous linux, mais quand on passe des fichiers avec de l'unicode sur des supports amovibles avec un FS du siècle dernier, ou sur un système obsolète, cela pose des problèmes.

                                Décrire un fichier avec des guillemets, je ne vois pas trop l'intérêt. C'est pour donner une nuance ? Genre :
                                Jeune fille en tenue "légère".jpg cela veut dire que c'est une photo de Britney à poil ?
                                ou
                                Mes Musiques "légales" c'est pour le dossier des trucs téléchargés avec amule ?


                                Enfin bon, si c'est possible de le faire, pourquoi pas, mais comme disait Geb, il ne faut pas se plaindre si cela a des effets de bord ensuite.

                                La prochaine demande c'est quoi ? Les italiques et les couleurs dans les titres de fichiers ?

                                (et pourtant c'est moi qui suis pour l'utilisation possible du html dans les courriels...)

                                Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                                • [^] # Re: C'est du poulet !

                                  Posté par  . Évalué à 1.

                                  Décrire un fichier avec des guillemets, je ne vois pas trop l'intérêt. C'est pour donner une nuance ?
                                  Ben la description se faisant en langage humain, les humains ayant invente des caracteres speciaux, ne pas voire l'interet est revelateur d'un gros probleme de ta part (je pense surtout un bon gros formatage par les limitations de l'outil).

                                  Tiens, petit exemples de nom de fichier trouve dans mon "My Documents":
                                  Panier - Apple Store (France).pdf
                                  Air Tahiti Nui Confirmation ( eticket number ) - monNom.pdf

                                  Bouh les mechants, ils ont ose mettre des parentheses, ca va peter le script du geeks qui fait mal son boulot (ou qui utilise un outil prehistorique).

                                  Si ca peut te rassurer, c'est pareil sous windows si je me rappelle bien...

                                  Le design limite d'outil dont l'utilisateur n'a souvent meme pas connaissance leak directement dans l'utilisation du systeme, si c'est pas la preuve d'une inadaptation de l'outil, je sais pas ce que c'est...
                                  • [^] # Re: C'est du poulet !

                                    Posté par  . Évalué à 1.

                                    ben on parle de guillemets, et toi tu me donnes des exemples avec des parenthèses...


                                    Panier - Apple Store (France).pdf
                                    Air Tahiti Nui Confirmation ( eticket number ) - monNom.pdf


                                    rassure-moi, c'est généré automatiquement ce genre de nom de fichier ?

                                    Et cela apporte quoi d'avoir la parenthèse par rapport au mot "Apple Store France" ?

                                    Bref, rien, mais si cela vous plait de les utiliser, ne vous privez pas, moi cela ne me dérange pas, sauf quand on me les envoie...

                                    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                                    • [^] # Re: C'est du poulet !

                                      Posté par  . Évalué à -1.

                                      ben on parle de guillemets, et toi tu me donnes des exemples avec des parenthèses...

                                      Daaaah...
                                      T'es gland ou quoi?


                                      $ tail Panier\ -\ Apple\ Store\ (France).pdf
                                      bash: syntax error near unexpected token `('

                                      $ tail L'armee.pdf
                                      >

                                      login@machine ~/My Documents


                                      Le probleme c'est pas juste le guillemet ou l'espace, c'est l'ensemble des caracteres reserves en shell qui sont pourtant tout ce qu'il ya de plus legal dans un nom de fichier

                                      Parenthese, espace, simple quote, double quote, je sais pas quoi d'autre qui est reserve, tout ca pose probleme...
                                  • [^] # Re: C'est du poulet !

                                    Posté par  . Évalué à 3.

                                    Le design limite d'outil dont l'utilisateur n'a souvent meme pas connaissance leak directement dans l'utilisation du systeme, si c'est pas la preuve d'une inadaptation de l'outil, je sais pas ce que c'est...

                                    Tu es en train de me dire qu'il faut adapter une scie sauteuse pour qu'elle soi capable de planter des clous, ou une pelleteuse pour qu'elle soit capable de me servir pour porter la nourriture à la bouche comme une fourchette ...

                                    Un util a des limites, et si tu ne peux pas faire ce que tu veux parce que l'outil ne te le permet pas il faut changer d'outil et utiliser un outil mieux approprié à ce que tu dois faire.
                                    • [^] # Re: C'est du poulet !

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

                                      Faut pas tomber dans la mauvaise foie non plus.

                                      Ici il s'agit de gérer un cas de nom de fichier avec certains caractères.

                                      Si ta scie sauteuse est incapable de scier une planche d'une certaine forme, tu peux avoir envie d'une scie sauteuse qui en serait capable.
                                    • [^] # Re: C'est du poulet !

                                      Posté par  . Évalué à 2.

                                      ben on tente pas d'utiliser une scie sauteuse pour planter des clous, on tente d'utiliser un marteau pour enfoncer un clou.

                                      Manipuler des fichiers et les passer a des commandes, c'est quand meme un des use case de base du shell.

                                      Le probleme c'est que le marteau refuse de planter certains clous, pourtant vendus par le fabriquant dudit marteau, a moins de d'abords les peindre pour les rendre plus jolis.
                                      Et l'autre probleme, c'est que si tu les peints pas avant ces clous particulers, ils petent, te faisant t'eclater le pouce et te faire proferer d'ignobles jurons pendant 30 minutes.
                                      Et cerise sur le gateau, t'as pas vraiment moyen de moyen fiable pour savoir s'il faut peindre le clou avant.

                                      Alors, bien sur, tu peux sortir l'artillerie lourd et peindre tous les clous apres les avoir achetes, histoire de, mais tu vas passer un temps monstrueux a le faire, ca va te couter du fric, et le boulot du bricolo c'est de planter les clous, pas de les peindre.
                                      Et en plus, t'as toujours qq rares clous qui vont peter s'ils sont peint, mais ne peteront pas s'ils ne sont pas peint.
                                      Le constructeur refuse de vendre des clous peints a l'avance, ca fait 35 ans qu'il fait ca, que le probleme est connu, et qu'il ne fait rien pour.
                                      Il pretends que si les clous petent, c'est la faut au bricolo, qu'il a qu'a pas planter ces clous la, non mais, ho, faut pas deconner quand meme, con de bricoleur.
                                      • [^] # Re: C'est du poulet !

                                        Posté par  . Évalué à 1.

                                        tu exageres dans ta comparaison. Je dirtais plutot que tu utilises un marteau trop petit pour planter de gros clous dans un matériau très dur ....
                                • [^] # Re: C'est du poulet !

                                  Posté par  . Évalué à 1.

                                  C'est une horreur parce que le shell gère ça comme une merde ... si t'avais un minimum de typage et pas tout chaine de caractère avec des sémantiques pour les caractères, un nom de fichier pourrait être traité comme un tout et pas coupé au beau milieu au bon vouloir du shell qui "applatit" tout en permanence.

                                  Je me suis laissé dire que t'aurais pas ce problème avec un truc genre powershell de Ms dans les trolls sur celui-ci à l'époque.
                                  • [^] # Re: C'est du poulet !

                                    Posté par  . Évalué à 2.

                                    Je tiens juste à te rappeler que le shell à l'origine est censé être un truc qui lance des commandes et qu'accessoirement il te permet de les séquencer de façon simple, et à mon avis il le fait bien.

                                    Maintenant, si tu veux mettre du typage dedans c'est sur que l'objectif initial (pouvoir séquancer des commandes de façon simple) n'est plus forcément atteint.
                                    • [^] # Re: C'est du poulet !

                                      Posté par  . Évalué à 3.

                                      J'y crois pas une seconde. Pour enchapiner les commandes et faire des choses un peu plus complexes t'es obligé d'introduire des variables.

                                      Le seul soucis c'est que tu n'as qu'un seul type en shell : les chaines de caractère. Pour contruire une commande, il ne fait rien d'autre que de la concaténation de chaine de caractère, qu'il doit ensuite parser de nouveau pour "re découvrir" les paramètres, en oubliant totalement la structures des éventuelles variables. Alors qu'un nom de fichier est atomique et ne devrait être décomposé que quand on en a réellement besoin, le shell le refait en permanence.


                                      Il faudrait vraiment moderniser un peu tout ça. Certe ça marche et on s'en accomode, mais ça reste viellot et un peu bidouilles pour s'en sortir ...
                                      • [^] # Re: C'est du poulet !

                                        Posté par  . Évalué à 2.

                                        mais non voyons, ecoutes totof2000.
                                        Le shell est parfait.
                                        C'est au systeme de fichier de s'adapter et de determiner quels nom de fichiers sont valides.
                                        C'est a l'utilisateur de decouvrir le chemin eclaire du shell, apres a long voyage a travers les man pages de bash, il aura la revelation: des parentheses dans un nom de fichier, c'est le mal absolu.
                                        Non pas parce que ca n'est pas de sens, mais parce que shell a decide qu'il allait se ramasser en beaute sur un nom de fichier avec une parenthese.

                                        Comme le shell est parfait, le probleme ne peut venir que de l'utlisateur ou du systeme de fichier.

                                        Pourquoi donc un outil concu pour manipuler les fichiers du disque dur devrait supporter aisement l'integralite des caracteres legaux des filesystems?
                                        • [^] # Re: C'est du poulet !

                                          Posté par  . Évalué à 3.

                                          Le shell est parfait.
                                          Je n'ai jamais dit ça ...
                                          C'est au systeme de fichier de s'adapter et de determiner quels nom de fichiers sont valides. Et pourtant, tu ne peux pas utiliser n'importe quel caractère pour un nom de fichier, même sous windows ...
                                          C'est a l'utilisateur de decouvrir le chemin eclaire du shell, apres a long voyage a travers les man pages de bash, il aura la revelation: des parentheses dans un nom de fichier, c'est le mal absolu. Affirmation ridicule : le shell permet de le gérer.
                                          • [^] # Re: C'est du poulet !

                                            Posté par  . Évalué à 1.

                                            Je n'ai jamais dit ça ...
                                            Ben tu repetes pourtant a qui veut l'entendre qu'on est trop con de vouloir des apostrophes et des guillements dans les noms de fichiers, que le shell est tres bien comme il est et qu'on a qu'a faire autrement, non mais.

                                            Affirmation ridicule : le shell permet de le gérer.

                                            Ah?
                                            tiens donc?

                                            Ecrit moi un script shell, qui tourne sous bsd et linux, qui par exemple, touch tous les fichiers d'un repertoire donne.
                                            Cela doit marcher avec, par exemple, le repertoire toto contenant:

                                            rush-vacances-1.avi
                                            L'armee des 12 singes.avi
                                            Montage vacances (Version "finale").avi
                                            • [^] # Re: C'est du poulet !

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

                                              Ecrit moi un script shell, qui tourne sous bsd et linux, qui par exemple, touch tous les fichiers d'un repertoire donne.

                                              Sous FreeBSD, on fait :

                                              $ find . -name "*.avi" -exec touch {} \;

                                              $ ls -l *avi
                                              -rw-r--r-- 1 thierry wheel 0 25 jul 00:10 L'armee des 12 singes.avi
                                              -rw-r--r-- 1 thierry wheel 0 25 jul 00:10 Montage vacances (Version "finale").avi
                                              -rw-r--r-- 1 thierry wheel 0 25 jul 00:10 rush-vacances-1.avi

                                              C'était sous un zsh. Maintenant je passe en émulation Linux :

                                              $ /usr/compat/linux/bin/sh
                                              sh-3.00$ find . -name "*.avi" -exec touch {} \;
                                              sh-3.00$ ls -l *avi
                                              -rw-r--r-- 1 thierry wheel 0 Jul 25 00:11 L'armee des 12 singes.avi
                                              -rw-r--r-- 1 thierry wheel 0 Jul 25 00:11 Montage vacances (Version "finale").avi
                                              -rw-r--r-- 1 thierry wheel 0 Jul 25 00:11 rush-vacances-1.avi

                                              Là, c'était un bash.
                                              • [^] # Re: C'est du poulet !

                                                Posté par  . Évalué à 0.

                                                ok, ok, je vais preciser ma pensee alors, vu que certains petits malins trouvent un workaround bancal.
                                                Ca, c'est pas un script shell, c'est une grosse commande find.

                                                Executer 2 commandes a l'affilee sur les fichiers d'un repertoire+sous reps, sans pour autant scanner le tout 2 fois.
                                                • [^] # Re: C'est du poulet !

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

                                                  Un simple : for i in *; do touch "$i";done ne fonctionne-t-il pas ?
                                                  • [^] # Re: C'est du poulet !

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

                                                    Si, ça marche aussi, bien sûr.
                                                  • [^] # Re: C'est du poulet !

                                                    Posté par  . Évalué à 0.

                                                    ca a l'air mais j'ai un effet de bord tres interessant:
                                                    bla:test blou$ ls
                                                    "toto.txt
                                                    bla:test blou$ for i in *.bmp; do touch "$i";done
                                                    bla:test blou$ ls
                                                    "toto.txt *.bmp
                                                    • [^] # Re: C'est du poulet !

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

                                                      Ah oui, tiens, c'est un bug de bash  !

                                                      Zsh ne fait rien, il dit juste :

                                                      zsh: no matches found: *.bmp
                                                    • [^] # Re: C'est du poulet !

                                                      Posté par  . Évalué à 1.

                                                      Si aucun glob , ne correspond il considère que c'est une entrée texte,
                                                      comme quand tu écris for x in a b c d (ou for x in '*.bmp' si c'est plus clair comme ça).

                                                      De l'art de critiquer ce que l'on ne comprend ni ne connait...
                                                      • [^] # Re: C'est du poulet !

                                                        Posté par  . Évalué à 2.

                                                        J'avoue que c'est plus compliqué de prendre le shell en défaut que je le pensais, quand les variables sont quotées ça passe. (J'ai pas été jouer avec les "eval", c'est tricher)

                                                        On doit pouvoir faire des trucs avec le globbing par contre. Genre avec cette histoire la, t'as pas vraiment de moyen de savoir si le pattern "*.bmp" a été retourné parce que t'avais effectivement un match '*.bmp' ou si t'en avais pas ...


                                                        Avec le globbing :
                                                        TEST=*
                                                        ls $TEST

                                                        Il faut savoir que le globbing n'est pas fait à l'affectation de la variable, pour une raison que j'ignore. Il est fait uniquement sur le "ls", un petit "set -x" est très instructif pour savoir ce qui se passe.
                                                        • [^] # Re: C'est du poulet !

                                                          Posté par  . Évalué à 1.


                                                          Développement des chemins
                                                          Après le découpage en mots, à moins que l’option -f soit présente, bash recherche dans chaque mot les caractères *, ? et [. Si l’un d’eux apparaît, le mot est considéré comme un motif et remplacé par une liste, classée par ordre alphabétique, des noms de fichiers correspondant à ce motif. Si aucun nom de fichier ne correspond et si l’option d’interpréteur nullglob est désactivée,le mot reste inchangé.

                                                          (man bash)

                                                          Ce comportement est là depuis /bin/sh. zsh n'a pas pour objectif d'être rétro-compatible, c'est normal qu'il ne l'ai pas (ce doit être modifiable).

                                                          for x in $( ls -1 $glob ); au pire...
                                                          • [^] # Re: C'est du poulet !

                                                            Posté par  . Évalué à 2.

                                                            Ouch, tu tresses les cordes pour te faire battre la. C'est le genre d'exemple que je cherchais.

                                                            le "for x in $( ls -1 $glob );" il marche pas si t'as des caractères de l'IFS dans ton nom de fichier. Et tu peux pas t'en sortir avec des quotes dans ce cas, donc il faut utiliser l'option de ls qui t'échappe automatiquement ou autre bidouille bien crade :)
                                                            • [^] # Re: C'est du poulet !

                                                              Posté par  . Évalué à 2.

                                                              meuh c'est juste qu'il ne sait pas le while read a
                                                              ls -1 | while read fich
                                                              do
                                                              touch "$fich"
                                                              done

                                                              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                                              • [^] # Re: C'est du poulet !

                                                                Posté par  . Évalué à 1.

                                                                Exact, ça, ça marche :) Et c'est bien pratique le "while read" pour lire un fichier ligne à ligne en shell, quasi indispensable même.

                                                                Bon après ça en reste pas moins une bonne démo que la programmation shell, c'est vachement plus compliqué et piégeux que ça pourrait l'être, ce qui était mon point de départ.
                                                                • [^] # Re: C'est du poulet !

                                                                  Posté par  . Évalué à 3.

                                                                  Ce n'était pas exactement le point de départ .... Le point de départ était que le shell n'est pas capable de gérer ces cas de figure. Il l'est, modulo quelques astuces. Maintenant c'est vrai que ces astuces ne sont pas triviales, mais elles existent. Personnellement je n'ai jamais été pris à défaut sur les nom de fichiers .... Quoique, je me souviens avoir eu des problèmes avec des fichiers contenant un "-" entre deux espaces, ou commencant par un "-" ....
                                                            • [^] # Re: C'est du poulet !

                                                              Posté par  . Évalué à 1.

                                                              Sur mon zsh, il suffit de faire
                                                              for x in "$( ls -1 $glob )"

                                                              Après essai, ça fonctionne effectivement pas sous bash. Je commence à entrevoir la douleur quotidienne des utilisateurs de ce shell :). Personnellement, je n’ai jamais eu de pb avec les caractères spéciaux dans les noms de fichiers, et j’utilise le shell tous les jours. Le seul problème sont les fichiers qui commencent par un tiret, mais ça c’est pas la faute du shell.
                              • [^] # Re: C'est du poulet !

                                Posté par  . Évalué à 6.

                                un ls particulier qui te retourne un nom de fichier echappe par exemple, ca serait deja tres bien

                                Un truc du genre
                                ls --quoting-style=shell

                                « 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: C'est du poulet !

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

                                  Alors là, génial, je ne connaissais pas.

                                  Find, grep font pareil ?
                                  • [^] # Re: C'est du poulet !

                                    Posté par  . Évalué à 2.

                                    Aucune idée, regarde dans la manpage.

                                    « 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

                                  • [^] # Commentaire supprimé

                                    Posté par  . Évalué à 3.

                                    Ce commentaire a été supprimé par l’équipe de modération.

                                • [^] # Re: C'est du poulet !

                                  Posté par  . Évalué à 1.

                                  ca ne resoud qu'une partie du probleme, meme si c'est une grosse partie du pb...
                                  • [^] # Re: C'est du poulet !

                                    Posté par  . Évalué à 2.

                                    Il manque quoi de résolu au problème du ls?

                                    « 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: C'est du poulet !

                                      Posté par  . Évalué à 1.

                                      ben ca n'echappe que les fichiers recuperes via ls...

                                      un nom de fichier entre par l'utilisateur, lu dans un fichier de config plain text, retourner par une autre commande ne sera pas echappe...
                                    • [^] # Re: C'est du poulet !

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

                                      Il manque quoi de résolu au problème du ls?

                                      L'option --quoting-style est spécifique au ls des GNU Coreutils. Elle ne fonctionne pas avec le ls des BSD* par exemple. Donc cette solution n'est pas portable.
                                      • [^] # Re: C'est du poulet !

                                        Posté par  . Évalué à 2.

                                        Et il n'y a pas de commande équivalente? Sinon, c'est dommage car ça peut être bien pratique.

                                        « 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: C'est du poulet !

                                Posté par  . Évalué à 4.

                                La philosophie d'Unix n'est _pas_ de gérer les cas exotiques, surtout lorsqu'une telle gestion remettrait en cause le fonctionnement d'outils ayant des dizaines d'années, aurait une plus value négligeable, et représenterait une charge de travail gigantesque pour couvrir tous les cas exotiques correctement sans introduire des régressions inadmissibles.
                                • [^] # Re: C'est du poulet !

                                  Posté par  . Évalué à 2.

                                  1) Je vois pas en quoi les ( )[]{}"'#+= sont exotiques dans les noms de fichier.
                                  Il est bien fait la différence dans le journal entre les sources de programmes et les autres fichiers. Autant pour mes sources j'utilise les _ les minuscules et pas de ( )[]{}"'#+= autant dans mes documents (bureautique moultimédia...) c'est le contraire. Bien sûr que je fais pas ex^près de mettre des "" mais je veux que ce soit possible. Cela n'est pas exotique.

                                  2) La philosophie d'Unix... Mouaah ah ahah ! Quelle grandiloquence pour un si petit sujet. Je te rappel qu'il s'agit de pouvoir utiliser les caractères du clavier (de n'importe quel clavier).

                                  3) ayant des dizaines d'années ça ne veut pas dire qu'il faut les changer, ça ne veut pas non plus dire qu'il faut les garder éternellement. Si le créateur de TBuild recent un besoin de nouveauté, cela me parait philosophiquement très linux de créer son propre bazar.

                                  J'ajouterai que j'ai vu passé plein de langage ou ces problèmes de caractères à la con n'apparaissait que pas ou peu (juste le \" à gérer) cette demande (de facilité) n'a donc rien d'exotique.
                                  • [^] # Re: C'est du poulet !

                                    Posté par  . Évalué à 2.

                                    J'ajouterai que j'ai vu passé plein de langage ou ces problèmes de caractères à la con n'apparaissait que pas ou peu (juste le \" à gérer)

                                    Ce n'est pas parce que certains langages sont faible :P qu'ils faut les généraliser.
                                    En fait tu te heurte à l'interprétation d'une ligne de commande/script. Dans un langage de programmation traditionnel tu n'auras pas à te poser la question si machin $truc bidule() est une fonction ou non.
                                    Dans un script/shell la distinction n'est pas simple.

                                    quand je fais un
                                    for i in */*
                                    do
                                    mv "$i" "$( find /mnt/bakaouilu/fionne -iname $( echo $i | cut -d'_' -f 1)) $( basename $a | cut -d'_' -f2 ).jpg"
                                    done
                                    et encore je n'ai pas utilisé les `` ou $(( ou [] ou [[ (bien que [ n'est qu'une commande toute simple )
                                    tout ces soucis viennent de la puissance et la souplesse du shell.
                                    Le soucis vient de l'interprétation de la ligne de commande; si tu n'en veux pas il faut alors passer par ' et dans ce cas tu peux tout avoir (sauf ') et dans ce cas l'écriture deviens plus complexe (en gros fins de ') guillemet quote guillemet
                                    echo 'ab$@[]$^a'"'"'b$@[]$^a'

                                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                                    • [^] # Re: C'est du poulet !

                                      Posté par  . Évalué à 1.

                                      Dans un langage de programmation traditionnel
                                      Dans un script/shell la distinction n'est pas simple
                                      <humour>
                                      Tu vois, tu vois, tu vois, tu vois !
                                      Toi aussi tu dis que le shell c'est pas traditionnel (donc pas normal) et compliqué.
                                      </humour>
                                  • [^] # Re: C'est du poulet !

                                    Posté par  . Évalué à 0.

                                    1) Par ce que le shell fait partit intégrante d'Unix de la norme POSIX et qu'utiliser de tel fichiers avec c'est "painfull" ? Par ce qu'il faut les échaper ?

                                    2 & 3) Si Unix, sa philosophie et son héritage ne te plaises pas, utilises win32 ou écris ton propre OS et son propre standard. éxactement comme les accents dans les noms de domaines, encore une fois.

                                    Je ne comprends même pas en quoi il y a besoin d'argumenter: bientôt tu vas nous sortir que de ton point de vue d'utilisateur il faudrait pouvoir mettre des noms de fichiers de 1Mo et que le système est débile de ne pas le permettre ?
                                    • [^] # Re: C'est du poulet !

                                      Posté par  . Évalué à 1.

                                      C'est inadmissible. Je ne peux pas planter de clous avec un tournevis. Je ne comprend pas qu'on impose des limites à l'utilisateur. Ce n'est pas à l'utilisateur de s'adapter à l'outil mais l'outil qui doit s'adapter à l'utilisateur ... Non franchement c'est inadmissible.
                          • [^] # Re: C'est du poulet !

                            Posté par  . Évalué à 2.

                            Je ne comprend pas trop le sens de ton argument ....

                            c'est à l'outil d'être adapté à ce qu'on veux faire
                            Je veux planter un clou -> j'utilise un marteau, pas un tournevis ni une scie sauteuse.

                            pas adapté ce qu'on veut faire à ce que permet l'outil.
                            Ben si quand même .... Si j'ai un marteau sous la main, j'utilise des clous, pas des vis. Si j'ai un tournevis j'utilise des vis, pas des clous ....

                            Pour moi, vouloir mettre des guillemets ou des parenthèses dans un nom de fichier, c'est simplement mal utiliser l'outil. Bien souvent le problème est résolu en se passant de parenthèses ou de guillements et en ajoutant un niveau d'arborescence supplémentaire ...

                            Pour moi les noms de fichiers/répertoire c'est comme les classeurs, les armoires et les tiroirs ... En général une armoire est destinée à stocker des dossiers d'un certain type (par exemple l'armoire censée stocker les employés d'une boite). Si la boite a une grande armoire et veut stocker les employés et les dossiers d'assurance dans la même armoire, elle le fera dans des tiroirs différents. Et les tiroirs seront divisés en dossier qui contiennent les informations sur les employés. J'imagine mal la secrétaire se plaindre qu'elle ne trouve pas l'age de l'employé Toto rien qu'en regardant le dossier, ou simplement le tiroir. De même je vois mal un grand tiroitr avec plein de dossiers dedans (assurance, employés, licences logicielles), différenciés uniquement par le nom du dossier le conenant .....

                            Les nom de fichiers ou répertoires, pour moi c'est la même chosen on peut pas tout mettre dedans ...
                            • [^] # Re: C'est du poulet !

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

                              Les caractères en questions sont autorisés dans un nom de fichier, et certains y trouve un intérêt. Il ne s'agit pas de mettre tout le document dans le titre, ou du gras ou que sais-je : ce genre de chose n'est pas possible.

                              Là on en fait trop ou pas assez, soit le système ne doit pas gérer autre chose que les caractères alphanumérique, soit il gère tous les caractères possible correctement avec un mécanisme pour les caractères spéciaux.
                              • [^] # Re: C'est du poulet !

                                Posté par  . Évalué à 2.

                                Le mécanisme pour les caractères spéciaux, c'est '\' Et le fait que certains caractères soint interdits dans un nom de fichier ne me choque pas du tout, tout comme il existe des mots réservés dans les langages de programmation ...

                                Sinon, les FS windows c'est de la merde aussi, je peux pas créer un répertoire c: sur mon disque dur (eh oui, les caractères \ / * : " ?<> | sont interdits dans les noms de fichiers sous windows ...).
                                • [^] # Re: C'est du poulet !

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

                                  C'est bien ce que je dit : Là on en fait trop ou pas assez, soit le système ne doit pas gérer autre chose que les caractères alphanumérique, soit il gère tous les caractères possible correctement avec un mécanisme pour les caractères spéciaux.

                                  Donc il n'y a pas de caractère interdit, je peux parfaitement mettre un guillemet simple, le système me le permette.
                    • [^] # Re: C'est du poulet !

                      Posté par  . Évalué à -1.

                      gne?
                      L'espace et les guillemets, c'est pas "standard"?

                      Si c'est pas un bel exemple de "l'homme s'adapte a l'informatique et pas le contraire", je sais pas ce que c'est....

                      Le fond du pb ici, c'est que le shell est con comme ses pieds, et on a un tres bel exemple de pourquoi un shell objet serait bien plus adapte, plutot que de s'emboucanner a faire des pirouettes dans tous les sens pour s'assurer que le nom de fichier ne soit pas massacre a la tronconneuse.

                      Pour revenir dans le sujet, Mildred, as tu envisage/regarde ce que ant permet?
                      Je sais qu'il est concu pour du java a la base, mais je sais aussi de source sur qu'il existe des tasks ecrites specifiquement pour compiler du c/c++ (tres probablement via gcc).

                      Et pour l'avoir pas mal utilise, on peut faire pas mal de trucs avec (fetch du SVN, compilation conditionnelle en fonction de la plateforme, du packaging a la volee relativement intelligent en fonction de divers parametres d'input, deployements, tests unitaires et tout le tralala habituel)

                      Tu n'as certes pas de "langage shell" a proprement parler, mais le tasks de bases te permettent de faire pas mal de choses de base et pour des cas reellement particulier, tu peux toujours t'ecrire ta propre task ant (c'est pas chiant a faire, sous reserve qu'il faut pas en ecrire 40).

                      C'est une philosphie d'ecriture assez particuliere (ie pas forcement au gout de tout le monde), mais ca marche plutot pas mal, puissant et efficace.
                      • [^] # Re: C'est du poulet !

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

                        ant, c'est une possibilité ...

                        seulement, je souhaitais le plus possible avoir une syntaxe pratique et facile, et pour moi, XML ne correspond pas vraiment.
                  • [^] # Re: C'est du poulet !

                    Posté par  . Évalué à 3.

                    Le shelle échappe tout ce qui gène quand tu mets entre quote/double quote (le deuxième autorisant l'expansion des variables/expressions).
                  • [^] # Re: C'est du poulet !

                    Posté par  . Évalué à 0.

                    Faut quand même être complêtement atteint pour mettre des guillemets dans les noms de fichier ... Et pourquoi pas des slash aussi ?
                    • [^] # Re: C'est du poulet !

                      Posté par  . Évalué à 3.

                      Oui, ça fonctionne tellement bien avec 8 caractères en majuscules pour le nom et 3 pour l'extension.

                      The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

              • [^] # Re: C'est du poulet !

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

                >Et si le mot contient des guillemets tu fais comment ?

                Brise les genoux de ceux qui osent faire ça, et fait en sorte d'être célébré et imité. Avec le temps, le problème devrait disparaître de lui même.

                Adhérer à l'April, ça vous tente ?

      • [^] # Re: C'est du poulet !

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

        Bah je cherchais vraiment pas à être agressif. J'ai du lire l'article un peu trop en diagonale.

        Bon, moi j'ai jamais eu de problème de guillemets, mais si y en a qui ont l'utilité, effectivement…
  • # ant et le reste

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

    ne pas oublier ce qui vient du monde java / ruby aussi, genre capistrano et surtout gradle !

    groovy rulez
  • # make rudimentaire?

    Posté par  . Évalué à 3.

    Il est beaucoup de chose mais rudimentaire surement pas.

    Pour la détection de plateforme les ifeq(,) suffisent amplement.
    Ensuite avec sa palanqué de règle par défaut tu peux en faire des trucs.

    Par contre il est vrai et je le reconnais qu'il est loin d'être simple à utiliser.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Mouai...

    Posté par  . Évalué à 4.

    il est trop lié à la plateforme cible (on écrit des lignes de commande shell, et le shell, ça change pas mal selon la plateforme

    PEBCAK, rien ne t'empeche d'écrire des scripts shell portables.

    Idem pour ton histoire de guillemets (voir plus bas), et les options de compilations (if then if then...)
    • [^] # Re: Mouai...

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

      J'ai la prétention de vouloir faire des applications portables même sous Windows ou d'autres OS non unix, même si je ne les utilise pas.

      J'ai eu la malchance de devoir développer sous Windows dernièrement (ça faisait des années que je n'avais pas touché à Windows) et je dois dire que même si mingw, msys, cygwin et coLinux ont bien été pratiques, je pense que j'aurais préféré avoir des applications natives.

      Antre autre: git-svn n'arrêtait pas de planter, même avec coLinux.

      Sans compter qu'il y a d'autres OS non unix libres dans la nature (par exemple IsaacOS, pour ceux qui suivent un peu de près le langage Lisaac dans lequel je me suis fortement investie).
  • # Réponses

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

    Sinon, j'aimerais revenir un peu sur les derniers commentaires. La solution de mettre des simple quotes autour des noms de fichiers serait une solution si les quotes n'étaient pas autorisées dans les noms de fichiers en eux même (au même titre que '/' ou que le caractère NULL). Mais je serais bien embêtée (par exemple pour écrire mon pseudo: Mildred Ki'Lya, même si on peut contourner avec un caractère unicode comme ’).

    Ce que j'aime bien, c'est avoir un sysème robuste. Avoir un système qui peut avoir des comportements erratiques (une commande qui n'est pas exécutée comme prévu, ça peut parfois faire des gros dégats) ne me convient pas.

    J'avais aussi dans l'idée que TBuild pouvait être sécurisé. je vois mal comment on peut sécuriser la chose si il suffit de mettre un nom de fichier «'; rm -rf /; echo '» pour finalement avoir une commande qui ressemble à:

    gcc -o executable -c ''; rm -rf /; echo ''

    Ça ne me paraît pas très sécurisé.


    Dernière chose: je ne considère pas le shell inadapté, je l'utilise tous les jours. Je considère juste que du code shell généré pas forcément proprement n'est pas une bonne idée.
    • [^] # Re: Réponses

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

      Tu peux échapper les caractères spéciaux avec un filtre :

      psy@tarasque:/tmp% ls *.ex
      a ()'".ex
      psy@tarasque:/tmp% ls *.ex|./escape.pl
      a\ \(\)\'\".ex
      psy@tarasque:/tmp% ls *.ex|./escape.pl|xargs cat
      Tada !


      Si tu as plusieurs variable, typiquement ta cible et ta destination, tu peux les échapper toutes les deux :

      cible=$(echo $@|escape)
      source=$(echo $+|escape)
      echo $cible $source | xargs $(GENPDF) -o


      Une ébauche de code pour escape.pl : https://linuxfr.org/~psychoslave__/28584.html
      • [^] # Re: Réponses

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

        Certes, c'est une possibilité, mais je préfère découper mes mots avant de les donner à exec, surtout qu'on est jamais vraiment sûr de ce que va être /bin/sh et comment il réagit vraiment.

Suivre le flux des commentaires

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