j'avoue, c'était un peu du show off :)
En fait, je suis tombé sur ce raccourci un jour alors que je creusais un autre sujet. Je pensais même pas que ça passerait en fait, preuve que le langage est robuste et flexible.
Après, je suis d'accord, pour de la prod, il faut préférer la version explicite, plus maintenable à long terme
Est il autorisé d'éffacer un pointeur alloué ailleur ?
c'est autorisé, mais déconseillé.
La règle usuelle : c'est celui qui alloue qui désalloue
Confier l'allocation et la désallocation à des layers différents du code complique énormément la maintenance (et donc favorise les bugs).
Là, c'est à la lib de fournir les APIs qu'il faut pour (au choix):
- désallouer la mémoire allouée,
- laisser la charge de l'allocation/désallocation à l'appelant
//Do something correspond à copier le pointeur dans un container civilisé (un vecteur) qui lui même est propagé par référence dans tout le code.
possible que j'interprète mal, mais si tu copie des *pointeurs* dans ton vecteur, et que tu désalloues la mémoire pointée, forcément ...
Si c'était *vraiment* si simple que ça de gérer les changements d'heures, ça serait fait ...
ce qui n'empêche pas que ça la fout mal sur l'ifon vu qu'Apple aurait les moyens humains pour valider ça bien.
Après, je laisse suffisamment de bugs dans mon code pour aussi garder une certaine humilité, il suffit de tellement peu pour que ça ne marche pas :)
#!/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.
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.
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.
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
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.
[^] # Re: Proposition
Posté par gaaaaaAab . En réponse au message Récupération des attributs mobiles dans un fichier xm avec ruby. Évalué à 3.
En fait, je suis tombé sur ce raccourci un jour alors que je creusais un autre sujet. Je pensais même pas que ça passerait en fait, preuve que le langage est robuste et flexible.
Après, je suis d'accord, pour de la prod, il faut préférer la version explicite, plus maintenable à long terme
[^] # Re: Proposition
Posté par gaaaaaAab . En réponse au message Récupération des attributs mobiles dans un fichier xm avec ruby. Évalué à 8.
[^] # Re: Merci pour cette information.
Posté par gaaaaaAab . En réponse au journal It's not a bug, it's a fissure !. Évalué à 2.
# free ... ou pas ?
Posté par gaaaaaAab . En réponse au message Effacer un pointeur fournit par une librairie externe. Évalué à 3.
c'est autorisé, mais déconseillé.
La règle usuelle : c'est celui qui alloue qui désalloue
Confier l'allocation et la désallocation à des layers différents du code complique énormément la maintenance (et donc favorise les bugs).
Là, c'est à la lib de fournir les APIs qu'il faut pour (au choix):
- désallouer la mémoire allouée,
- laisser la charge de l'allocation/désallocation à l'appelant
//Do something correspond à copier le pointeur dans un container civilisé (un vecteur) qui lui même est propagé par référence dans tout le code.
possible que j'interprète mal, mais si tu copie des *pointeurs* dans ton vecteur, et que tu désalloues la mémoire pointée, forcément ...
[^] # Re: 640go, seulement
Posté par gaaaaaAab . En réponse au journal Geocities archivé. Évalué à 5.
[^] # Re: Merci pour cette information.
Posté par gaaaaaAab . En réponse au journal It's not a bug, it's a fissure !. Évalué à 3.
qu'est-ce que j'ai écrit qui pourrait te laisser croire ça ?
[^] # Re: Grave !
Posté par gaaaaaAab . En réponse au journal Enfin un journal qui parle de Linux. Évalué à 7.
[^] # Re: Merci pour cette information.
Posté par gaaaaaAab . En réponse au journal It's not a bug, it's a fissure !. Évalué à 2.
ce qui n'empêche pas que ça la fout mal sur l'ifon vu qu'Apple aurait les moyens humains pour valider ça bien.
Après, je laisse suffisamment de bugs dans mon code pour aussi garder une certaine humilité, il suffit de tellement peu pour que ça ne marche pas :)
[^] # Re: une seule ligne
Posté par gaaaaaAab . En réponse au sondage J'indente mon code source avec. Évalué à 3.
[^] # Re: une seule ligne
Posté par gaaaaaAab . En réponse au sondage J'indente mon code source avec. Évalué à 4.
[^] # Re: download depuis la machine HOTE vers le dossier du chroot
Posté par gaaaaaAab . En réponse au journal [ juste pour me défouler ] Encore un coup de gueule.. Évalué à 3.
pour déployer rapidement du soft sur des machines d'intégration, je fais du sshfs. Tant qu'il n'y a que quelques machines, c'est super confortable.
[^] # Re: j'aller dire "eviter les accents" meme en francais
Posté par gaaaaaAab . En réponse au message [UTF8 et Co] recherche pense bête pour programmeur distrait. Évalué à 1.
# ...
Posté par gaaaaaAab . En réponse au message [UTF8 et Co] recherche pense bête pour programmeur distrait. Évalué à 9.
superbe lapsus ! =)
# en changeant de séparateur
Posté par gaaaaaAab . En réponse au message bash : construction d'une ligne de commande dont certains arguments contiennent des espaces. Évalué à 2.
[^] # Re: zut ...
Posté par gaaaaaAab . En réponse au journal Toujours plus vite. Évalué à 2.
on peut déjà faire pleins de trucs avec des perfs plus qu'acceptables avec sed
[^] # Re: zut ...
Posté par gaaaaaAab . En réponse au journal Toujours plus vite. Évalué à 4.
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 ;)
[^] # Re: ???
Posté par gaaaaaAab . En réponse au journal Toujours plus vite. Évalué à 2.
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
[^] # Re: ???
Posté par gaaaaaAab . En réponse au journal Toujours plus vite. Évalué à 3.
qu'est-ce que vous appelez la complétion sur les packages ?
[^] # Re: Pas de problème
Posté par gaaaaaAab . En réponse au journal Toujours plus vite. Évalué à 5.
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.
[^] # Re: ~~
Posté par gaaaaaAab . En réponse au message Comment traduiriez-vous "Fencing Device" ?. Évalué à 3.
concernant le retrait de fruits contaminés dans une grappe, ça ne me dit rien.
[^] # Re: ~~
Posté par gaaaaaAab . En réponse au message Comment traduiriez-vous "Fencing Device" ?. Évalué à 3.
En revenant sur le sujet aujourd'hui, et dans l'idée du sécateur : élagage ?
[^] # Re: Facile
Posté par gaaaaaAab . En réponse au journal Softs qui déchiraizent \o/. Évalué à 2.
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
[^] # Re: Ca dépend du sujet...
Posté par gaaaaaAab . En réponse au journal Sacrés fournisseurs Internet.... Évalué à 2.
et puis la vente à emporter est à 5,5 % depuis un sacré bout de temps
# 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.