Difference between revisions of "Linux Fundamentals, Part 1/fr-fr"

From Funtoo
Jump to navigation Jump to search
(Add categories)
(Creating links and removing files - in French now)
 
(One intermediate revision by the same user not shown)
Line 314: Line 314:
$ mv /var/tmp/myfile1.txt /var/tmp/myarticle3.txt /home/drobbins
$ mv /var/tmp/myfile1.txt /var/tmp/myarticle3.txt /home/drobbins
</pre>
</pre>
==  Création des liens et suppression de fichier ==
=== Liens physiques ===
Nous avons mentionné le terme lien pour parler de la relation entre des entrées de répertoires (les "noms" que nous tapons) et les inodes (les nombres dans l'index du système de fichiers dont on peut généralement ne pas tenir compte). Il y a en réalité deux types de liens sur Linux. Ceux dont nous avons parlé sont les liens physiques. À un inode correspond un certain nombre de liens physiques, et cet inode existe sur le système de fichiers jusqu'à ce qu'il n'y ait plus de lien physique. Lorsque le dernier lien disparait et qu'aucun programme ne laisse le fichier ouvert, Linux efface ce fichier automatiquement. De nouveaux liens durs peuvent être créés avec la commande <span style="color:green">ln</span> :
<pre>
$ cd /tmp
$ touch firstlink
$ ln firstlink secondlink
$ ls -i firstlink secondlink
  15782 firstlink    15782 secondlink
</pre>
Comme vous pouvez le voir, les liens physiques fonctionnent au niveau de l'inode pour un fichier donné. Sur les systèmes Linux, les liens physiques ont certaines limitations. La première est que vous pouvez créer des liens physiques uniquement vers des fichiers, pas vers des répertoires. Entendu, cependant . et .. sont des liens durs vers des répertoires créés par le système, et vous (même en tant qu'utilisateur root) n'avez pas le droit de créer les vôtres. La seconde limitation est que les liens physiques ne peuvent pas sortir d'un système de fichiers ; c'est le cas si votre arborescence est répartie sur différentes partitions. Autrement dit, vous ne pouvez pas créer un lien de /usr/bin/bash sur /bin/bash si vos répertoires / et /usr sont sur des systèmes de fichiers différents.
=== Liens symboliques ===
En pratique, les liens symboliques sont plus utilisés que les liens durs. Les liens symboliques sont des fichiers spéciaux pour lesquels le lien vers un fichier se réfère à un chemin et non plus directement à partir de l'inode. Les liens symboliques n'empêchent pas l'effacement d'un fichier ; si la cible disparaît, alors le lien symbolique sera inutilisable ou cassé.
Un lien symbolique est créé en utilisant l'option -s de <span style="color:green">ln</span> :
<pre>
$ 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
</pre>
Les liens symboliques peuvent être reconnus, avec la commande <span style="color:green">ls -l</span>, de trois façon. Tout d'abord, vous noterez que la première colonne contient le caractère l qui signifie qu'il s'agit d'un lien symbolique. Ensuite, la taille du lien symbolique correspond au nombre de caractères de la cible (secondlink dans ce cas). Enfin, la dernière colonne affiche le nom de la cible du lien précédé par ->.
===  Les liens symboliques en détails ===
Les liens symboliques sont généralement plus flexibles que les liens durs. Vous pouvez créer un lien symbolique vers n'importe quel type d'objet du système de fichier, y compris les répertoires. Et parce que l'implémentation des liens symboliques est basée sur les chemins (et non les inodes), il est parfaitement possible de créer un lien symbolique qui pointe vers un objet d'un autre système de fichiers, comme une autre partition.  Cependant, cela peut rendre les liens symboliques difficiles à comprendre.
Considérons une situation où nous voulons créer un lien dans /tmp qui pointe vers /usr/local/bin.  Nous pourrions taper :
<pre>
$ ln -s /usr/local/bin bin1
$ ls -l bin1
lrwxrwxrwx    1 root    root          14 Jan  1 15:42 bin1 -> /usr/local/bin
</pre>
Ou encore :
<pre>
$ ln -s ../usr/local/bin bin2
$ ls -l bin2
lrwxrwxrwx    1 root    root          16 Jan  1 15:43 bin2 -> ../usr/local/bin
</pre>
Comme vous pouvez le voir, les deux liens symboliques pointent vers le même répertoire. Cependant, si votre second lien symbolique venait à être déplacé vers un autre répertoire, il serait cassé à cause du chemin relatif :
<pre>
$ 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
</pre>
Comme le répertoire /tmp/usr/local/bin n'existe pas, vous ne pouvez plus aller dans bin2 ; en d'autres mots, bin2 est maintenant cassé.
C'est pour cela qu'il vaut parfois mieux éviter de créer des liens symboliques en utilisant des chemins relatifs.  Cependant, il y a de nombreux cas où les liens symboliques relatifs sont pratiques. Prenons l'exemple où vous créez un nom alternatif pour un programme dans /usr/bin :
<pre>
# ls -l /usr/bin/keychain
-rwxr-xr-x    1 root    root        10150 Dec 12 20:09 /usr/bin/keychain
</pre>
En tant qu'utilisateur root, vous souhaitez peut être créer un nom alternatif pour "keychain", par exemple "kc".. Dans ce cas, nous avons les droits root, comme l'indique l'invite de commande du bash qui est devenue "#". Vous avez besoin des droits root car les utilisateurs normaux ne peut pas créer de fichier dans /usr/bin. En tant que root, vous pouvez créer un nom alternatif à keychain de la façon suivante :
<pre>
# 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
</pre>
Dans cet exemple, nous avons créé un lien symbolique appelé kc qui pointe vers le fichier /usr/bin/keychain.
Bien que cette solution fonctionne, elle peut poser problème si nous décidons de déplacer les deux fichiers /usr/bin/keychain et /usr/bin/kc vers /usr/local/bin :
<pre>
# 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
</pre>
Comme nous avons utilisé de chemin absolu dans notre lien symbolique, notre lien kc pointe toujours vers /usr/bin/keychain, qui n'existe plus puisqu'il a été déplacé de /usr/bin/keychain vers /usr/local/bin.
En d'autres termes, le lien kc est cassé (sans jeu de mot). Les deux types de chemins, relatif et absolu, ont leurs propres avantages, que vous devrez choisir suivant vos applications.  Très souvent, les chemins relatifs et absolus fonctionnent parfaitement bien. L'exemple suivant aurait fonctionné après le déplacement des fichiers :
<pre>
# 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
</pre>
Nous pouvons maintenant lancer le programme keychain en tapant /usr/local/bin/kc. /usr/local/bin/kc pointe vers le programme keychain, dans le même répertoire que kc.
=== rm ===
Maintenant que nous savons utiliser cp, mv et ln, il est temps d'apprendre comment supprimer des objets du système de fichiers. Normalement, c'est ce que fait la commande rm. Pour supprimer des fichiers, il faut simplement les spécifier sur la ligne de commande :
<pre>
$ 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
</pre>
Remarquons que sous Linux, la suppresion d'un fichier est définitive. C'est pour cette raison que beaucoup de jeunes administrateurs système utilisent l'option -i lorsqu'ils suppriment des fichiers. L'option -i indique à rm d'effacer les fichiers en mode interactif, et de demander avant d'effacer les fichiers. Par exemple :
<pre>
$ rm -i file1 file2
rm: remove regular empty file `file1'? y
rm: remove regular empty file `file2'? y
</pre>
Dans l'exemple ci-dessus, la commande rm demande confirmation avant d'effacer "réellement" le fichier. Afin de les supprimer, j'ai dû taper "y" et Entrée deux fois. Si j'avais tapé "n", le fichier n'aurait pas été supprimé. Et si j'avais fait une grosse erreur, j'aurais pu taper Control-C pour annuler complètement la commande rm -i. Tout ce qui est fait avant peut potentiellement causer des dégâts sur mon système.
Si vous êtes déjà habitué à la commande rm, il peut être pratique d'ajouter la ligne suivante dans votre fichier ~.bashrc avec votre éditeur de texte favori, puis vous déconnecter et vous reconnecter (NdT : ou encore taper source ~/.bashrc). Ensuite, à chaque fois que vous taperez rm, le bash convertira automatiquement votre commande en rm -i. De cette façon, rm fonctionnera toujours en mode interactif :
<pre>
alias rm="rm -i"
</pre>
=== rmdir ===
Pour supprimer des répertoires, vous avez deux options. Vous pouvez supprimer tous les objets à l'intérieur de ce répertoire, et ensuite utiliser la commande <span style="color:green">rmdir</span> pour supprimer les répertoire lui même :
<pre>
$ mkdir mydir
$ touch mydir/file1
$ rm mydir/file1
$ rmdir mydir
</pre>
Cette méthode est connue comme "la suppression de répertoires pour les glands". Tous les utilisateurs et administrateurs avancés préfèrent utiliser la commande <span style="color:green">rm -rf</span>, bien plus pratique comme nous allons le voir.
Le meilleur moyen de supprimer un répertoire est d'utiliser les options récursive et forcée de la commande rm, ce qui permet à la commande rm de supprimer le répertoire choisi, ainsi que les objets qu'il contient :
<pre>
$ rm -rf mydir
</pre>
Géneralement, rm -rf est utilisé pour supprimer une arborescence de répertoires. Soyez très prudent lors de l'utilisation de la commande rm -rf dont la puissance peut permettre le meilleur comme le pire :-)
== 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:
<pre>
$ rm file1 file2 file3 file4 file5 file6 file7 file8
</pre>
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:
<pre>
$ rm file[1-8]
</pre>
Or if you simply wanted to remove all files whose names begin with file as well as any file named file, you could type:
<pre>
$ rm file*
</pre>
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:
<pre>
$ ls -d /etc/g*
/etc/gconf  /etc/ggi  /etc/gimp  /etc/gnome  /etc/gnome-vfs-mime-magic  /etc/gpm  /etc/group  /etc/group-
</pre>
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:
<pre>
$ ls -d /usr/bin/asdf*jkl
ls: /usr/bin/asdf*jkl: No such file or directory
</pre>
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:
<nowiki>*</nowiki> 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:
<pre>
$ echo [fo]* > /tmp/mynewfile.txt
</pre>
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:
<pre>
$ echo '[fo]*' > /tmp/mynewfile.txt
</pre>
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:
<pre>
$ echo \[fo\]\* > /tmp/mynewfile.txt
</pre>
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 \).
{{fancynote|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:
*[[Linux Fundamentals, Part 2]]
*[[Linux Fundamentals, Part 3]]
*[[Linux Fundamentals, Part 4]]
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>


__NOTOC__
__NOTOC__
Line 319: Line 545:
[[Category:Articles]]
[[Category:Articles]]
{{ArticleFooter}}
{{ArticleFooter}}
[[Category:fr_FR]

Latest revision as of 20:05, May 6, 2018


   Support Funtoo!
Get an awesome Funtoo container and support Funtoo! See Funtoo Containers for more information.

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  src
En 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 commande
ls -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

Création des liens et suppression de fichier

Liens physiques

Nous avons mentionné le terme lien pour parler de la relation entre des entrées de répertoires (les "noms" que nous tapons) et les inodes (les nombres dans l'index du système de fichiers dont on peut généralement ne pas tenir compte). Il y a en réalité deux types de liens sur Linux. Ceux dont nous avons parlé sont les liens physiques. À un inode correspond un certain nombre de liens physiques, et cet inode existe sur le système de fichiers jusqu'à ce qu'il n'y ait plus de lien physique. Lorsque le dernier lien disparait et qu'aucun programme ne laisse le fichier ouvert, Linux efface ce fichier automatiquement. De nouveaux liens durs peuvent être créés avec la commande ln :

$ cd /tmp
$ touch firstlink
$ ln firstlink secondlink
$ ls -i firstlink secondlink
  15782 firstlink    15782 secondlink

Comme vous pouvez le voir, les liens physiques fonctionnent au niveau de l'inode pour un fichier donné. Sur les systèmes Linux, les liens physiques ont certaines limitations. La première est que vous pouvez créer des liens physiques uniquement vers des fichiers, pas vers des répertoires. Entendu, cependant . et .. sont des liens durs vers des répertoires créés par le système, et vous (même en tant qu'utilisateur root) n'avez pas le droit de créer les vôtres. La seconde limitation est que les liens physiques ne peuvent pas sortir d'un système de fichiers ; c'est le cas si votre arborescence est répartie sur différentes partitions. Autrement dit, vous ne pouvez pas créer un lien de /usr/bin/bash sur /bin/bash si vos répertoires / et /usr sont sur des systèmes de fichiers différents.

Liens symboliques

En pratique, les liens symboliques sont plus utilisés que les liens durs. Les liens symboliques sont des fichiers spéciaux pour lesquels le lien vers un fichier se réfère à un chemin et non plus directement à partir de l'inode. Les liens symboliques n'empêchent pas l'effacement d'un fichier ; si la cible disparaît, alors le lien symbolique sera inutilisable ou cassé.

Un lien symbolique est créé en utilisant l'option -s de 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

Les liens symboliques peuvent être reconnus, avec la commande ls -l, de trois façon. Tout d'abord, vous noterez que la première colonne contient le caractère l qui signifie qu'il s'agit d'un lien symbolique. Ensuite, la taille du lien symbolique correspond au nombre de caractères de la cible (secondlink dans ce cas). Enfin, la dernière colonne affiche le nom de la cible du lien précédé par ->.

Les liens symboliques en détails

Les liens symboliques sont généralement plus flexibles que les liens durs. Vous pouvez créer un lien symbolique vers n'importe quel type d'objet du système de fichier, y compris les répertoires. Et parce que l'implémentation des liens symboliques est basée sur les chemins (et non les inodes), il est parfaitement possible de créer un lien symbolique qui pointe vers un objet d'un autre système de fichiers, comme une autre partition. Cependant, cela peut rendre les liens symboliques difficiles à comprendre.

Considérons une situation où nous voulons créer un lien dans /tmp qui pointe vers /usr/local/bin. Nous pourrions taper :

$ ln -s /usr/local/bin bin1
$ ls -l bin1
lrwxrwxrwx    1 root     root           14 Jan  1 15:42 bin1 -> /usr/local/bin

Ou encore :

$ ln -s ../usr/local/bin bin2
$ ls -l bin2
lrwxrwxrwx    1 root     root           16 Jan  1 15:43 bin2 -> ../usr/local/bin

Comme vous pouvez le voir, les deux liens symboliques pointent vers le même répertoire. Cependant, si votre second lien symbolique venait à être déplacé vers un autre répertoire, il serait cassé à cause du chemin relatif :

$ 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

Comme le répertoire /tmp/usr/local/bin n'existe pas, vous ne pouvez plus aller dans bin2 ; en d'autres mots, bin2 est maintenant cassé.

C'est pour cela qu'il vaut parfois mieux éviter de créer des liens symboliques en utilisant des chemins relatifs. Cependant, il y a de nombreux cas où les liens symboliques relatifs sont pratiques. Prenons l'exemple où vous créez un nom alternatif pour un programme dans /usr/bin :

# ls -l /usr/bin/keychain 
-rwxr-xr-x    1 root     root        10150 Dec 12 20:09 /usr/bin/keychain

En tant qu'utilisateur root, vous souhaitez peut être créer un nom alternatif pour "keychain", par exemple "kc".. Dans ce cas, nous avons les droits root, comme l'indique l'invite de commande du bash qui est devenue "#". Vous avez besoin des droits root car les utilisateurs normaux ne peut pas créer de fichier dans /usr/bin. En tant que root, vous pouvez créer un nom alternatif à keychain de la façon suivante :

# 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

Dans cet exemple, nous avons créé un lien symbolique appelé kc qui pointe vers le fichier /usr/bin/keychain.

Bien que cette solution fonctionne, elle peut poser problème si nous décidons de déplacer les deux fichiers /usr/bin/keychain et /usr/bin/kc vers /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

Comme nous avons utilisé de chemin absolu dans notre lien symbolique, notre lien kc pointe toujours vers /usr/bin/keychain, qui n'existe plus puisqu'il a été déplacé de /usr/bin/keychain vers /usr/local/bin.

En d'autres termes, le lien kc est cassé (sans jeu de mot). Les deux types de chemins, relatif et absolu, ont leurs propres avantages, que vous devrez choisir suivant vos applications. Très souvent, les chemins relatifs et absolus fonctionnent parfaitement bien. L'exemple suivant aurait fonctionné après le déplacement des fichiers :

# 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

Nous pouvons maintenant lancer le programme keychain en tapant /usr/local/bin/kc. /usr/local/bin/kc pointe vers le programme keychain, dans le même répertoire que kc.

rm

Maintenant que nous savons utiliser cp, mv et ln, il est temps d'apprendre comment supprimer des objets du système de fichiers. Normalement, c'est ce que fait la commande rm. Pour supprimer des fichiers, il faut simplement les spécifier sur la ligne de commande :

$ 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

Remarquons que sous Linux, la suppresion d'un fichier est définitive. C'est pour cette raison que beaucoup de jeunes administrateurs système utilisent l'option -i lorsqu'ils suppriment des fichiers. L'option -i indique à rm d'effacer les fichiers en mode interactif, et de demander avant d'effacer les fichiers. Par exemple :

$ rm -i file1 file2
rm: remove regular empty file `file1'? y
rm: remove regular empty file `file2'? y

Dans l'exemple ci-dessus, la commande rm demande confirmation avant d'effacer "réellement" le fichier. Afin de les supprimer, j'ai dû taper "y" et Entrée deux fois. Si j'avais tapé "n", le fichier n'aurait pas été supprimé. Et si j'avais fait une grosse erreur, j'aurais pu taper Control-C pour annuler complètement la commande rm -i. Tout ce qui est fait avant peut potentiellement causer des dégâts sur mon système.

Si vous êtes déjà habitué à la commande rm, il peut être pratique d'ajouter la ligne suivante dans votre fichier ~.bashrc avec votre éditeur de texte favori, puis vous déconnecter et vous reconnecter (NdT : ou encore taper source ~/.bashrc). Ensuite, à chaque fois que vous taperez rm, le bash convertira automatiquement votre commande en rm -i. De cette façon, rm fonctionnera toujours en mode interactif :

alias rm="rm -i"

rmdir

Pour supprimer des répertoires, vous avez deux options. Vous pouvez supprimer tous les objets à l'intérieur de ce répertoire, et ensuite utiliser la commande rmdir pour supprimer les répertoire lui même :

$ mkdir mydir
$ touch mydir/file1
$ rm mydir/file1
$ rmdir mydir

Cette méthode est connue comme "la suppression de répertoires pour les glands". Tous les utilisateurs et administrateurs avancés préfèrent utiliser la commande rm -rf, bien plus pratique comme nous allons le voir.

Le meilleur moyen de supprimer un répertoire est d'utiliser les options récursive et forcée de la commande rm, ce qui permet à la commande rm de supprimer le répertoire choisi, ainsi que les objets qu'il contient :

$ rm -rf mydir

Géneralement, rm -rf est utilisé pour supprimer une arborescence de répertoires. Soyez très prudent lors de l'utilisation de la commande rm -rf dont la puissance peut permettre le meilleur comme le pire :-)

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 \).

   Note

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:

</translate>


   Note

Browse all our available articles below. Use the search field to search for topics and keywords in real-time.

Article Subtitle
Article Subtitle
Awk by Example, Part 1 An intro to the great language with the strange name
Awk by Example, Part 2 Records, loops, and arrays
Awk by Example, Part 3 String functions and ... checkbooks?
Bash by Example, Part 1 Fundamental programming in the Bourne again shell (bash)
Bash by Example, Part 2 More bash programming fundamentals
Bash by Example, Part 3 Exploring the ebuild system
BTRFS Fun
Funtoo Filesystem Guide, Part 1 Journaling and ReiserFS
Funtoo Filesystem Guide, Part 2 Using ReiserFS and Linux
Funtoo Filesystem Guide, Part 3 Tmpfs and Bind Mounts
Funtoo Filesystem Guide, Part 4 Introducing Ext3
Funtoo Filesystem Guide, Part 5 Ext3 in Action
GUID Booting Guide
Learning Linux LVM, Part 1 Storage management magic with Logical Volume Management
Learning Linux LVM, Part 2 The cvs.gentoo.org upgrade
Libvirt
Linux Fundamentals, Part 1
Linux Fundamentals, Part 2
Linux Fundamentals, Part 3
Linux Fundamentals, Part 4
LVM Fun
Making the Distribution, Part 1
Making the Distribution, Part 2
Making the Distribution, Part 3
Maximum Swappage Getting the most out of swap
On screen annotation Write on top of apps on your screen
OpenSSH Key Management, Part 1 Understanding RSA/DSA Authentication
OpenSSH Key Management, Part 2 Introducing ssh-agent and keychain
OpenSSH Key Management, Part 3 Agent Forwarding
Partition Planning Tips Keeping things organized on disk
Partitioning in Action, Part 1 Moving /home
Partitioning in Action, Part 2 Consolidating data
POSIX Threads Explained, Part 1 A simple and nimble tool for memory sharing
POSIX Threads Explained, Part 2
POSIX Threads Explained, Part 3 Improve efficiency with condition variables
Sed by Example, Part 1
Sed by Example, Part 2
Sed by Example, Part 3
Successful booting with UUID Guide to use UUID for consistent booting.
The Gentoo.org Redesign, Part 1 A site reborn
The Gentoo.org Redesign, Part 2 The Documentation System
The Gentoo.org Redesign, Part 3 The New Main Pages
The Gentoo.org Redesign, Part 4 The Final Touch of XML
Traffic Control
Windows 10 Virtualization with KVM