En plus de l'exécution de commandes simples comme
grep, vous pouvez utiliser la ligne de commande pour démarrer un programme vaste et complexe. Avant, les interfaces graphiques étaient communes, les programmes conçus pour employer du texte simple et utiliser le texte brut et prendre l'écran. Maintenant, ces programmes s'exécutent au sein de la même fenêtre que vous utilisez pour la ligne de commande.
Dans ce livre, nous nous concentrerons sur les éditeurs de texte, parce que vous en avez besoin pour enregistrer vos commandes pour une utilisation ultérieure et écrire des scripts. Ils sont ratiques pour beaucoup d'autres tâches également : par exemple, vous pouvez être amené à modifier des fichiers HTML sur un serveur web à l'aide d'un éditeur de texte.
Pratiquement toutes les personnes utilisant un ordinateur connaissent un traitement de texte. Le monde du logiciel libre en fournit plusieurs, puissants, dont OpenOffice.org et KWrite. Les éditeurs de texte que nous présentons cet ouvrage manipulent du texte comme les traitements de texte, mais il existe une différence fondamentale.
Word processors, wikis, content management systems, and text editors all have their place. The tasks in this book require a text editor. If you want to use a word processor to edit these files, you can do so, but make sure to choose a plain text form when you save the file.
GNU/Linux is a very file-centric operating system: everything is (or looks like) a file. All basic configuration is done via carefully crafted text files, in the right place with the right contents. You can find many graphical tools to configure your GNU/Linux box, but most of them just tweak text files on your behalf.
Those text files have an exact syntax that you must follow. A simple misplaced character could jeopardize your system, so using a word processor for this matter is not only a bad idea but could corrupt your files with extra formatting information. Configuration files don't need italic or bold, they only need the right information.
With source code it's the same thing. Compilers (programs that turn code into other programs) are very strict with syntax. Some of them even care about where in the line a specific command is. Word processors mess up the position of text in lines far too much for compiler to like them. What you need is a clean view of what's in the source code or the configuration file to know that what you're writing is exactly what your system will get.
Some editors go even further: they became Integrated Development Environments (IDEs), that not only understand what you're typing (be it an Apache configuration or Java code) but can predict what you want to type, suggest modifications, or show your mistakes. They can color specific keywords, automatically place things in the right place, and so on.
But the most important is that all those colors and highlighting are done only within the display. Those fancy changes are not propagated to the text files, which are meant to be plain text. This is one particular useful feature that word processing programs can't do and is most essential to text editing.
In the beginning... was the command line (Neil Stephenson). Twenty years ago there weren't many graphical interfaces around and Unix was already a grown-up operating system running on a whole lot of very important computers. All configuration was already stored in text files because of the KISS principle (keep it short and simple). Unix made the most of KISS and plain text by helping programs work together on text files. Pipes (using the | character) are one powerful method of working together that you've seen in this book.
Nowadays, computers have thousands of times more power than those early ones, but keeping configuration in text files still gives a big advantage when the only connection you have to your server is through a 56-Kbit modem line and it's in a different country. Having to open a graphical interface might not be possible and if that's the only way you have to fix a problem, you're in big trouble.
Making graphical programs that deal with configuration was a big plus, as the average user can now change things without reading tons of documentation and isn't likely to break the system by inserting one wrong character to a point where it's irrecoverable, but providing text files and the command-line editor is fundamental to any operating system.
Although most text editors came from the command-line world, most also have a graphical interface today. Menus and buttons do help a lot when using Gvim or Emacs. GEdit and Kate (which are purely graphical) are short and simple, still providing the same basic functionality and the same important features for text editing.
Because the terminal and command line are so tied in with the text editors, many commands open up a text editor for you. We saw one example
sudoedit, in the "Useful Customizations" section. You can set the default editor though by setting either the EDITOR or the VISUAL environment variable. For instance:
$ export EDITOR=emacs
Put this in a startup file such as ./bashrc, and commands will use your chosen editor when they present a file for editing.
Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.
Vous devriez rafraîchir la page.