C'est pour troller parce que ca fait plaisir. Et c'est pour eduquer parce que bon, le shell ca n'a pas non plus a etre crado tout le temps, surtout quand on veut donner du code.
La commande ls est prevue pour un usage interactif, pas pour etre parsee. Son output n'est pas fiable. De plus utiliser le resultat d'expansion de commandes comme noms de fichier c'est plutot hasardeux et souvent inutile… De plus, si tu ne declares pas tes variables de fonction "local", tu pourris l'environnement de l'appelant, fais attention.
En built-in, tu peux faire plus rapide et plus secure comme ca :
cd_up(){local opt_saving=$(shopt -p failglob nullglob)shopt -s nullglob
shopt -u failglob
local -a dirs=( */ )eval"$opt_saving"[[${#dirs[@]} -ne 0]]||return 0
cd"${dirs[0]}" 2>/dev/null && ls
}
Je ne force personne (a part certains, qui se reconnaitront - private joke) mais je refute l'argument.
J'ai constate que ce genre de bout de code etait tres souvent 1. dupliqué partout, tout le temps 2. penible a ecrire 3. penible a ecrire correctement, a la fois dans la syntaxe (manque de double-quotes, "eval" utilise a mauvais escient et mal controle) et dans le design (gestions des options longues hasardeuse, variables utilisees nommees aleatoirement, ce qui nuit a la lisibilite).
Typiquement, ton exemple ne gere pas le cas d'une chaine vide passee en parametre.
Pour la ligne de commande
foo.sh "" 1 2 3
Ton script ignorera completement 1, 2 et 3. C'est peut-etre un detail pour vous mais pour moi ca veut dire beaucoup. Et peut-etre que tu n'en as rien a faire pour ton cas specifique mais de la a dire que ca convient dans la plupart des cas je trouve ca un tantinet exagere.
Pour moins de lignes de code, je te propose d'avoir en plus :
Une meilleure robustesse (ce que l'utilisateur rentre, le script l'aura entre les mains)
Un usage-message genere automatiquement
Une nomenclature claire (enfin, relativement claire : la syntaxe de bash est ce qu'elle est) :
la valeur de option 2 dans "${program_options[option2]}"
tes fichiers dans "${program_params[@]}"
la possibilite de tester option1 avec des syntaxe "if argsparse_is_option_set option1; then … ; fi"
Un comportement non-ambigu : pour reprendre ton bout de code : tu permets "--option2=tata" mais pas "--option2 tata" ? Pourquoi peut-on faire l'un mais pas l'autre alors que ce sont 2 formes d'ecritures permises par getopt et que de facto l'utilisateur espere pouvoir les utiliser ?
Je pense qu'argsparse est encore moins contraignant pour les gens qui ne veulent pas se prendre la tete.
Non, je voulais bien parler de [/usr]/bin/getopt qui fait partie de util-linux. Mais getopts etant sensiblement moins evolue (pas d'option longue.. -_-) que getopt, tu vois bien la transitivite.
Chaque fichier du tuto est un shell script a la fois a lire et a exécuter.
C'est sur qu'il est pas commenté en français, mais si c'est obscure je suis prêt a le rendre plus clair.
Si tu veux un exemple rapido-trivial, tu peux toujours essayer ça :
La fondation n'a *pas* ete creee en juin 2005 mais dans le courant de l'automne.
En juin Red Hat avait annonce son *intention* de creer une fondation pour fedora. La confusion vient d'un site de news qui dans la phrase "nous avons l'intention de creer une fondation fedora" a fait purement et simplement sauter "l'intention de". C'est aussi imple que ca.
La fondation a ete officialisee en octobre dernier. Et effectivement elle n'est pas fonctionnelle, en ce sens que ce n'est pas elle qui dirige encore le projet fedora.
Ceci dit, les personnes qui vont diriger la fondation ont ete nommees (voir les log des FESCo-meeting) et on espere qu'une fois la charge de travail qu'impose la release de FC5 estompee, la transition se fera rapidement.
Les sources de RHAS sont librement telechargeables. Je vois pas du tout le probleme. Plusieurs groupes de motives ont meme reconstruit la distribution... notemment l'equipe de CentOS.
Sous Fedora Core - et donc a fortiori sous RHEL - /tmp n'est pas efface a chaque reboot. Seules les sockets et pipes persistants y passent. Il est surveille par un tmpwatch (en crontab) qui efface les fichiers non accedes depuis plus de 2 semaines.
Red Hat ne developpe pas yum. Yum n'a pas ete developpe par Red Hat.
YUM est le Yellowdog Updater, Modified. donc un truc modifie de yellowdog.
Adopte' par fedora.us "in the first place" et pousse' chez dans le projet fedora par la suite c'etait ca ou apt-rpm. Et apt rpm c'est un peu trop... sale pour metre son nez dedans. urpmi n'a pas convaincu tout le monde a l'epoque, point.
D'facon ca evitera aux idiots d'utiliser les repositories mandrake sous fedora.
Et vice-versa.
noms differents == differents packages.
tu ne peux pas avoir un packages libc6 compile pour i386 et un package libc6 compile' pour x86_64 en meme temps installes sur ton systeme a moins de le declare en duplicate... et de declarer tout le reste en duplicate aussi.... apt ne saurait installer ce genre de trucs.
apt (version rpm) n'est plus maintenu.
apt (tout court) ne supporte pas l'installation en plusieurs exemplaires d'un package pour differentes architectures --> impossibilite d'installer glibc.x86_64 et glibc.i386 --> completement inutile pour Fedora PPC64/x86_64.
apt (version rpm?) a un systeme de resolution de dependances completement moisi (surtout sur les trucs genre "Provides: foo".. et tout ce qui touche au noyau... affreux.)
yum a evolue depuis FC2. A la sortie de FC3 un nouveau format de donnees de depot (repository data) est venu remplacer les simple fichiers .hdr tout pourris. La duree des dites donnees en a ete grandement reduite.
Il y a quelques semaines Seth (le mainteneur de yum) a affirme que yum 2.3.x etait plus rapide qu'apt pour la resolution de dependances. J'ai brievement teste et je veux bien le croire.
Sauf que le reverse engineering est interdit par la licence du module pwcx.
Donc, qui enfreint le plus la licence de l'autre la ? Pas tres cathodique tout ca..
Le film "où il va demander des comptes aux patrons de grandes entreprises" s'appelle The Big One, et non on y parle pas de Microsoft. On voit le pdg de nike qui refuse de faire faire des chaussures nike aux USA et qui prefere exploiter des gosses de 14 ans en thailande..... des trucs comme ca.
Bon, c'est sur, j'ai fait la mise à jour via apt-get, et pas via les CDs
Tout est dit. Mettre a jour les package ne suffit pas. Donc si tu fais pas les choses de la bonne maniere c'est ton probleme. Tu peux aussi conduire sur l'autoroute dans le bon sens mais en marche arriere, c'est sur t'es pas vraiment face a la route, mais quand meme.
Anaconda aurait su migrer tes config. Voila. Bonjour chez toi.
# Simple.
Posté par Dams Nadé (site web personnel) . En réponse au sondage Quels sont les mots que vous employez le plus dans un contexte d'engagement ?. Évalué à 3.
"Seek ! Locate ! Destroy !"
# ok, corrigeons. :p
Posté par Dams Nadé (site web personnel) . En réponse au journal Faire de la magie avec son .inputrc. Évalué à 10. Dernière modification le 28 mars 2015 à 21:50.
C'est pour troller parce que ca fait plaisir. Et c'est pour eduquer parce que bon, le shell ca n'a pas non plus a etre crado tout le temps, surtout quand on veut donner du code.
La commande ls est prevue pour un usage interactif, pas pour etre parsee. Son output n'est pas fiable. De plus utiliser le resultat d'expansion de commandes comme noms de fichier c'est plutot hasardeux et souvent inutile… De plus, si tu ne declares pas tes variables de fonction "local", tu pourris l'environnement de l'appelant, fais attention.
En built-in, tu peux faire plus rapide et plus secure comme ca :
# Et quid du portage gtk3 ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Firefox 35 heures. Évalué à 3.
Ca se stabilise ? Wayland arrivant, ca me paraissait vaguement important.
[^] # Re: Exemple simple
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Bash Argsparse : mieux gérer sa ligne de commande dans ses scripts.. Évalué à 5. Dernière modification le 12 octobre 2013 à 15:34.
Je ne force personne (a part certains, qui se reconnaitront - private joke) mais je refute l'argument.
J'ai constate que ce genre de bout de code etait tres souvent 1. dupliqué partout, tout le temps 2. penible a ecrire 3. penible a ecrire correctement, a la fois dans la syntaxe (manque de double-quotes, "eval" utilise a mauvais escient et mal controle) et dans le design (gestions des options longues hasardeuse, variables utilisees nommees aleatoirement, ce qui nuit a la lisibilite).
Typiquement, ton exemple ne gere pas le cas d'une chaine vide passee en parametre.
Pour la ligne de commande
Ton script ignorera completement 1, 2 et 3.
C'est peut-etre un detail pour vous mais pour moi ca veut dire beaucoup.Et peut-etre que tu n'en as rien a faire pour ton cas specifique mais de la a dire que ca convient dans la plupart des cas je trouve ca un tantinet exagere.Pour moins de lignes de code, je te propose d'avoir en plus :
Je pense qu'argsparse est encore moins contraignant pour les gens qui ne veulent pas se prendre la tete.
[^] # Re: Vulgaire ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Bash Argsparse : mieux gérer sa ligne de commande dans ses scripts.. Évalué à 1.
Non, je voulais bien parler de [/usr]/bin/getopt qui fait partie de util-linux. Mais getopts etant sensiblement moins evolue (pas d'option longue.. -_-) que getopt, tu vois bien la transitivite.
[^] # Re: Exemple d'utilisation
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Bash Argsparse : mieux gérer sa ligne de commande dans ses scripts.. Évalué à 6.
C'est vrai que j'aurai pu rajouter un lien direct vers le didacticiel.
https://github.com/Anvil/bash-argsparse/blob/master/tutorial/
Et commençons par le commencement : https://github.com/Anvil/bash-argsparse/blob/master/tutorial/1-basics
Chaque fichier du tuto est un shell script a la fois a lire et a exécuter.
C'est sur qu'il est pas commenté en français, mais si c'est obscure je suis prêt a le rendre plus clair.
Si tu veux un exemple rapido-trivial, tu peux toujours essayer ça :
Ça tient en 4 lignes, la ou tu aurais du invoquer getopt, faire ta fonction usage, etc..
# Definitivement Hyperion.
Posté par Dams Nadé (site web personnel) . En réponse au sondage Votre univers SF / Space opéra préféré. Évalué à 1.
Nuf said.
# Y'a du boulot...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Un prompt bash utile, sans poudre aux yeux. Évalué à 6.
…A faire.
Les variables non "quotées", ni declaree en "local" dans les fonctions, les * non-despecialisees… ouais y'a encore beaucoup a faire.
Je pense que ton script est dangeureux.
tu contredis beaucoup de points de la FAQ de reference http://mywiki.wooledge.org/BashFAQ/
# Y'a que moi que ca choque ca ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Sortie officielle de GTK+ 3.0 !. Évalué à 5.
[^] # Re: Prématuré
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Nouvelle version majeure de VLC media player : 1.1.0 « The luggage ». Évalué à 1.
# ( )
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Atelier jeux vidéos à Montpellier. Évalué à 1.
[^] # Re: gratte-gratte ?
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Machinarium, un nouveau jeu pour Linux. Évalué à 3.
[^] # Re: Fedora doit changer
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Fedora Core en mutation. Évalué à 7.
En juin Red Hat avait annonce son *intention* de creer une fondation pour fedora. La confusion vient d'un site de news qui dans la phrase "nous avons l'intention de creer une fondation fedora" a fait purement et simplement sauter "l'intention de". C'est aussi imple que ca.
La fondation a ete officialisee en octobre dernier. Et effectivement elle n'est pas fonctionnelle, en ce sens que ce n'est pas elle qui dirige encore le projet fedora.
Ceci dit, les personnes qui vont diriger la fondation ont ete nommees (voir les log des FESCo-meeting) et on espere qu'une fois la charge de travail qu'impose la release de FC5 estompee, la transition se fera rapidement.
[^] # Re: Ca commence mal
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Quand Mark Shuttleworth fait le point sur Ubuntu. Évalué à 1.
[^] # Re: Interessant
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Envie de "kliker" ?. Évalué à 5.
[^] # Re: Utilisation de Fedora en tant que serveur ...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 1.
YUM est le Yellowdog Updater, Modified. donc un truc modifie de yellowdog.
Adopte' par fedora.us "in the first place" et pousse' chez dans le projet fedora par la suite c'etait ca ou apt-rpm. Et apt rpm c'est un peu trop... sale pour metre son nez dedans. urpmi n'a pas convaincu tout le monde a l'epoque, point.
D'facon ca evitera aux idiots d'utiliser les repositories mandrake sous fedora.
Et vice-versa.
# rpm.livna.org : nouvelle configuration
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 2.
http://rpm.livna.org/fedora/4/i386/RPMS.lvn/livna-release-4-0.lvn.2(...) pour avoir la configuration et la cle gpg.
[^] # Re: un troll et une question
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 5.
tu ne peux pas avoir un packages libc6 compile pour i386 et un package libc6 compile' pour x86_64 en meme temps installes sur ton systeme a moins de le declare en duplicate... et de declarer tout le reste en duplicate aussi.... apt ne saurait installer ce genre de trucs.
[^] # Re: un troll et une question
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 3.
apt (tout court) ne supporte pas l'installation en plusieurs exemplaires d'un package pour differentes architectures --> impossibilite d'installer glibc.x86_64 et glibc.i386 --> completement inutile pour Fedora PPC64/x86_64.
apt (version rpm?) a un systeme de resolution de dependances completement moisi (surtout sur les trucs genre "Provides: foo".. et tout ce qui touche au noyau... affreux.)
yum a evolue depuis FC2. A la sortie de FC3 un nouveau format de donnees de depot (repository data) est venu remplacer les simple fichiers .hdr tout pourris. La duree des dites donnees en a ete grandement reduite.
Il y a quelques semaines Seth (le mainteneur de yum) a affirme que yum 2.3.x etait plus rapide qu'apt pour la resolution de dependances. J'ai brievement teste et je veux bien le croire.
Preferez yum.
# pff....
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Subventions publiques pour la R&D des jeux vidéo en logiciels libres. Évalué à 5.
[^] # Re: Efficace !
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Support des webcams Philips: pilotes en GPL. Évalué à 4.
Donc, qui enfreint le plus la licence de l'autre la ? Pas tres cathodique tout ca..
# ksss...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Réponse de la FFII au manifeste du MEDEF sur les brevets. Évalué à 6.
[^] # Re: www.fahrenheit911.com
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Fahrenheit 9/11 de Michael Moore. Évalué à 1.
[^] # Re: De mon point de vue, pas finie...
Posté par Dams Nadé (site web personnel) . En réponse à la dépêche Test de la Fedora Core 2. Évalué à 1.
Tout est dit. Mettre a jour les package ne suffit pas. Donc si tu fais pas les choses de la bonne maniere c'est ton probleme. Tu peux aussi conduire sur l'autoroute dans le bon sens mais en marche arriere, c'est sur t'es pas vraiment face a la route, mais quand meme.
Anaconda aurait su migrer tes config. Voila. Bonjour chez toi.
[^] # Re: raccourci mozilla
Posté par Dams Nadé (site web personnel) . En réponse au journal Fedora Extra. Évalué à 1.