gaaaaaAab a écrit 1387 commentaires

Je reprouve tous mes beaux commentaires en français

superbe lapsus ! =)

Je ne sais pas si ça répond à la question mais :

#!/bin/bash
set -e

IFS=':'
COWBUILDER_OPTS="--autocleanaptcache$IFS--debootstrap=cdebootstrap"
REQUESTED_DIST=lucid

case $REQUESTED_DIST in
    # universe is required for ubuntu
    hardy|jaunty|karmic|lucid|maverick)
        COWBUILDER_OPTS+="$IFS--components=\"main universe\""
        ;;
esac

for opt in $COWBUILDER_OPTS; do echo $opt; done
unset IFS

en ne restant qu'avec l'espace, je pense que ça va être compliqué quand même.

faut voir ...
on peut déjà faire pleins de trucs avec des perfs plus qu'acceptables avec sed

le UUOC, c'est aussi une histoire d'élégance, mais pas que !
Si ton script est destiné â être appelé très souvent, économiser le fork d'un cat, c'est bien
Quand tu fais un one-liner à usage unique en ligne de commande, c'est pas grave, évidemment, mais bon, c'est plus facile de laisser traîner un cat dans un script si on l'utilise libéralement dans un shell interactif, alors autant prendre des bonnes habitudes ;)

ok, rectifie moi si je me trompe, mais tu lances cette commande en tant que root ?

parce qu'effectivement, sur debian, même si bash-completion est installé, elle n'est pas chargée pour le compte root. Par contre, en tant qu'utilisateur sudoer, ça marche très bien.

$ sudo aptitude install command-no[tab]
$ sudo aptitude install command-not-found

je me demande depuis le premier commentaire de ce fil alors je demande :)
qu'est-ce que vous appelez la complétion sur les packages ?

J'ai été confronté à différents outils de conf en dépannant de temps en temps. Jusqu'à présent, je n'en ai pas vu qui me donnent plus envie de comprendre comment fonctionne l'outil plutôt que de comprendre ce qui se passe au niveau système. C'est même parfois un peu pénible quand on sait ce qu'il faut faire et qu'on galère à trouver l'option dans l'outil.

Comme je me débrouilles avec /etc/network/interfaces, je peux pas trop parler de NM, mais bon, l'argument "tu sais pas t'en servir parce que t'es hors du coup", c'est un peu naze.
Et puis, question de priorité. Il y a des technos récentes sur les quelles il est plus intéressant de se mettre à jour qu'une nième interface de gestion des interfaces réseaux, qui sera complètement refondue d'ici deux ans de toute façon.

il y a émondage aussi, qui est p-e meilleur qu'élagage, mais incontestablement moins compréhensible :)

concernant le retrait de fruits contaminés dans une grappe, ça ne me dit rien.

isolation m'était aussi venu à l'esprit, ça parait un peu faible par rapport à ce que c'est.
En revenant sur le sujet aujourd'hui, et dans l'idée du sécateur : élagage ?

presque pareil, mais plus joli (et avec moins de fautes) :
vim
enlightenment
python

Le shell est hors catégorie. Un shell sans l'écosystème des outils en ligne de commande, c'est moyen utile. Et distinguer une commande parmi d'autre, ça a peu de sens, vu que c'est l'ensemble des commandes dispo qui font la puissance du shell.
Bon, je ne résiste quand même pas, grep, find, sed, numéro complémentaire, xargs

oui, c'est vrai, mais la formulation outrancière de Moogle ne m'a pas incité à la nuance :)

et puis la vente à emporter est à 5,5 % depuis un sacré bout de temps

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.

c'est vrai que manger au restaurant, c'est carrément vital

meilleur roman anglophone de l'année en Science-Fiction

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 !

Intel et Windows

pour une fois, je pensais plutôt aux développeurs qu'aux fondeurs/éditeurs d'OS :)

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 :)

merci pour cette utile précision.
Je l'ai lu il y a lonnngtemps, et j'en avais principalement retenu la conclusion (éviter les make récursifs).

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.

du temps ou je faisais beaucoup de makefile, j'étais tombé là dessus :

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.

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.

* choisir comment les fenêtres prennent le focus

moi je mettrais les "petits bras".

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.

c'est clair, tu as tout à fait raison.

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.