je pense qu'il y a consensus pour conclure qu'en analyse statique, c'est très ardu (voire impossible).
pour avoir une chance d'être exhaustif en dynamique, comme le dit Barret Michel, ça suppose d'avoir des tests ayant la plus large couverture possible.
si je devais lister toutes les commandes externes d'un script, je monterais un environnement chrooté avec simplement un bash, et je compléterais cet environnement à mesure que je rencontrerais des "command not found".
Ensuite, dans une perspective à long terme, tous les nouveaux scripts devraient être validés dans cet environnement avant le déploiement.
Pour peu que tu fasses quelques efforts pendant quelques semaines (ou quelques mois), tu peux taper sans regarder ton clavier. Dans ces conditions, les gribouillis sur les capots des touches n'ont plus beaucoup d'importance.
pff, pourtant pas difficile de faire des phrases sans accent ! :D
je trolle sur des sujets que je ne lis pas :p
c'est un peu le principe, non ? :)
cela dit, mon commentaire n'était pas complètement pertinent non plus semble-t-il
mais quel générateur maison ?
un outil complément interne. Il s'agit d'un script en python qui gère les dépendances entre modules (avec une vérification sommaire de la compatibilité des versions des différents modules). Les makefile générés par ce script stockent les produits de la compilation dans des sous répertoires spécifiques à chaque architecture (pour éviter d'avoir à tout recompiler à chaque fois qu'on change de cible). Et ça, c'est quand même intéressant vu qu'on compile sur HP-UX sur Itanium (et autre chose, mais je ne sais plus quoi), Solaris 9 sur sparc, solaris 10 sur sparc/x86, Linux sur x86 et quelques vieilleries sur AIX.
Cela dit, comme tout outil développé en interne et peu maintenu, il amène son lot de contraintes :)
Mon problème de perf venait du fait que pour chaque sous répertoire de niveau n, make était lancé n-1 fois. Évidemment, n-2 fois, il ne faisait pas grand chose ... à part recopîer tous les produits utiles de la compilations dans le sous répertoire de l'architecture du moment ... arg ! :D
L'exemple que je donne ne portait pas sur les makefile récursifs (vu qu'ils le sont toujours), mais sur ton affirmation selon laquelle l'augmentation des perfs des machines permettrait de s'abstenir de se pencher sur les perfs de sa chaine de compil.
C'est parfois vrai, parfois pas :)
l'augmentation des performances du hardware, c'est souvent utilisé comme prétexte pour gérer les ressources n'importe comment ...
sur un projet ici, en dehors de pondre des makefile récursifs, le générateur maison de makefile était un peu trop frileux et recompilait pleins de répertoires pour rien.
Et ben mine de rien, gagner 20 minutes sur une compile de 40, c'est pas mal.
Comme je le précisais dans mon commentaire précédent, c'est intéressant de se pencher sur la question pour les gros projets avec une arborescence conséquente.
Sur les petits projets, l'intérêt est effectivement très faible.
Conclusion, le soft est parfait, c'est les utilisateurs qui ont des problemes.
revois tes cours de logique, parce que là, j'ai du mal à voir comment tes affirmations de départ (qui sont à mon avis fausses mais bon) amènent à ta conclusion.
Re rappelons (comme ça l'a été dans d'autres messages) que les gens qui répondent dans les forums sont la plupart du temps bénévoles. Leur temps n'a pas moins de valeur que le temps de celui qui pose la question.
Il est rare qu'une question bien posée ne suscite aucune réponse utile.
Par exemple, un commerciaux qui fait des macros VBA est au moins autant un informaticien qu'un ingénieur/universitaire qui a fait des études spécialisées sur la question.
si on te comprend bien, faire des études d'histoire, c'est se disqualifier en tant qu'historien ...
reste à vérifier si les situations sont comparables. Dans le temps, l'inflation législative était moins prononcée et les gouvernements n'avaient pas systématiquement recours à la procédure d'urgence (qui n'existait peut-être même pas pour ce que j'en sais).
Ca serait intéressant de refaire l'historique de cette loi et de revoir les arguments qui avaient été soulevés à l'époque, et comment ses partisans avaient répondu à la critique. J'imagine que les aspects liberté d'expression, principe vs cas particuliers, etc avaient été évoqués. Mais bon, là, je suis un peu au boulot donc ça sera pas tout de suite (si tant est que ça soit un jour parce que ça peut être un peu long et je peux me lasser avant même de commencer :D )
Enfin bon, sur le fond, je pense comme nicolas qu'il n'y a pas d'absolu possible. La liberté d'expression totale est un idéal, et comme tout idéal, inatteignable. L'intérêt de la question réside dans le fait de savoir ou en met le curseur. Si tu penses que tout entrave à la liberté d'expression est une hérésie (je ne dis pas que c'est le cas, j'avoue que je m'y perds un peu entre toutes les intervenants sur le sujet), on est sur des prémisses complètement irréconciliables.
relis mon commentaire. Je ne donne absolument pas mon avis sur la question, je me contente de dire que c'est pas la peine d'invoquer des trucs aussi abstraits que le rapport concepts/langage pour ce sujet.
La question de la justice, sur le plan technique, ne se discute pas non plus. Par définition (et tant qu'il n'y a pas un appel rendu en sens inverse ou que le jugement n'est pas cassé), la décision de mettre ce monsieur en prison est juste.
Quant à savoir si c'est juste (au sens moral) ou pas, ça pourrait éventuellement se discuter, mais pas ici, y a trop de gens qui "savent" ce qu'il faut penser (et c'est bien possible que j'en fasse partie en plus ;-)
Classez moi parmi les affreux censeurs si ça vous chante, mais il y a d'autres lois passées en urgence sur le coup de l'actualité qui m'embêtent infiniment plus que celle là.
Rien ne t'interdit de dire des conneries chez toi. Par contre, dire ce type de conneries en publique est interdit. C'est pas plus compliqué que ça. Pas la peine d'invoquer l'anthropologie pour ça ...
En ce qui concerne NTFS, en particulier, tu pourras la lire sans problème, mais pour ainsi dire pas écrire dessus.
C'était vrai avant.
C'est toujours vrai si tu utilises l'implémentation du NTFS dans le noyau, mais il y a une implémentation utilisant FUSE qui fonctionne très bien.
En Debian, le package s'appelle ntfsprogs
Traduction pour Potage : c'est un tout petit peu moins immédiat pour écrire dans du NTFS, mais ça se fait.
"qui *commencent* en SSII" serait plus correct, et puis, il n'y a pas de honte hein.
J'ai commencé par 7 ans en SSII. Autant c'est des maichant exploitateurs, autant ça a certains avantages (beaucoup de distance par rapport à la petite politique de chefaillons chez le client, pas d'impact de la politique interne de la SSII dont tu n'entends quasiment pas parler, une porte de sortie le jour ou ça part en vrille chez le client, l'opportunité de goûter plusieurs cultures d'entreprise sans passer par le retour sur le marché de l'emploi).
Tu me diras, je suis peut-être un gros manche en info en fait.
# chroot + exécution
Posté par gaaaaaAab . En réponse au message Lister les commandes appelées par un script. Évalué à 3.
pour avoir une chance d'être exhaustif en dynamique, comme le dit Barret Michel, ça suppose d'avoir des tests ayant la plus large couverture possible.
si je devais lister toutes les commandes externes d'un script, je monterais un environnement chrooté avec simplement un bash, et je compléterais cet environnement à mesure que je rencontrerais des "command not found".
Ensuite, dans une perspective à long terme, tous les nouveaux scripts devraient être validés dans cet environnement avant le déploiement.
[^] # Re: Ca dépend du sujet...
Posté par gaaaaaAab . En réponse au journal Sacrés fournisseurs Internet.... Évalué à 10.
# ...
Posté par gaaaaaAab . En réponse au journal Prix Hugo et Folio SF. Évalué à 4.
ce qui n'enlève rien au fait que beaucoup de prix Hugo sont des très bon bouquins.
et aussi, merci pour l'info !
[^] # Re: make récursif = pas bien
Posté par gaaaaaAab . En réponse au message Makefile récursifs et variable. Évalué à 2.
pour une fois, je pensais plutôt aux développeurs qu'aux fondeurs/éditeurs d'OS :)
[^] # Re: requête
Posté par gaaaaaAab . En réponse au journal Il est bien ce gars la. Évalué à 5.
pff, pourtant pas difficile de faire des phrases sans accent ! :D
[^] # Re: make récursif = pas bien
Posté par gaaaaaAab . En réponse au message Makefile récursifs et variable. Évalué à 2.
c'est un peu le principe, non ? :)
cela dit, mon commentaire n'était pas complètement pertinent non plus semble-t-il
mais quel générateur maison ?
un outil complément interne. Il s'agit d'un script en python qui gère les dépendances entre modules (avec une vérification sommaire de la compatibilité des versions des différents modules). Les makefile générés par ce script stockent les produits de la compilation dans des sous répertoires spécifiques à chaque architecture (pour éviter d'avoir à tout recompiler à chaque fois qu'on change de cible). Et ça, c'est quand même intéressant vu qu'on compile sur HP-UX sur Itanium (et autre chose, mais je ne sais plus quoi), Solaris 9 sur sparc, solaris 10 sur sparc/x86, Linux sur x86 et quelques vieilleries sur AIX.
Cela dit, comme tout outil développé en interne et peu maintenu, il amène son lot de contraintes :)
Mon problème de perf venait du fait que pour chaque sous répertoire de niveau n, make était lancé n-1 fois. Évidemment, n-2 fois, il ne faisait pas grand chose ... à part recopîer tous les produits utiles de la compilations dans le sous répertoire de l'architecture du moment ... arg ! :D
L'exemple que je donne ne portait pas sur les makefile récursifs (vu qu'ils le sont toujours), mais sur ton affirmation selon laquelle l'augmentation des perfs des machines permettrait de s'abstenir de se pencher sur les perfs de sa chaine de compil.
C'est parfois vrai, parfois pas :)
[^] # Re: make récursif = pas bien
Posté par gaaaaaAab . En réponse au message Makefile récursifs et variable. Évalué à 2.
Je l'ai lu il y a lonnngtemps, et j'en avais principalement retenu la conclusion (éviter les make récursifs).
[^] # Re: make récursif = pas bien
Posté par gaaaaaAab . En réponse au message Makefile récursifs et variable. Évalué à 6.
sur un projet ici, en dehors de pondre des makefile récursifs, le générateur maison de makefile était un peu trop frileux et recompilait pleins de répertoires pour rien.
Et ben mine de rien, gagner 20 minutes sur une compile de 40, c'est pas mal.
Comme je le précisais dans mon commentaire précédent, c'est intéressant de se pencher sur la question pour les gros projets avec une arborescence conséquente.
Sur les petits projets, l'intérêt est effectivement très faible.
# make récursif = pas bien
Posté par gaaaaaAab . En réponse au message Makefile récursifs et variable. Évalué à 3.
http://miller.emu.id.au/pmiller/books/rmch/
pour les gros projets, les make récursifs coûtent très chers puisqu'ils faut forker un make pour chaque répertoire.
C'est en fait possible (et pas beaucoup plus compliqué) d'avoir une seul makefile pour les gouverner tous, et dans les ténèbres, les lier.
[^] # Re: Ce que je préfère
Posté par gaaaaaAab . En réponse au journal Humeur : Fuck The Fucking Manual/Web/ect.. Évalué à 3.
revois tes cours de logique, parce que là, j'ai du mal à voir comment tes affirmations de départ (qui sont à mon avis fausses mais bon) amènent à ta conclusion.
Re rappelons (comme ça l'a été dans d'autres messages) que les gens qui répondent dans les forums sont la plupart du temps bénévoles. Leur temps n'a pas moins de valeur que le temps de celui qui pose la question.
Il est rare qu'une question bien posée ne suscite aucune réponse utile.
[^] # Re: Vous cherchez à convaincre qui de passer à Linux?
Posté par gaaaaaAab . En réponse au journal Linux sur le desktop et 1% de part de marché : mythe ou réalité ?. Évalué à 2.
[^] # Re: wimp != crétin
Posté par gaaaaaAab . En réponse au message Linux Torvalds Quote. Évalué à 2.
allez, j'y vais de ma version :
les sauvegardes sur bandes, c'est pour les petits bras, les vrais mettent leur trucs importants sur FTP et laissent le reste du monde les dupliquer.
[^] # Re: Mais merde à la fin
Posté par gaaaaaAab . En réponse au journal Délit d'opinion : 1 an de prison ferme. Évalué à 5.
Par exemple, un commerciaux qui fait des macros VBA est au moins autant un informaticien qu'un ingénieur/universitaire qui a fait des études spécialisées sur la question.
si on te comprend bien, faire des études d'histoire, c'est se disqualifier en tant qu'historien ...
[^] # Re: Mais merde à la fin
Posté par gaaaaaAab . En réponse au journal Délit d'opinion : 1 an de prison ferme. Évalué à 2.
Ca serait intéressant de refaire l'historique de cette loi et de revoir les arguments qui avaient été soulevés à l'époque, et comment ses partisans avaient répondu à la critique. J'imagine que les aspects liberté d'expression, principe vs cas particuliers, etc avaient été évoqués. Mais bon, là, je suis un peu au boulot donc ça sera pas tout de suite (si tant est que ça soit un jour parce que ça peut être un peu long et je peux me lasser avant même de commencer :D )
Enfin bon, sur le fond, je pense comme nicolas qu'il n'y a pas d'absolu possible. La liberté d'expression totale est un idéal, et comme tout idéal, inatteignable. L'intérêt de la question réside dans le fait de savoir ou en met le curseur. Si tu penses que tout entrave à la liberté d'expression est une hérésie (je ne dis pas que c'est le cas, j'avoue que je m'y perds un peu entre toutes les intervenants sur le sujet), on est sur des prémisses complètement irréconciliables.
[^] # Re: Mais merde à la fin
Posté par gaaaaaAab . En réponse au journal Délit d'opinion : 1 an de prison ferme. Évalué à 2.
La question de la justice, sur le plan technique, ne se discute pas non plus. Par définition (et tant qu'il n'y a pas un appel rendu en sens inverse ou que le jugement n'est pas cassé), la décision de mettre ce monsieur en prison est juste.
Quant à savoir si c'est juste (au sens moral) ou pas, ça pourrait éventuellement se discuter, mais pas ici, y a trop de gens qui "savent" ce qu'il faut penser (et c'est bien possible que j'en fasse partie en plus ;-)
Classez moi parmi les affreux censeurs si ça vous chante, mais il y a d'autres lois passées en urgence sur le coup de l'actualité qui m'embêtent infiniment plus que celle là.
[^] # Re: Mais merde à la fin
Posté par gaaaaaAab . En réponse au journal Délit d'opinion : 1 an de prison ferme. Évalué à 2.
[^] # Re: Premiers pas
Posté par gaaaaaAab . En réponse au message [advanced-user@win] dernières questions avant passage sous linux. Évalué à 5.
C'était vrai avant.
C'est toujours vrai si tu utilises l'implémentation du NTFS dans le noyau, mais il y a une implémentation utilisant FUSE qui fonctionne très bien.
En Debian, le package s'appelle ntfsprogs
Traduction pour Potage : c'est un tout petit peu moins immédiat pour écrire dans du NTFS, mais ça se fait.
[^] # Re: Une bonne raison de NE PAS aller le voir.
Posté par gaaaaaAab . En réponse au journal Toy Story 3 : Pixar renvoie l'ascenseur à Debian. Évalué à 2.
[^] # Re: Tout de travers
Posté par gaaaaaAab . En réponse au journal Le point Q. Évalué à 2.
on est en 1431 de l'hégire :)
sinon, relis http://linuxfr.org/comments/1150589.html#1150589
[^] # Re: Mais ké kidi?
Posté par gaaaaaAab . En réponse au journal P != NP : la preuve. Évalué à 2.
-return n
+return [1, n]
certes, 1 n'est pas premier, mais ils divise quand même n.
[^] # Re: merci infiniment
Posté par gaaaaaAab . En réponse au message remmonter tous les mots contenant une lettre spécifique. Évalué à 2.
ça peut aussi se faire en awk:
echo "plop blabla" | awk '/a/{i=1; while (i <= NF) {if (index($i, "a") != 0) {print $i} i = i+1}}'
[^] # Re: dia
Posté par gaaaaaAab . En réponse au message Logiciel pour faire du Merise. Évalué à 2.
[^] # Re: Supair
Posté par gaaaaaAab . En réponse au journal Linux de moins en moins utilisé chez les étudiants de l'université Information Technology & Communication. Évalué à 3.
han !
j'aurais jamais tenu 7 ans si ça avait été du Java, la programmation en fichiers XML, ça va 5 minutes :D
[^] # Re: Les journaux ne sont pas tout
Posté par gaaaaaAab . En réponse au journal P != NP : la preuve. Évalué à 6.
The preliminary version made it to the web without my knowledge.
Il l'a envoyé à ses pairs pour relecture, pas pour diffusion publique.
[^] # Re: Supair
Posté par gaaaaaAab . En réponse au journal Linux de moins en moins utilisé chez les étudiants de l'université Information Technology & Communication. Évalué à 5.
"qui *commencent* en SSII" serait plus correct, et puis, il n'y a pas de honte hein.
J'ai commencé par 7 ans en SSII. Autant c'est des maichant exploitateurs, autant ça a certains avantages (beaucoup de distance par rapport à la petite politique de chefaillons chez le client, pas d'impact de la politique interne de la SSII dont tu n'entends quasiment pas parler, une porte de sortie le jour ou ça part en vrille chez le client, l'opportunité de goûter plusieurs cultures d'entreprise sans passer par le retour sur le marché de l'emploi).
Tu me diras, je suis peut-être un gros manche en info en fait.