Il y a un manuel, il suffit de savoir où il se trouve. Il est accessible avec le man commande. Si vous ne savez pas comment l'utiliser, tapez man man . Le man la commande est très importante; rappelez-vous-en même si vous oubliez tout le reste.
Le manuel contient des informations détaillées sur une variété de sujets, qui sont séparés en plusieurs sections :
- Commandes générales
- Appels système
- Fonctions de bibliothèque, couvrant en particulier la bibliothèque standard C
- Fichiers spéciaux (généralement des appareils, ceux trouvés dans
/dev) et les pilotes - Formats et conventions de fichiers
- Jeux et économiseurs d'écran
- Divers
- Commandes et démons d'administration système
La notation ls(1) fait référence au ls page dans la section 1. Pour la lire, tapez man 1 ls ou man ls .
Pour éviter qu'on vous dise de lire le manuel lorsque vous posez une question, essayez man command , apropos command , command -? , command --help , et quelques recherches Google. Si vous ne comprenez pas quelque chose dans le manuel, citez-le dans votre question et essayez d'expliquer ce que vous ne comprenez pas. Habituellement, lorsqu'ils vous demandent de lire le manuel, c'est parce qu'ils pensent que cela vous sera plus bénéfique qu'une simple réponse incomplète. Si vous ne savez pas quelles pages de manuel sont pertinentes, demandez.
Je pense que le proverbe chinois souvent cité l'explique bien :
Si vous donnez un poisson à un homme, il n'aura qu'un seul repas. Si vous lui apprenez à pêcher, il mangera toute sa vie.
Alors que vous pourriez penser "Mais ce n'est qu'une question, pourquoi ne peuvent-ils pas simplement me dire la réponse", c'est parce que les forums deviendraient si remplis de personnes posant des questions évidentes qu'il serait difficile pour des questions sur des choses plus ésotériques d'être remarquées . Alors n'y pensez pas comme s'ils vous rebutaient, pensez-y comme s'ils vous aidaient à vous aider vous-même.
Par exemple, il est trivial de trouver la réponse à "Comment utiliser grep pour effectuer une recherche insensible à la casse", surtout une fois qu'on vous rappelle de regarder dans la page de manuel. Mais pour une question comme "Comment puis-je faire une recherche insensible à la casse sur le premier champ d'un fichier, mais sensible à la casse sur les champs restants ?", il n'y a pas de page de manuel simple qui vous dira la réponse, et il existe une multitude de façons d'y répondre.
Je crois que c'est parce que la plupart des experts préfèrent enseigner à quelqu'un comment apprendre, plutôt que de lui enseigner un ou deux faits isolés. Dire à quelqu'un de lire la page de manuel, c'est essayer de l'inciter à apprendre à apprendre par lui-même.
Je me souviens, mais je ne peux pas rechercher sur Google, une étude qui affirmait que la différence entre un novice Unix et un expert Unix (pas si différent d'un novice ou d'un expert Linux, peut-être) était que l'expert savait comment rechercher les choses. En essayant de trouver cette étude, j'ai trouvé Prompt Comprehension in UNIX Command Production, ce qui semble contredire l'étude dont je me souviens. Quel dommage :tout ce que vous avez à faire est de connaître un tas de faits pour être un expert. Mais dans ce cas, dire à quelqu'un de lire le manuel peut également servir à remplir le questionneur de connaissances, conduisant à la production d'un autre expert Unix ou Linux.
Il y a aussi un investissement de temps à court ou à long terme dans le débutant qui pose la question. Il faut certainement moins de temps pour dire "utiliser ls -ltr" par exemple, que pour enseigner au débutant la liste des fichiers et les options, etc. Mais si l'expert doit répondre à plus de 3 ou 4 questions, la valeur à long terme d'investir dans la lecture du manuel par quelqu'un devient évidente.