The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Linux Fundamentals, Part 1/fr-fr
Avant de commencer
À propos de ce tutoriel
Bienvenue à « Fondamentaux Linux », premier d'une série de quatre tutoriels destiné à vous préparer à l'examen LPI 101. Dans ce tutoriel, vous suivrez une introduction au bash (le shell linux standard), vous apprendrez à utiliser les commandes standard Linux telles que ls, cp et mv, puis vous aurez une explication sur les inodes, les liens physiques et symboliques, et beaucoup plus que ça. À la fin de ce document, vous aurez une sérieuse base sur les fondamentaux Linux et vous serez prêt à apprendre quelques tâches d'administration de base. À la fin de cette série de tutoriels (8 en tout), vous disposerez des connaissances dont vous avez besoin pour être un administrateur système Linux et serez prêt à obtenir la certification LPIC de niveau 1 du Linux Professional Institute si vous le souhaitez.
Ce tutoriel (Partie 1) est idéal pour ceux qui s'initient à Linux, ou pour ceux qui souhaitent revoir ou améliorer leur compréhension des concepts fondamentaux sous Linux comme la copie et le déplacement de fichiers, la création des liens symboliques et physiques et l'utilisation des commandes d'opération sur les chaînes de caractère à travers les tubes ou les redirections. En chemin, nous apporterons nos suggestions, conseils, ou encore nos petits trucs pour rendre ce tutoriel appétissant et pratique, même pour ceux qui ont déjà une bonne expérience sous Linux. Pour les débutants, la plupart de ce qu'ils liront sera tout neuf mais les utilisateurs de Linux plus expérimentés trouveront dans ce tutoriel un bon moyen pour compléter leurs compétences Linux.
Ceux qui ont suivi la première version de ce document pour une autre raison que la préparation de la certification LPI n'ont sans doute pas besoin de suivre celle-ci. Par contre, si vous prévoyez de passer les examens, vous devriez envisager de lire cette version révisée.
Introduction au Bash
Le shell
Si vous avez déjà utilisé un système Linux, vous savez que lorsque vous vous connectez, vous êtes accueilli par une invite (prompt) qui ressemble un peu à ceci :
user $
L'invite que vous devez voir peut être légèrement différente. Par exemple elle peut contenir votre nom de machine, votre répertoire de travail courant ou les deux. Cependant, quelle que soit votre invite de commande, un point est certain. Le programme qui affiche cette invite est appelé un « shell » ou interpréteur de commandes et il est très probable que votre shell soit un programme nommé bash.
Utilisez-vous bash ?
Vous pouvez vérifier si vous utilisez bash en tapant :
user $ echo $SHELL /bin/bash
Si la ligne précédente vous a retourné une erreur ou quelquechose de différent, vous utilisez peut-être un autre shell que le bash. Dans ce cas, la plus grande partie de ce tutoriel devrait continuer à fonctionner, mais il serait avantageux que vous passiez à bash fpour la préparation de l'examen LPI 101.
À propos de bash
Bash, un acronyme de "Bourne-again shell", (ndt : le shell re-né - pas comme le prénom - , en référence au bourne shell, le shell natif) est le shell par défaut sur la plupart des systèmes Linux. Le rôle du shell est d'obéir à vos commandes de façon à ce que vous puissiez interagir avec votre système Linux (c'est une interface homme machine en mode texte). Quand vous avez fini d'entrer vos commandes, vous pouvez quitter le shell ou vous déconnecter, à ce point vous retournez à l'invite de connexion.
De la même façon, vous pouvez également vous déconnecter en pressant les touches Contrôle et D simultanément au prompt du bash.
Utiliser "cd"
Comme vous vous en serez probablement rendu compte, observer votre prompt sans rien faire n'est pas la chose la plus intéressante au monde. Alors commençons à utiliser bash pour naviguer dans notre système de fichiers. À l'invite de commande, tapez ceci (sans le $):
user $ cd /
Nous avons seulement dit à bash que nous voulons travailler dans le répertoire /, également connu comme la racine ou le répertoire racine (root) ; tous les répertoires du système forment un arbre ou une arborescence et / (prononcer slash) est considéré comme le point le plus haut (la racine) de cet arbre. cd paramètre le répertoire dans lequel vous êtes en train de travailler, également nommé le répertoire de travail. cd = change (working) directory. "
Chemins
Pour connaître votre répertoire de travail actuel, tapez :
user $ pwd /
Dans l'exemple précédent, l'argument / passé à cd est appelé un "chemin". Il dit à cd où vous souhaitez aller. En particulier, l'argument / est un chemin "absolu," ce qui veut dire qu'il spécifie un lieu relatif à la racine de l'arborescence de fichiers.
Chemins absolus
Voici quelques chemins absolus :
/dev /usr /usr/bin /usr/local/bin
Comme vous pouvez le voir, le point commun entre tous les chemins absolus est qu'ils commencent tous par /. Avec le chemin /usr/local/bin, nous disons à cd d'aller dans le répertoire racine, puis d'aller dans le répertoire usr en-dessous, puis local et bin. Les chemins absolus sont toujours évalués en partant de /.
Chemins relatifs
L'autre type de chemin est un "chemin relatif". bash, cd et les autres commandes interprètent toujours ces chemins par rapport au répertoire courant (répertoire de travail). Les chemins relatifs ne commencent jamais par un /. Donc, si nou sommes dans /usr:
user $ cd /usr
Alors nous pouvons utiliser un chemin relatif pour nous placer dans le répertoire /usr/local/bin :
user $ cd local/bin user $ pwd /usr/local/bin
Utiliser ..
Les chemins relatifs peuvent également contenir un ou plusieurs répertoires .. (dites point-point pas deux points ni coin-coin). directories. Le répertoire .. est un répertoire spécial qui pointe sur le répertoire parent (celui du niveau du dessus dans l'arborescence). Donc, à partir de l'exemple précédent :
$ pwd /usr/local/bin $ cd .. $ pwd /usr/local
Comme vous pouvez le voir , notre répertoire courant est désormais /usr/local. Nous avons été capable de "remonter" d'un répertoire, relativement au répertoire où nous nous trouvions.
En outre, nous pouvons également ajouter .. à un chemin relatif existant, ce qui nous permet d'aller dans un répertoire qui est au même niveau de l'arborescence que celui où nous nous trouvons, par exemple :
$ pwd /usr/local $ cd ../share $ pwd /usr/share
Exemples de chemins relatifs
Les chemins relatifs peuvent devenir assez complexes. Voici quelques exemples, dont aucun ne présente le répertoire de destination. Essayez de trouver le répertoire d'arrivée après avoir tapé ces commandes :
$ cd /bin $ cd ../usr/share/zoneinfo $ cd /usr/X11R6/bin $ cd ../lib/X11 $ cd /usr/bin $ cd ../bin/../bin
Maintenant essayez les et regardez si vous aviez visé juste ;)
Comprendre "."
Avant que nous ayons fini notre tour sur cd, il faut que je mentionne encore quelques points. Tout d'abord, il y a un autre répertoire spécial, appelé ., qui signifie "le répertoire courant". Ce répertoire n'est pas utilisé avec la commande cd, mais est régulièrement utilisé pour exécuter des programmes dans les répertoire courant, comme suit :
$ ./myprog
Dans l'exemple précédent, le programme exécutable myprog résidant dans le répertoire courant sera exécuté.
cd et le répertoire personnel
Si nous souhaitions aller dans notre répertoire personnel, nous pourrions taper :
$ cd
Sans argument, cd vous replace dans votre répertoire personnel, qui est /root pour le superutilisateur (l'administrateur) et typiquement /home/nomdutilisateur pour un utilisateur normal. Mais comment spécifier un fichier dans notre répertoire personnel ? Par exemple nous pourrions vouloir passer un fichier en argument à la commande myprog. Si ce fichier se situe dans notre répertoire personnel, nous pouvons taper :
$ ./myprog /home/drobbins/myfile.txt
Cependant, utiliser un chemin absolu comme ça n'est pas toujours confortable. Heureusement, nous pouvons utiliser le caractère ~ (tilde) pour faire la même chose :
$ ./myprog ~/myfile.txt
Les répertoires personnels des autres utilisateurs
Bash interprétera un ~ seul comme pointant vers votre répertoire personnel, mais vous pouvez également utiliser le tilde pour pointer vers le répertoire personnel d'autres utilisateurs. Par exemple, si vous souhaitez vous référer à un fichier nommé fredsfile.txt dans le répertoire personnel de Fred, nous pourrions taper :
$ ./myprog ~fred/fredsfile.txt
Utilisation des commandes Linux
Introduction à ls
Regardons maintenant brièvement la commande ls. Il est très probable que vous soyez familier avec cette commande qui, tapée sans paramètre, retourne le contenu du répertoire courant :
$ cd /usr $ ls X11R6 doc i686-pc-linux-gnu lib man sbin ssl bin gentoo-x86 include libexec portage share tmp distfiles i686-linux info local portage.old srcEn spécifiant l'option -a, on peut voir tous les fichiers du répertoire, y compris les fichiers cachés : ceux qui commencent avec .. Comme vous pouvez le voir dans l'exemple suivant, ls -a affiche les liens spéciaux vers les répertoires . et .. : et ..
$ ls -a . bin gentoo-x86 include libexec portage share tmp .. distfiles i686-linux info local portage.old src X11R6 doc i686-pc-linux-gnu lib man sbin ssl
Liste détaillée
Vous pouvez aussi spécifier un ou plusieurs fichiers ou répertoires à la commande ls. Si vous spécifiez un fichier, ls n'affiche que celui-ci. Si vous spécifiez un répertoire, ls affichera le contenu de celui-ci. L'option -l est très pratique si vous avez besoin de voir les permissions, le propriétaire, l'heure de modification, et les informations sur la taille dans l'affichage du répertoire.
Dans l'exemple suivant, nous utilisons l'option -l pour afficher mon répertoire /usr.
$ ls -l /usr drwxr-xr-x 7 root root 168 Nov 24 14:02 X11R6 drwxr-xr-x 2 root root 14576 Dec 27 08:56 bin drwxr-xr-x 2 root root 8856 Dec 26 12:47 distfiles lrwxrwxrwx 1 root root 9 Dec 22 20:57 doc -> share/doc drwxr-xr-x 62 root root 1856 Dec 27 15:54 gentoo-x86 drwxr-xr-x 4 root root 152 Dec 12 23:10 i686-linux drwxr-xr-x 4 root root 96 Nov 24 13:17 i686-pc-linux-gnu drwxr-xr-x 54 root root 5992 Dec 24 22:30 include lrwxrwxrwx 1 root root 10 Dec 22 20:57 info -> share/info drwxr-xr-x 28 root root 13552 Dec 26 00:31 lib drwxr-xr-x 3 root root 72 Nov 25 00:34 libexec drwxr-xr-x 8 root root 240 Dec 22 20:57 local lrwxrwxrwx 1 root root 9 Dec 22 20:57 man -> share/man lrwxrwxrwx 1 root root 11 Dec 8 07:59 portage -> gentoo-x86/ drwxr-xr-x 60 root root 1864 Dec 8 07:55 portage.old drwxr-xr-x 3 root root 3096 Dec 22 20:57 sbin drwxr-xr-x 46 root root 1144 Dec 24 15:32 share drwxr-xr-x 8 root root 328 Dec 26 00:07 src drwxr-xr-x 6 root root 176 Nov 24 14:25 ssl lrwxrwxrwx 1 root root 10 Dec 22 20:57 tmp -> ../var/tmp
La première colonne affiche les informations sur les permissions de chaque objet de la liste. J'expliquerai bientôt comment interpréter ces informations. La colonne suivante liste le nombre de liens à chaque objet du système de fichier, mais nous y reviendrons plus tard. La troisième et quatrième colonne listent respectivement le propriétaire et le groupe. La cinquième colonne liste la taille de l'objet. La sixième colonne est la "dernière modification" ou "mtime" de l'objet. La dernière colonne est le nom de l'objet. Si ce fichier est un lien symbolique, vous verrez à la suite un -> et le chemin vers lequel pointe ce lien symbolique.
Examen des répertoires
Parfois, vous souhaitez observer les répertoires plutôt que leur contenu. Dans ce cas, vous pouvez spécifier l'option -d qui indiquera à ls d'observer les répertoires plutôt que leur contenu :
$ ls -dl /usr /usr/bin /usr/X11R6/bin ../share drwxr-xr-x 4 root root 96 Dec 18 18:17 ../share drwxr-xr-x 17 root root 576 Dec 24 09:03 /usr drwxr-xr-x 2 root root 3192 Dec 26 12:52 /usr/X11R6/bin drwxr-xr-x 2 root root 14576 Dec 27 08:56 /usr/bin
Listes récursives et inodes
Vous pouvez donc utilisez -dpour observer un répertoire, mais également -R pour faire le contraire : c'est à dire pas simplement lister le contenu d'un répertoire, mais également, de façon récursive, tous les fichiers et répertoires à l'intérieur de celui-ci ! Nous ne présenterons pas d'exemple de cette commande (car généralement assez volumineux), mais vous pouvez essayer quelques ls -R et ls -lR pour comprendre leur fonctionnement.
Enfin, l'option -i peut être utilisée pour afficher l'inode des objets du système de fichier dans la liste :
$ ls -i /usr
1409 X11R6 314258 i686-linux 43090 libexec 13394 sbin
1417 bin 1513 i686-pc-linux-gnu 5120 local 13408 share
8316 distfiles 1517 include 776 man 23779 src
43 doc 1386 info 93892 portage 36737 ssl
70744 gentoo-x86 1585 lib 5132 portage.old 784 tmp
Comprendre les inodes
Chaque objet du système de fichier se voit attribuer un indice unique, appelé l'inode. Cela peut sembler trivial, mais la compréhension des inodes est essentielle pour comprendre beaucoup d'opérations du système de fichiers. Par exemple, considérons les liens . et .. qui apparaissent dans chaque répertoire. Pour bien comprendre ce qu'est en fait le répertoire .. , nous allons d'abord afficher l'inode du répertoire /usr/local :
$ ls -id /usr/local 5120 /usr/local
Le répertoire /usr/local a pour numéro d'inode 5120. Regardons maintenant l'inode du répertoire /usr/local/bin/.. :
$ ls -id /usr/local/bin/.. 5120 /usr/local/bin/..
Comme vous pouvez le voir, /usr/local/bin/.. a le même numéro d'inode que /usr/local/ ! Voilà une révélation surprenante. Jusqu'ici, nous considérions que /usr/local était le répertoire. Maintenant, nous découvrons que l'inode 5120 est en fait un répertoire, et nous avons trouvé deux entrées à ce répertoire (appelés liens) qui pointent vers cet inode. Aussi bien /usr/local que /usr/local/bin/.. sont des liens vers l'inode 5120. L'inode 5120 existe à un seul endroit sur le disque, mais plusieurs liens pointent vers lui. L'inode 5120 est la véritable entrée sur le disque.
En fait, nous pouvons voir le nombre total de fois où l'inode 5120 est référencé en utilisant la commandels -dl:
$ ls -dl /usr/local drwxr-xr-x 8 root root 240 Dec 22 20:57 /usr/local
Si nous regardons la seconde colonne, nous pouvons voir que le répertoire /usr/local (inode 5120) est référencé 8 fois. Sur mon système, voici les différents chemins qui font référence à cet inode :
/usr/local /usr/local/. /usr/local/bin/.. /usr/local/games/.. /usr/local/lib/.. /usr/local/sbin/.. /usr/local/share/.. /usr/local/src/..
mkdir
Regardons rapidement la commande mkdir, qui peut être utilisée pour créer de nouveaux répertoires. L'exemple suivant crée trois nouveaux répertoires, tic, tac et toe, dans /tmp :
$ cd /tmp $ mkdir tic tac toe
Par défaut, la commande mkdir ne crée pas les répertoires parents pour vous ; tout le chemin jusqu'à l'avant dernier élément doit exister. Donc, si vous voulez créer le répertoire won/der/ful, vous devrez utiliser trois fois la commande mkdir :
$ mkdir won/der/ful mkdir: cannot create directory `won/der/ful': No such file or directory $ mkdir won $ mkdir won/der $ mkdir won/der/ful
Cependant, mkdir dispose de l'option -p qui permet de créer les répertoires parents manquants, comme vous pouvez le voir :
$ mkdir -p easy/as/pie
C'est vraiment très pratique. Pour en apprendre plus sur la commande mkdir, tapez man mkdir pour lire la page de manuel. Ceci est valable pour presque toutes les commandes présentées ici (par exemple man ls), sauf pour cd, qui est une commande interne au bash.
touch
Nous allons maintenant regarder les commandes cp et mv, qui permettent de copier, renommer et déplacer des fichiers et répertoires. Pour commencer cette présentation, nous utilisons la commande touch pour créer un fichier dans /tmp :
$ cd /tmp $ touch copyme
La commande touch met à jour le "mtime" d'un fichier existant (souvenez vous la sixième colonne de la sortie de ls -l). Si le fichier n'existe pas, alors un nouveau fichier vide est créé. Vous devriez maintenant avoir un fichier /tmp/copyme de taille nulle.
echo
Maintenant que le fichier existe, ajoutons lui quelques données. Nous pouvons faire cela avec la commande echo, qui affiche ses arguments sur la sortie standard. Tout d'abord, la commande echo par elle même :
$ echo "firstfile" firstfile
Et la même commande en redirigeant sa sortie dans le fichier copyme :
$ echo "firstfile" > copyme
TLe symbole supérieur indique au shell qu'il faut écrire la sortie de la commande echo dans le fichier copyme. Le fichier sera créé s'il n'existe pas, et sera écrasé s'il existe. En tapant ls -l, nous pouvons voir que le fichier copyme fait 10 octets, maintenant qu'il contient le mot firstfile et celui de nouvelle ligne :
$ ls -l copyme -rw-r--r-- 1 root root 10 Dec 28 14:13 copyme
cat et cp
Pour afficher le contenu de ce fichier sur le terminal, nous pouvons utiliser la commande cat :
$ cat copyme firstfile
Nous pouvons alors utiliser simplement la commande cp pour créer un fichier copiedme à partir du fichier original copyme :
$ cp copyme copiedme
Nous pouvons nous assurer qu'il s'agit bien de deux fichiers différents en observant leurs inodes :
$ ls -i copyme copiedme 648284 copiedme 650704 copyme
mv
Utilisons la commande mv pour renommer "copiedme" en "movedme". L'inode restera le même ; cependant, le nom de fichier qui pointe vers cet inode changera.
$ mv copiedme movedme $ ls -i movedme 648284 movedme
L'inode du fichier déplacé restera le même tant que le fichier de destination restera sur le même système de fichiers que le fichier source. Nous regarderons de plus près le système de fichiers dans Linux Fundamentals, Part 3.
Pendant que nous parlons de mv, voyons une autre façon d'utiliser cette commande. En plus de renommer des fichiers, la commande mv permet de déplacer un ou plusieurs fichiers vers une autre destination dans l'arborescence des répertoires. Par exemple, pour déplacer /var/tmp/myfile.txt vers /home/drobbins (qui est mon répertoire personnel), je peux taper :
$ mv /var/tmp/myfile.txt /home/drobbins
Après avoir tapé cette commande, myfile.txt sera déplacé vers /home/drobbins/myfile.txt. Et si /home/drobbins est sur un système de fichier différent de /var/tmp, la commande mv copiera le fichier myfile.txt vers le nouveau système de fichier et l'effacera de l'ancien système de fichier. Comme vous pouvez le deviner, lorsque myfile.txt est déplacé entre différents systèmes de fichiers, le fichier myfile.txt au nouvel emplacement disposera d'un nouvel inode. Ceci vient du fait que chaque système de fichier doit avoir son propre jeu de numéros d'inodes.
Nous pouvons également utiliser la commande mv pour déplacer plusieurs fichiers vers une même destination. Par exemple, pour déplacer myfile1.txt et myarticle3.txt vers /home/drobbins, je peux taper :
$ mv /var/tmp/myfile1.txt /var/tmp/myarticle3.txt /home/drobbins
Creating Links and Removing Files
Hard links
We've mentioned the term "link" when referring to the relationship between directory entries (the "names" we type) and inodes (the index numbers on the underlying file system that we can usually ignore.) There are actually two kinds of links available on Linux. The kind we've discussed so far are called hard links. A given inode can have any number of hard links, and the inode will persist on the file system until all the hard links disappear. When the last hard link disappears and no program is holding the file open, Linux will delete the file automatically. New hard links can be created using the ln command:
$ cd /tmp $ touch firstlink $ ln firstlink secondlink $ ls -i firstlink secondlink 15782 firstlink 15782 secondlink
As you can see, hard links work on the inode level to point to a particular file. On Linux systems, hard links have several limitations. For one, you can only make hard links to files, not directories. That's right; even though . et .. are system-created hard links to directories, you (even as the "root" user) aren't allowed to create any of your own. The second limitation of hard links is that they can't span file systems; which would be the case if the file systems are on separate disk partitions. This means that you can't create a link from /usr/bin/bash to /bin/bash if your / and /usr directories exist on separate disk partitions.
Symbolic links
In practice, symbolic links (or symlinks) are used more often than hard links. Symlinks are a special file type where the link refers to another file by name, rather than directly to the inode. Symlinks do not prevent a file from being deleted; if the target file disappears, then the symlink will just be unusable, or broken.
A symbolic link can be created by passing the -s option to ln.
$ ln -s secondlink thirdlink $ ls -l firstlink secondlink thirdlink -rw-rw-r-- 2 agriffis agriffis 0 Dec 31 19:08 firstlink -rw-rw-r-- 2 agriffis agriffis 0 Dec 31 19:08 secondlink lrwxrwxrwx 1 agriffis agriffis 10 Dec 31 19:39 thirdlink -> secondlink
Symbolic links can be distinguished in ls -l output from normal files in three ways. First, notice that the first column contains an l character to signify the symbolic link. Second, the size of the symbolic link is the number of characters in the target (secondlink, in this case). Third, the last column of the output displays the target filename preceded by a cute little ->.
Symlinks in-depth
Symbolic links are generally more flexible than hard links. You can create a symbolic link to any type of file system object, including directories. And because the implementation of symbolic links is based on paths (not inodes), it's perfectly fine to create a symbolic link that points to an object on another physical file system; that is, a different disk partition. However, this fact can also make symbolic links tricky to understand.
Consider a situation where we want to create a link in /tmp that points to /usr/local/bin. Should we type this:
$ ln -s /usr/local/bin bin1 $ ls -l bin1 lrwxrwxrwx 1 root root 14 Jan 1 15:42 bin1 -> /usr/local/bin
Or alternatively:
$ ln -s ../usr/local/bin bin2 $ ls -l bin2 lrwxrwxrwx 1 root root 16 Jan 1 15:43 bin2 -> ../usr/local/bin
As you can see, both symbolic links point to the same directory. However, if our second symbolic link is ever moved to another directory, it will be "broken" because of the relative path:
$ ls -l bin2 lrwxrwxrwx 1 root root 16 Jan 1 15:43 bin2 -> ../usr/local/bin $ mkdir mynewdir $ mv bin2 mynewdir $ cd mynewdir $ cd bin2 bash: cd: bin2: No such file or directory
Because the directory /tmp/usr/local/bin doesn't exist, we can no longer change directories into bin2; in other words, bin2 is now broken.
For this reason, it is sometimes a good idea to avoid creating symbolic links with relative path information. However, there are many cases where relative symbolic links come in handy. Consider an example where you want to create an alternate name for a program in /usr/bin:
# ls -l /usr/bin/keychain -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain
As the root user, you may want to create an alternate name for "keychain", such as "kc". In this example, we have root access, as evidenced by our bash prompt changing to "#". We need root access because normal users aren't able to create files in /usr/bin. As root, we could create an alternate name for keychain as follows:
# cd /usr/bin # ln -s /usr/bin/keychain kc # ls -l keychain -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/bin/keychain # ls -l kc lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain
In this example, we created a symbolic link called kc that points to the file /usr/bin/keychain.
While this solution will work, it will create problems if we decide that we want to move both files, /usr/bin/keychain and /usr/bin/kc to /usr/local/bin:
# mv /usr/bin/keychain /usr/bin/kc /usr/local/bin # ls -l /usr/local/bin/keychain -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain # ls -l /usr/local/bin/kc lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> /usr/bin/keychain
Because we used an absolute path in our symbolic link, our kc symlink is still pointing to /usr/bin/keychain, which no longer exists since we moved /usr/bin/keychain to /usr/local/bin.
That means that kc is now a broken symlink. Both relative and absolute paths in symbolic links have their merits, and you should use a type of path that's appropriate for your particular application. Often, either a relative or absolute path will work just fine. The following example would have worked even after both files were moved:
# cd /usr/bin # ln -s keychain kc # ls -l kc lrwxrwxrwx 1 root root 8 Jan 5 12:40 kc -> keychain # mv keychain kc /usr/local/bin # ls -l /usr/local/bin/keychain -rwxr-xr-x 1 root root 10150 Dec 12 20:09 /usr/local/bin/keychain # ls -l /usr/local/bin/kc lrwxrwxrwx 1 root root 17 Mar 27 17:44 kc -> keychain
Now, we can run the keychain program by typing /usr/local/bin/kc. /usr/local/bin/kc points to the program keychain in the same directory as kc.
rm
Now that we know how to use cp, mv, and ln, it's time to learn how to remove objects from the file system. Normally, this is done with the rm command. To remove files, simply specify them on the command line:
$ cd /tmp $ touch file1 file2 $ ls -l file1 file2 -rw-r--r-- 1 root root 0 Jan 1 16:41 file1 -rw-r--r-- 1 root root 0 Jan 1 16:41 file2 $ rm file1 file2 $ ls -l file1 file2 ls: file1: No such file or directory ls: file2: No such file or directory
Note that under Linux, once a file is rm'ed, it's typically gone forever. For this reason, many junior system administrators will use the -i option when removing files. The -i option tells rm to remove all files in interactive mode -- that is, prompt before removing any file. For example:
$ rm -i file1 file2 rm: remove regular empty file `file1'? y rm: remove regular empty file `file2'? y
In the above example, the rm command prompted whether or not the specified files should *really* be deleted. In order for them to be deleted, I had to type "y" and Enter twice. If I had typed "n", the file would not have been removed. Or, if I had done something really wrong, I could have typed Control-C to abort the rm -i command entirely -- all before it is able to do any potential damage to my system.
If you are still getting used to the rm command, it can be useful to add the following line to your ~/.bashrc file using your favorite text editor, and then log out and log back in. Then, any time you type rm, the bash shell will convert it automatically to an rm -i command. That way, rm will always work in interactive mode:
alias rm="rm -i"
rmdir
To remove directories, you have two options. You can remove all the objects inside the directory and then use rmdir to remove the directory itself:
$ mkdir mydir $ touch mydir/file1 $ rm mydir/file1 $ rmdir mydir
This method is commonly referred to as "directory removal for suckers." All real power users and administrators worth their salt use the much more convenient rm -rf command, covered next.
The best way to remove a directory is to use the recursive force options of the rm command to tell rm to remove the directory you specify, as well as all objects contained in the directory:
$ rm -rf mydir
Generally, rm -rf is the preferred method of removing a directory tree. Be very careful when using rm -rf, since its power can be used for both good and evil :)
Using Wild cards
Introducing Wild cards
In your day-to-day Linux use, there are many times when you may need to perform a single operation (such as rm) on many file system objects at once. In these situations, it can often be cumbersome to type in many files on the command line:
$ rm file1 file2 file3 file4 file5 file6 file7 file8
To solve this problem, you can take advantage of Linux' built-in wild card support. This support, also called "globbing" (for historical reasons), allows you to specify multiple files at once by using a wildcard pattern. Bash and other Linux commands will interpret this pattern by looking on disk and finding any files that match it. So, if you had files file1 through file8 in the current working directory, you could remove these files by typing:
$ rm file[1-8]
Or if you simply wanted to remove all files whose names begin with file as well as any file named file, you could type:
$ rm file*
The * wildcard matches any character or sequence of characters, or even "no character." Of course, glob wildcards can be used for more than simply removing files, as we'll see in the next panel.
Understanding non-matches
If you wanted to list all the file system objects in /etc beginning with g as well as any file called g, you could type:
$ ls -d /etc/g* /etc/gconf /etc/ggi /etc/gimp /etc/gnome /etc/gnome-vfs-mime-magic /etc/gpm /etc/group /etc/group-
Now, what happens if you specify a pattern that doesn't match any file system objects? In the following example, we try to list all the files in /usr/bin that begin with asdf and end with jkl, including potentially the file asdfjkl:
$ ls -d /usr/bin/asdf*jkl ls: /usr/bin/asdf*jkl: No such file or directory
Here's what happened. Normally, when we specify a pattern, that pattern matches one or more files on the underlying file system, and bash replaces the pattern with a space-separated list of all matching objects. However, when the pattern doesn't produce any matches, bash leaves the argument, wild cards and all, as-is. So, then ls can't find the file /usr/bin/asdf*jkl and it gives us an error. The operative rule here is that glob patterns are expanded only if they match objects in the file system. Otherwise they remain as is and are passed literally to the program you're calling.
Wild card syntax: * and ?
Now that we've seen how globbing works, we should look at wild card syntax. You can use special characters for wild card expansion:
* will match zero or more characters. It means "anything can go here, including nothing". Examples:
- /etc/g* matches all files in /etc that begin with g, or a file called g.
- /tmp/my*1 matches all files in /tmp that begin with my and end with 1, including the file my1.
? matches any single character. Examples:
- myfile? matches any file whose name consists of myfile followed by a single character
- /tmp/notes?txt would match both /tmp/notes.txt and /tmp/notes_txt, if they exist
Wild card syntax: []
This wild card is like a ?, but it allows more specificity. To use this wild card, place any characters you'd like to match inside the []. The resultant expression will match a single occurrence of any of these characters. You can also use - to specify a range, and even combine ranges. Examples:
- myfile[12] will match myfile1 and myfile2. The wild card will be expanded as long as at least one of these files exists in the current directory.
- [Cc]hange[Ll]og will match Changelog, ChangeLog, changeLog, and changelog. As you can see, using bracket wild cards can be useful for matching variations in capitalization.
- ls /etc/[0-9]* will list all files in /etc that begin with a number.
- ls /tmp/[A-Za-z]* will list all files in /tmp that begin with an upper or lower-case letter.
The [!] construct is similar to the [] construct, except rather than matching any characters inside the brackets, it'll match any character, as long as it is not listed between the [! and ]. Example:
- rm myfile[!9] will remove all files named myfile plus a single character, except for myfile9
Wild card caveats
Here are some caveats to watch out for when using wild cards. Since bash treats wild card-related characters (?, [, ], and *) specially, you need to take special care when typing in an argument to a command that contains these characters. For example, if you want to create a file that contains the string [fo]*, the following command may not do what you want:
$ echo [fo]* > /tmp/mynewfile.txt
If the pattern [fo]* matches any files in the current working directory, then you'll find the names of those files inside /tmp/mynewfile.txt rather than a literal [fo]* like you were expecting. The solution? Well, one approach is to surround your characters with single quotes, which tell bash to perform absolutely no wild card expansion on them:
$ echo '[fo]*' > /tmp/mynewfile.txt
Using this approach, your new file will contain a literal [fo]* as expected. Alternatively, you could use backslash escaping to tell bash that [, ], and * should be treated literally rather than as wild cards:
$ echo \[fo\]\* > /tmp/mynewfile.txt
Both approaches (single quotes and backslash escaping) have the same effect. Since we're talking about backslash expansion, now would be a good time to mention that in order to specify a literal \, you can either enclose it in single quotes as well, or type \\ instead (it will be expanded to \).
Double quotes will work similarly to single quotes, but will still allow bash to do some limited expansion. Therefore, single quotes are your best bet when you are truly interested in passing literal text to a command. For more information on wild card expansion, type man 7 glob. For more information on quoting in bash, type man 8 glob and read the section titled QUOTING. If you're planning to take the LPI exams, consider this a homework assignment :)
Summary and Resources
Summary
Congratulations; you've reached the end of our review of Linux fundamentals! I hope that it has helped you to firm up your foundational Linux knowledge. The topics you've learned here, including the basics of bash, basic Linux commands, links, and wild cards, have laid the groundwork for our next tutorial on basic administration, in which we'll cover topics like regular expressions, ownership and permissions, user account management, and more.
By continuing in this tutorial series, you'll soon be ready to attain your LPIC Level 1 Certification from the Linux Professional Institute. Speaking of LPIC certification, if this is something you're interested in, then we recommend that you study the Resources in the next panel, which have been carefully selected to augment the material covered in this tutorial.
Resources
Be sure to read the other articles in this series:
In the "Bash by Example" article series, Daniel shows you how to use bash programming constructs to write your own bash scripts. This series (particularly Parts 1 and 2) will be good preparation for the LPIC Level 1 exam:
- Bash by Example, Part 1: Fundamental programming in the Bourne-again shell
- Bash by Example, Part 2: More bash programming fundamentals
- Bash by Example, Part 3: Exploring the ebuild system
</translate>
Browse all our available articles below. Use the search field to search for topics and keywords in real-time.