Discussion:Muffin 1/Utilisation de la ligne de commande

De Magazine fedora-fr
Aller à : navigation, rechercher

Intro & Désaventages

1ère relecture

Perso, je pense que tout l'article se joue là dedans, même si c'est très beau de voir des belles lignes de codes avoir un effet mazic :-) Dans l'intro, je verrais bien une explication du mécanisme interne (pas trop technique), être plus exhaustif, l'historique etc... Enfin, tout ce qui permette de comprendre dans quoi il va, donner les bases environnementales à l'utilisateur. Vu la présentation des titres, on peut croire que la ligne de commande n'a que des désavantages, ce qui n'est pas du tout le cas. Donc autant faire une partie claire et nette "Avantages & Désavantages" en appuyant un peu plus sur les avantages; puisque que dans l'article hormis la légèreté et les scripts, je ne vois rien d'autre.

Correction

J'ai changé quelque peu le paragraphe d'introduction, pour ce qui est de désavantages, j'ai changé le titre en mise en garde puisque je pense qu'il faut quand même prévenir les gens des efforts qu'ils auront à faire pour utiliser la ligne de commande. Attention tu as fait une faute ;)

2nd relecture

Je trouve ça mieux :-) Quoi que pour l'historique, je voyais la chose plus proche : genre l'histoire des shells. Enfin, c'est toi qui vois. Pour la mise en garde, j'aurais formuler autrement; mais bon c'est encore ton article ^^

2nd correction

Rho fait pas ton bochecha (chieur), je la laisse tel quel, on va dire que c'est ma patte qui est dessus

Première approche

Première relecture

C'est bien beau en soi la pratique, mais un peu de théorie universelle avant ça ferait un peu de bien. Rien qu'un petit "[commande] [option(s)] [argument(s)]" expliqué ce serait bien ainsi que (très court), l'appel à toute les commandes dans /usr/bin /bin etc...

Ensuite, tu donnes des combinaisons de commandes (du mini-scripting) avec l'utilisation de "lien logique" de bash, ce n'est pas précisé comment ça fonctionne. Pareil pour la "tabulation", ce n'est pas évident qu'elle sert pour faire de la complétion de commande.

Pour man, je trouve que c'est un peu bourrin, "à froid", je pense que d'essayer "--help" avant, ça peut être plus ingérable.

Correction

Voila j'ai fait quelque changements par rapport à tes remarques, je te laisse lire.

2nd relecture

C'est beaucoup plus mieux. Par contre, ça va être indispensable de séparer la pratique de le théorie, sinon ça fait un gros pavet. Pour le "copier/coller" de fichier, quand je disais "expliquer la syntaxe bash", c'était juste dire après le script à quoi sert chaque chose, un peu comme tu as fait avec le joker, pas comme avec le point virgule qui rallonge bêtement l'article. Par contre en dessous, tu n'as pas expliqué le "pipe (|)". D'ailleurs, je verrais bien l'utilisation de "points", parce que la il n'y a pas de séparation des exemples. Également, tu as déjà mentionné la commande "man", pas besoin d'en reparler.

2nd correction

Les changements sont fait, et puis pour le ;, ça parait con, mais quand c'est purement perso, je me suis retrouvé à devoir l'utiliser un jour, et ça m'a franchement fait gagner trop de temps.

Maîtrisons la ligne de commande

1ère relecture

Pour les alias, pourquoi pas, c'est des exemples assez pratiques. Enfin, personnellement, j'ai jamais utilisé d'alias.

Pour Script, ça commence bien avec un script bash qui manque tout de même de documentation. On montre le lien facilement franchissable entre la ligne de commande et la création de script pour l'administrateur système.

Mais là, ça s'écroule ! Je sais que le perl c'est un bon langage que tu apprécies. Mais non, tu fais complètement hors-sujet/inapproprié par rapport au but initial "la ligne de commande"; d'accord c'est un type de script pour l'utilisateur, mais jamais un utilisateur lambda va lancer un shell perl pour faire de la ligne de commandes.

Perso, j'aurais fait une partie sur tout les outils/logiciel en ligne de commande tel vi, imagemagik, etc... Voire même une partie sur l'utilisation de la console en elle même.

Correction

Ah tu devrais utiliser des alias, ça te change la vie !!!!

Bon j'ai fait les changements que tu as proposé, et j'ai viré le script perl.

Je pense que le plus intéressant serait de faire un lien avec l'article sur Yum.

2nd relecture

Pour l'intro, les alias et les scripts, c'est parfait. Par contre, pour les logiciels c'est beaucoup trop précis; on cherche pas à savoir l'historique de Vim ou de Yum, juste une ribambelle de logiciel qui va de l'éditeur de texte jusqu'au client de messagerie instantanée, en passant par une série d'outil de monitoring. Peut-être préciser aussi, que généralement, les interfaces graphiques ne sont que des "frontends" et l'on peut s'adresser généralement directement au moteur; ou encore que certain ont une interface propre.

2nd correction

Justement le but n'est pas de montrer la ribambelle de logiciel, je pourrais faire une ligne et dire : on peux tout faire ou presque en ligne de commande, tant que cela ne requiert pas d'image. J'ai justement focalisé sur vim et yum car ce sont pour moi les deux outils les plus important à maitriser en ligne de commande.

Conclusion

1ère relecture

L'ouverture est assez moyenne (rpm & co ça peut être un bon filon, mais ce n'est pas super exploité). Pour le reste, ça va. Par contre, ta dernière phrase est intéressante par son contenu, mais la forme casse tout (franchement, "je vous pris de").

Correction

J'ai fait quelques changements

2nd relecture

Je n'ai rien à y redire

2nd correction

Je n'ai donc rien changé ;)

Ma conclusion personnelle

Globalement, la trame de l'article est bien; néanmoins, ça manque de contenu/d'exhaustivité/de détail à certains endroits. Fait aussi à la structure des phrases, certaines sont presque incompréhensibles. Pareil pour le style, ce serait bien à certain endroit de faire un peu moins "papote" avec le lecteur.

Je répète tout ceci n'est qu'un avis personnel

PabloMartinGomez 17 juillet 2008 à 02:32 (CEST)

Je pense que l'article est proche de la validation. Ce n'est presque plus que des finitions. Néanmoins, je pense qu'il serait intéressant de trouver des images pour compléter l'article :-)

PabloMartinGomez 20 juillet 2008 à 15:23 (CEST)

J'approuve les remarques de Pascal, qui donne un style plus journalistique à l'article. Pareil pour le script, une description en détail serait bienvenue (d'ailleurs, sur la version actuelle tu as laissé la mention du script perl). Sinon pour le reste, je pense considère l'article comme validé (l'utilisation intelligente de "gras" et d'"italique" ainsi que d'images serait bienvenue)

PabloMartinGomez 26 juillet 2008 à 01:02 (CEST)

Recorrection

J'ai recorrigé, le style, le script, à toi de relire.

Relecture Pascal

Quelques lourdeurs de style. Par exemple : « Pour pouvoir faire cela, vous trouverez des liens utiles dans les références. » Il vaut mieux intégrer les refs dans le textes. J'ai corrigé uniquement le paragraphe script (dans la page discussion) car j'en ai assez pour aujourd'hui.

quelques « bien sur », « je vous renvoies vers... », « une chose à savoir... » Il y a aussi « Je vous laisse chercher pour avoir différents tutoriaux sur Vim, vous en trouverez dans les références[3] »

Je viens de voir que tu t'es largement inspirer de wikipedia, il y a pas de mal mais met le en ref. Je caserais la ref, à la fin de cette phrase : ou éventuellement « VI Meilleur ».

Je rajouterais une ref ici : « Vim possède son propre langage d’extension ». Ce qu'il fait que ta phrase « Je vous laisse chercher... » est inutile, il y a tout ce qu'il faut dans les 2 refs à rajouter :)

Peut-être habituer le lecteur en variant l'appelation. ligne de commande, terminal, shell, invite de commande... En plus ça évite les répétitions :)

caser csh, zsh histoire d'ouvrir l'article. Il n'y a pas que bash :) Il manque pas une description des sorties ? sortie standard, std error, std input une description de | ? xargs ? Un exemple avec un find ... | xargs grep "..." ? Les caractères actifs : * (c'est le seul que je connaisse)

réécriture du paragraphe script ci-après.

Script

Les scripts permettent une automatisation des commandes entrées dans le terminal. Ils peuvent être écrit en différent langages comme bash[ref], python[ref], perl[ref] et bien d'autres. Il est impossible de détailler toutes les possibilités des différents langages de script dans cette article, seuls quelques exemples de script bash démontrant leurs possibilités seront présentés.

Le premier exemple est la réalisation d'un script bash (Bourne shell est mal placé, une explication est nécessaire ou une ref) qui donne l'heure en français. Cette exemple montre l'utilisation des variables et l'affichage de texte sur la sortie standard. Créons un fichier nommé heure à l'aide de Vim (vim heure) :

#! /bin/sh ordonne l'interprétation par le bourne shell
#
# Les lignes commençant par # sont un commentaire qui n'est pas interpréter par le shell.
# Shell-script de mise en application de la récupération du résultat 
# d une commande. Affiche l'heure en français.
# définition de la variable heures, expliquer $(), « + » et « %H »
heures=$(date +%H) 
#expliquer ` `
minutes=`date +%M`
# la commande echo écrit la chaine en paramètre sur la sortie standard
echo "Il est $heures heures $minutes minutes et $(date +%S) secondes"

Voila ce qui devrait s'afficher à l'écran, après le lancement du script :

$ ./heure
Il est 14 heures 08 minutes et 23 secondes 

Le 2ème exemple présente la suppression de certains fichiers suivant quelques critères...