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.inLe 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 Ririsoft . Évalué à 2.
Qu'est-ce qui ne te plait pas chez eux ?
http://www.cmake.org/
http://www.scons.org/
[^] # Re: cmake, scons ?
Posté par Ph Husson (site web personnel) . Évalué à 1.
Sinon pour scons, il devrait effectivement pouvoir répondre au problème.
[^] # Re: cmake, scons ?
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: cmake, scons ?
Posté par calandoa . Évalué à 2.
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 Mildred (site web personnel) . Évalué à 1.
[^] # Re: cmake, scons ?
Posté par karteum59 . Évalué à 1.
[^] # Re: cmake, scons ?
Posté par Mildred (site web personnel) . Évalué à 1.
# Et les guillemets ?
Posté par psychoslave__ (site web personnel) . Évalué à 5.
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 blobmaster . Évalué à 6.
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.ingenpdf -o mon joli document.pdf "ma jolie source.in"
[^] # Re: C'est du poulet !
Posté par blobmaster . Évalué à 2.
genpdf -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.
Ce qui est entre les quotes est considéré comme un seul mot.
[^] # Re: C'est du poulet !
Posté par blobmaster . Évalué à 1.
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 fearan . Évalué à 5.
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 blobmaster . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 4.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: C'est du poulet !
Posté par fearan . Évalué à 5.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: C'est du poulet !
Posté par fearan . Évalué à 3.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est du poulet !
Posté par B16F4RV4RD1N . Évalué à 3.
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 blobmaster . Évalué à 3.
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 geb . Évalué à 0.
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 psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: C'est du poulet !
Posté par geb . Évalué à 1.
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 thedude . Évalué à 4.
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 B16F4RV4RD1N . Évalué à 4.
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 thedude . Évalué à 1.
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 B16F4RV4RD1N . Évalué à 1.
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 thedude . Évalué à -1.
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 totof2000 . Évalué à 3.
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 psychoslave__ (site web personnel) . Évalué à 3.
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 thedude . Évalué à 2.
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 totof2000 . Évalué à 1.
[^] # Re: C'est du poulet !
Posté par Thomas Douillard . Évalué à 1.
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 totof2000 . Évalué à 2.
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 Thomas Douillard . Évalué à 3.
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 thedude . Évalué à 2.
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 totof2000 . Évalué à 3.
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 thedude . Évalué à 1.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
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 thedude . Évalué à 0.
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 psychoslave__ (site web personnel) . Évalué à 3.
for i in *; do touch "$i";donene fonctionne-t-il pas ?[^] # Re: C'est du poulet !
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: C'est du poulet !
Posté par thedude . Évalué à 0.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
Zsh ne fait rien, il dit juste :
zsh: no matches found: *.bmp
[^] # Re: C'est du poulet !
Posté par geb . Évalué à 1.
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 Thomas Douillard . Évalué à 2.
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 geb . É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 Thomas Douillard . Évalué à 2.
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 fearan . Évalué à 2.
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 Thomas Douillard . Évalué à 1.
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 totof2000 . Évalué à 3.
[^] # Re: C'est du poulet !
Posté par Moonz . Évalué à 1.
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 claudex . Évalué à 6.
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 Sytoka Modon (site web personnel) . Évalué à 2.
Find, grep font pareil ?
[^] # Re: C'est du poulet !
Posté par claudex . Évalué à 2.
« 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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est du poulet !
Posté par thedude . Évalué à 1.
[^] # Re: C'est du poulet !
Posté par claudex . Évalué à 2.
« 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 thedude . Évalué à 1.
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 Jérôme Pinot (site web personnel) . Évalué à 1.
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 claudex . Évalué à 2.
« 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 Guillaume Knispel . Évalué à 4.
[^] # Re: C'est du poulet !
Posté par blobmaster . Évalué à 2.
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 fearan . Évalué à 2.
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 blobmaster . Évalué à 1.
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 geb . Évalué à 0.
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 totof2000 . Évalué à 1.
[^] # Re: C'est du poulet !
Posté par totof2000 . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 2.
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 totof2000 . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 3.
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 thedude . Évalué à -1.
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 Mildred (site web personnel) . Évalué à 1.
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 benoar . Évalué à 3.
[^] # Re: C'est du poulet !
Posté par totof2000 . Évalué à 0.
[^] # Re: C'est du poulet !
Posté par téthis . Évalué à 3.
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 Pol' uX (site web personnel) . Évalué à 2.
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 psychoslave__ (site web personnel) . Évalué à 3.
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 Bruno Bonfils (site web personnel) . Évalué à 1.
groovy rulez
[^] # Re: ant et le reste
Posté par Victor . Évalué à 1.
[^] # Re: ant et le reste
Posté par Ghis . Évalué à 1.
D'ailleurs Rake vaux quoi par rapport au commentaire du journal ?
# make rudimentaire?
Posté par fearan . Évalué à 3.
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 geb . Évalué à 4.
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 Mildred (site web personnel) . Évalué à 1.
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).
[^] # Re: Mouai...
Posté par geb . Évalué à 2.
[^] # Re: Mouai...
Posté par Mildred (site web personnel) . Évalué à 0.
[^] # Re: Mouai...
Posté par geb . Évalué à 2.
Pour info (Quand tu auras été voir) http://www.netbsd.org/docs/software/packages.html#platforms
# Réponses
Posté par Mildred (site web personnel) . Évalué à 1.
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 psychoslave__ (site web personnel) . Évalué à 2.
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 Mildred (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.