105.1 Leçon 1
Certification : |
LPIC-1 |
---|---|
Version : |
5.0 |
Thème : |
105 Shells et scripts shell |
Objectif : |
105.1 Personnaliser et utiliser l’environnement shell |
Leçon : |
1 sur 3 |
Introduction
L’interpréteur de commandes (shell) est probablement l’outil le plus puissant d’un système Linux. Il peut être défini comme une interface entre l’utilisateur et le cœur du système d’exploitation. Le shell interprète les commandes saisies par l’utilisateur. C’est pourquoi tous les administrateurs système doivent savoir utiliser l’interpréteur de commandes. Comme nous le savons sans doute déjà, le Bourne Again Shell (Bash) est l’interpréteur de commandes utilisé par défaut par la grande majorité des distributions Linux.
Une fois qu’il est lancé, la première chose que fait Bash — tout comme n’importe quel autre shell d’ailleurs — c’est d’exécuter une série de scripts de démarrage. Ces scripts permettent de personnaliser l’environnement de la session. Certains scripts concernent la totalité du système alors que d’autres sont propres à l’utilisateur. Nous pouvons y intégrer nos préférences personnelles et les paramètres adaptés aux besoins des utilisateurs sous forme de variables, d’alias et de fonctions.
La séquence exacte de fichiers de démarrage dépend d’un paramètre très important : le type de shell. Jetons un œil aux différents types de shells qui existent.
Types de shell : interactif vs. non interactif et connexion vs. simple
Pour commencer, nous allons mettre au clair les concepts interactif et connexion dans le contexte du shell :
- Shells interactifs / non interactifs
-
Ce type de shell fait référence à l’interaction qui a lieu entre l’utilisateur et le shell. L’utilisateur fournit des données en tapant des commandes dans le terminal à l’aide du clavier ; l’interpréteur de commandes fournit des résultats en affichant des messages à l’écran.
- Shells de connexion / simples
-
Ce type de shell fait référence au cas de figure où un utilisateur accède à un système informatique en fournissant son identifiant et son mot de passe.
Les shells interactifs et non interactifs peuvent être des shells de connexion ou simples, et toute combinaison possible de ces types de shell a ses utilisations spécifiques.
Les shells de connexion interactifs sont lancés lorsque les utilisateurs se connectent au système. On les utilise pour personnaliser les configurations des utilisateurs en fonction de leurs besoins. Un bon exemple de ce type de shell serait celui d’un groupe d’utilisateurs appartenant au même service et qui ont besoin d’une variable particulière dans leurs sessions.
Les shells interactifs simples font référence à tous les autres shells ouverts par l’utilisateur une fois qu’il est connecté au système. Les utilisateurs se servent de ces interpréteurs de commandes pendant les sessions pour effectuer des tâches d’administration et de maintenance le réglage de l’heure, la définition de variables, la copie de fichiers, l’écriture de scripts, etc.
D’autre part, les shells non-interactifs ne requièrent aucune interaction humaine. Ces interpréteurs de commandes ne demandent aucune entrée à l’utilisateur et leur sortie — s’il y en a une — est généralement écrite dans un journal.
Les shells de connexion non interactifs sont aussi rares que peu commodes. Leur utilisation est marginale et nous ne les abordons ici que pour mieux comprendre le comportement de l’interpréteur de commandes. Quelques exemples insolites incluent le fait de forcer l’exécution d’un script à partir d’un shell de connexion avec /bin/bash --login <some_script>
ou de faire passer la sortie standard (stdout) d’une commande dans l’entrée standard (stdin) d’une connexion ssh :
<some_command> | ssh <some_user>@<some_server>
Quant au shell simple non interactif, il n’y a ni connexion ni interaction de la part de l’utilisateur, et nous faisons référence ici à l’utilisation de scripts automatisés. Ces scripts sont utilisés principalement pour effectuer des tâches administratives répétitives comme celles que l’on trouve habituellement dans les cronjobs. Dans ce cas, bash
ne lit aucun fichier de démarrage.
Ouvrir un terminal
Lorsque nous sommes dans un environnement de bureau, nous pouvons ouvrir une application de terminal ou basculer vers l’une des consoles du système. De ce fait, un nouveau shell est soit un shell pts
lorsqu’il est ouvert à partir d’un émulateur de terminal dans l’interface graphique, soit un shell tty
lorsqu’il est exécuté à partir d’une console système. Dans le premier cas, il ne s’agit pas d’un terminal mais d’un émulateur de terminal. Dans le contexte d’une session graphique, les émulateurs de terminal tels que gnome-terminal ou konsole sont riches en fonctionnalités et conviviaux par rapport aux terminaux de type texte. Parmi les émulateurs de terminal moins complets, on peut mentionner — entre autres — XTerm et sakura.
Les raccourcis clavier Ctrl+Alt+F1-F6 permettent d’accéder aux consoles qui ouvrent un shell de connexion interactif en mode texte. Ctrl+Alt+F7 ramène la session sur le bureau.
Note
|
|
Lancer un shell avec bash
Une fois que vous vous êtes connecté, tapez bash
dans un terminal pour lancer un nouvel interpréteur de commandes. Techniquement, ce shell est un processus enfant du shell en cours.
Lorsqu’on démarre le processus enfant bash
, on peut utiliser plusieurs options pour définir le type d’interpréteur de commandes que l’on veut initier. Voici quelques options fondamentales pour invoquer bash
:
bash -l
oubash --login
-
invoque un shell de connexion.
bash -i
-
invoque un shell interactif.
bash --noprofile
-
avec les shells de connexion ignorera à la fois le fichier de démarrage du système
/etc/profile
et les fichiers de démarrage au niveau utilisateur~/.bash_profile
,~/.bash_login
et~/.profile
. bash --norc
-
avec les shells interactifs ignorera à la fois le fichier de démarrage du système
/etc/bash.bashrc
et le fichier de démarrage de l’utilisateur~/.bashrc
. bash --rcfile <file>
-
avec les shells interactifs utilisera
<fichier>
comme fichier de démarrage en ignorant/etc/bash.bashrc
au niveau système et~/.bashrc
au niveau utilisateur.
Les différents fichiers de démarrage seront abordés ci-dessous.
Lancer un shell avec su
et sudo
Ces deux programmes similaires permettent d’obtenir des types de shells spécifiques :
su
-
Changer l’ID de l’utilisateur ou devenir superutilisateur (
root
). Cette commande permet d’invoquer les shells de connexion et des shells simples :-
su - user2
,su -l user2
ousu --login user2
lance un shell de connexion interactif en tant queuser2
. -
su user2
lance un shell interactif simple en tant queuser2
. -
su - root
ousu -
lance un shell de connexion interactif en tant queroot
. -
su root
ousu
lance un shell interactif simple en tant queroot
.
-
sudo
-
Exécuter des commandes sous une autre identité (y compris celle du super-utilisateur). Étant donné que cette commande est principalement utilisée pour obtenir temporairement les privilèges de
root
, l’utilisateur qui y a recours doit figurer dans le fichiersudoers
. Pour ajouter des utilisateurs àsudoers
, nous devons devenirroot
et ensuite exécuter :root@debian:~# usermod -aG sudo user2
Tout comme
su
,sudo
nous permet d’invoquer des shells de connexion ou des shells simples :-
sudo su - user2
,sudo su -l user2
ousudo su --login user2
lance un shell interactif de connexion en tant queuser2
. -
sudo su user2
lance un shell interactif simple en tant queuser2
. -
sudo -u user2 -s
lance un shell interactif simple en tant queuser2
. -
sudo su - root
ousudo su -
lance un shell interactif de connexion en tant queroot
. -
sudo -i
lance un shell interactif de connexion en tant queroot
. -
sudo -i <some_command>
lance un shell interactif de connexion en tant queroot
, exécute la commande et retourne à l’utilisateur initial. -
sudo su root
ousudo su
lance un shell interactif simple en tant queroot
. -
sudo -s
ousudo -u root -s
lance un shell simple en tant queroot
.
-
Lorsque nous utilisons su
ou sudo
, nous devons prendre en compte le contexte dans lequel nous démarrons un nouvel interpréteur de commandes : Est-ce que nous avons besoin de l’environnement de l’utilisateur cible ou non ? Si c’est le cas, nous utiliserons les options qui invoquent un shell de connexion ; dans le cas contraire, nous utiliserons celles qui invoquent un shell simple.
Quel type de shell avons-nous ?
Pour connaître le type de shell dans lequel nous travaillons, nous pouvons taper echo $0
dans le terminal et obtenir ce qui suit :
- Shell de connexion interactif
-
-bash
ou-su
- Shell interactif simple
-
bash
or/bin/bash
- Shell simple non-interactif (script)
-
<nom_du_script>
Combien de shells avons-nous ?
Pour voir combien de shells bash
sont lancés sur le système, nous pouvons utiliser la commande ps aux | grep bash
:
user2@debian:~$ ps aux | grep bash user2 5270 0.1 0.1 25532 5664 pts/0 Ss 23:03 0:00 bash user2 5411 0.3 0.1 25608 5268 tty1 S+ 23:03 0:00 -bash user2 5452 0.0 0.0 16760 940 pts/0 S+ 23:04 0:00 grep --color=auto bash
user2
sur le hôte debian
s’est connecté à une session graphique (GUI ou X Window System) et a ouvert gnome-terminal. Puis il a appuyé sur Ctrl+Alt+F1 pour ouvrir une session terminal tty
. Enfin, il est retourné dans la session graphique en appuyant sur Ctrl+Alt+F7 et a tapé la commande ps aux | grep bash
. Ainsi, l’affichage montre un shell interactif simple via l’émulateur de terminal (pts/0
) et un shell de connexion interactif via la console de texte (tty1
). Notez aussi que la dernière colonne de chaque ligne (la commande) est bash
pour le premier cas de figure et -bash
pour le second.
D’où les shells tirent leur configuration : les fichiers de démarrage
Maintenant que nous connaissons les différents types de shells que l’on peut trouver dans un système Linux, il est temps de voir les fichiers de démarrage propres à chaque type de shell. Notez que les scripts système ou globaux sont rangés dans le répertoire /etc/
alors que les scripts locaux ou propres à l’utilisateur se trouvent dans le répertoire personnel de l’utilisateur (~
). De plus, lorsqu’il y a plus d’un fichier à rechercher, une fois que l’un d’entre eux est trouvé et exécuté, les autres sont ignorés. Explorez et étudiez ces fichiers vous-même avec votre éditeur de texte préféré ou en tapant less <startup_file>
.
Note
|
Les fichiers de démarrage peuvent être classés en fichiers spécifiques à Bash (ceux qui sont limités uniquement aux configurations et commandes |
Shell de connexion interactif
Niveau global
/etc/profile
-
C’est le fichier
.profile
du système pour le shell Bourne et les shells compatibles Bourne (y comprisbash
). Au moyen d’une série d’instructionsif
, ce fichier définit un certain nombre de variables telles quePATH
etPS1
et prend en compte — s’ils existent — le fichier/etc/bash.bashrc
et ceux du répertoire/etc/profile.d
. /etc/profile.d/*
-
Ce répertoire est susceptible de contenir des scripts qui seront exécutés par
/etc/profile
.
Niveau local
~/.bash_profile
-
Ce fichier spécifique à Bash est utilisé pour configurer l’environnement utilisateur. Il peut également être utilisé pour prendre en compte
~/.bash_login
et~/.profile
. ~/.bash_login
-
Également spécifique à Bash, ce fichier ne sera exécuté qu’en l’absence de fichier
~/.bash_profile
. Son nom suggère qu’il est utilisé pour exécuter les commandes nécessaires à l’ouverture d’une session. ~/.profile
-
Ce fichier n’est pas spécifique à Bash et n’est utilisé que si les fichiers
~/.bash_profile
et~/.bash_login
n’existent pas — ce qui est normalement le cas. Ainsi, le rôle principal de~/.profile
consiste à vérifier si un shell Bash est en cours d’exécution et — si c’est le cas — à prendre en compte~/.bashrc
s’il existe. Il définit habituellement la variablePATH
de manière à inclure le répertoire privé~/bin
de l’utilisateur s’il existe. ~/.bash_logout
-
S’il existe, ce fichier spécifique à Bash effectue des opérations de nettoyage lors de la fermeture du shell. Cela peut s’avérer pratique pour les sessions distantes, par exemple.
Explorer les fichiers de configuration du shell de connexion interactif
Voyons quelques-uns de ces fichiers en action en modifiant /etc/profile
et /home/user2/.profile
. Nous ajoutons à chacun d’eux une ligne qui va signaler le fichier en cours d’exécution :
root@debian:~# echo 'echo Hello from /etc/profile' >> /etc/profile root@debian:~# echo 'echo Hello from ~/.profile' >> /home/user2/.profile
Note
|
Deux chevrons de redirection |
Ainsi, grâce à l’affichage des commandes echo
respectives, nous saurons à quel moment chacun de ces fichiers est lu et exécuté. Pour le vérifier, voyons ce qui se passe lorsque user2
se connecte via ssh
depuis une autre machine :
user2@debian:~$ ssh user2@192.168.1.6 user2@192.168.1.6's password: Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Nov 27 19:57:19 2018 from 192.168.1.10 Hello from /etc/profile Hello from /home/user2/.profile
Comme on peut le voir dans les deux dernières lignes, ça a marché. Par ailleurs, notez trois détails :
-
Le fichier global a été exécuté en premier.
-
Il n’y a pas de fichiers
.bash_profile
ou.bash_login
dans le répertoire personnel deuser2
. -
Le tilde (
~
) a été développé pour indiquer le chemin complet du fichier (/home/user2/.profile
).
Shell interactif simple
Niveau global
/etc/bash.bashrc
-
C’est le fichier
.bashrc
du système pour les shellsbash
interactifs. En l’exécutant,bash
s’assure qu’il est lancé de manière interactive, vérifie la taille de la fenêtre après chaque commande (en mettant à jour les valeurs deLINES
etCOLUMNS
si nécessaire) et définit quelques variables.
Niveau local
~/.bashrc
-
En dehors des tâches similaires à celles décrites pour
/etc/bash.bashrc
au niveau de l’utilisateur (comme la vérification de la taille de la fenêtre ou de l’exécution interactive), ce fichier spécifique à Bash définit habituellement quelques variables de l’historique et prend en compte~/.bash_aliases
s’il existe. En dehors de cela, ce fichier est normalement utilisé pour stocker les alias et les fonctions spécifiques de l’utilisateur.De même, il est intéressant de noter que
~/.bashrc
est lu sibash
détecte que son entrée standard (<stdin>
) est une connexion réseau, comme c’était le cas avec la connexion SSH dans l’exemple ci-dessus.
Explorer les fichiers de configuration du shell interactif simple
À présent, modifions /etc/bash.bashrc
et /home/user2/.bashrc
:
root@debian:~# echo 'echo Hello from /etc/bash.bashrc' >> /etc/bash.bashrc root@debian:~# echo 'echo Hello from ~/.bashrc' >> /home/user2/.bashrc
Voici ce qui se passe lorsque user2
démarre un nouveau shell :
user2@debian:~$ bash Hello from /etc/bash.bashrc Hello from /home/user2/.bashrc
Là encore, les deux fichiers ont été lus et exécutés.
Warning
|
N’oubliez pas qu’en raison de l’ordre d’exécution des fichiers, les fichiers locaux ont la primauté sur les fichiers globaux. |
Shell de connexion non-interactif
Un shell non-interactif avec les options -l
ou --login
est forcé de se comporter comme un shell de connexion. Les fichiers de démarrage à exécuter seront donc les mêmes que ceux du shell de connexion interactif.
Pour le prouver, écrivons un simple script shell et rendons-le exécutable. Nous n’allons pas inclure de shebang étant donné que nous allons invoquer l’exécutable bash (/bin/bash
avec l’option login) depuis la ligne de commande.
-
On crée le script
test.sh
avec la ligneecho 'Hello from a script'
pour prouver que le script s’exécute correctement :user2@debian:~$ echo "echo 'Hello from a script'" > test.sh
-
On rend notre script exécutable :
user2@debian:~$ chmod +x ./test.sh
-
Enfin, on invoque
bash
avec l’option-l
pour exécuter le script :user2@debian:~$ bash -l ./test.sh Hello from /etc/profile Hello from /home/user2/.profile Hello from a script
Ça marche ! Avant d’exécuter le script, la connexion a eu lieu et les fichiers
/etc/profile
et~/.profile
ont été exécutés.
Note
|
Nous aborderons le shebang et d’autres aspects des scripts shell dans les leçons à venir. |
Nous allons maintenant faire passer la sortie standard (stdout) de la commande echo
vers l’entrée standard (stdin) d’une connexion ssh
à l’aide d’un pipe (|
) :
user2@debian:~$ echo "Hello-from-a-noninteractive-login-shell" | ssh user2@192.168.1.6 Pseudo-terminal will not be allocated because stdin is not a terminal. user2@192.168.1.6's password: Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Hello from /etc/profile Hello from /home/user2/.profile -bash: line 1: Hello-from-a-noninteractive-login-shell: command not found
Là encore, /etc/profile
et ~/.profile
sont exécutés. À part ça, la première et la dernière ligne du résultat sont assez révélatrices du comportement du shell.
Shell simple non-interactif
Les scripts ne lisent aucun des fichiers mentionnés ci-dessus. Ils recherchent la variable d’environnement BASH_ENV
, développent sa valeur si nécessaire et l’utilisent comme nom d’un fichier de démarrage pour lire et exécuter des commandes. Nous verrons plus en détail les variables d’environnement dans la prochaine leçon.
Comme nous l’avons vu plus haut, /etc/profile
et ~/.profile
s’assurent que /etc/bash.bashrc
et ~/.bashrc
sont exécutés après une connexion réussie. Le résultat de la commande suivante illustre ce comportement :
root@debian:~# su - user2 Hello from /etc/bash.bashrc Hello from /etc/profile Hello from /home/user2/.bashrc Hello from /home/user2/.profile
Si l’on garde à l’esprit les lignes que nous avons précédemment ajoutées aux scripts de démarrage — et si l’on invoque un shell de connexion interactif au niveau utilisateur avec su - user2
— les quatre lignes de résultat peuvent être expliquées de la sorte :
-
Hello from /etc/bash.bashrc
signifie que/etc/profile
a pris en compte/etc/bash.bashrc
. -
Hello from /etc/profile
signifie que/etc/profile
a été entièrement lu et exécuté. -
Hello from /home/user2/.bashrc
signifie que~/.profile
a pris en compte~/.bashrc
. -
Hello from /home/user2/.profile
signifie que~/.profile
a été entièrement lu et exécuté.
Notez qu’avec su - <username>
(ainsi que su -l <username>
et su --login <username>
) nous garantissons l’invocation d’un shell de connexion, alors que su <username>
n’aurait invoqué que /etc/bash.bashrc
et ~/.bashrc
.
Sourcer des fichiers
Dans les sections précédentes, nous avons vu que certains scripts de démarrage incluent ou exécutent d’autres scripts. Ce mécanisme de prise en compte, appelé sourcing, est présenté dans cette section.
Sourcer des fichiers avec .
Le point (.
) se trouve normalement dans les fichiers de démarrage.
Dans le fichier .profile
de notre serveur Debian, nous pouvons trouver — par exemple — le bloc suivant :
# include .bashrc if it exists if [ -f "$HOME/.bashrc" ]; then . "$HOME/.bashrc" fi
Nous avons déjà vu comment l’exécution d’un script peut conduire à celle d’un autre. Ainsi, l’instruction if
garantit que le fichier $HOME/.bashrc
— s’il existe (-f
) — sera sourcé (c’est-à-dire lu et exécuté) à l’ouverture de la session :
. "$HOME/.bashrc"
Note
|
Comme nous le verrons dans la prochaine leçon, |
Par ailleurs, nous pouvons utiliser le .
lorsque nous avons modifié un fichier de démarrage et que nous souhaitons que les changements soient effectifs sans redémarrage. Par exemple, nous pouvons :
-
ajouter un alias à
~/.bashrc
:user2@debian:~$ echo "alias hi='echo We salute you.'" >> ~/.bashrc
Warning
|
Lorsque vous envoyez la sortie d’une commande dans un fichier, ne confondez pas l’ajout ( |
-
afficher la dernière ligne de
~/.bashrc
pour vérifier si tout s’est bien passé :user2@debian:~$ tail -n 1 !$ tail -n 1 ~/.bashrc alias hi='echo We salute you.'
Note!$
remplace le dernier argument de la commande précédente, c’est-à-dire~/.bashrc
: -
sourcer le fichier en ligne de commande :
user2@debian:~$ . ~/.bashrc
-
et invoquer l’alias pour monter que ça marche :
user2@debian:~$ hi We salute you.
Note
|
Reportez-vous à la prochaine leçon pour en savoir plus sur les alias et les variables. |
Sourcer les fichiers avec source
La commande source
est un synonyme de .
. Ainsi, pour sourcer ~/.bashrc
, nous pouvons également le faire comme ceci :
user2@debian:~$ source ~/.bashrc
L’origine des fichiers de démarrage du shell : SKEL
SKEL
est une variable dont la valeur est le chemin absolu vers le répertoire skel
. Ce répertoire sert de modèle pour la structure du système de fichiers des répertoires personnels des utilisateurs. Il inclut les fichiers qui seront hérités par tout nouveau compte utilisateur créé (y compris, bien sûr, les fichiers de configuration des interpréteurs de commandes). SKEL
et les autres variables associées sont stockées dans /etc/adduser.conf
, qui est le fichier de configuration pour adduser
:
user2@debian:~$ grep SKEL /etc/adduser.conf # The SKEL variable specifies the directory containing "skeletal" user SKEL=/etc/skel # If SKEL_IGNORE_REGEX is set, adduser will ignore files matching this SKEL_IGNORE_REGEX="dpkg-(old|new|dist|save)"
SKEL
est défini à /etc/skel
; c’est là que sont rangés les scripts de démarrage qui configurent nos shells :
user2@debian:~$ ls -a /etc/skel/ . .. .bash_logout .bashrc .profile
Warning
|
Rappelez-vous que les fichiers qui commencent par un |
Ajoutons un répertoire dans /etc/skel
pour tous les nouveaux utilisateurs afin qu’ils y stockent leurs scripts personnels :
-
En tant que
root
, nous nous rendons dans/etc/skel
:root@debian:~# cd /etc/skel/ root@debian:/etc/skel#
-
Nous affichons son contenu :
root@debian:/etc/skel# ls -a . .. .bash_logout .bashrc .profile
-
Nous créons notre répertoire et nous vérifions que tout s’est passé comme prévu :
root@debian:/etc/skel# mkdir my_personal_scripts root@debian:/etc/skel# ls -a . .. .bash_logout .bashrc my_personal_scripts .profile
-
Supprimons
user2
et son répertoirehome
:root@debian:~# deluser --remove-home user2 Looking for files to backup/remove ... Removing files ... Removing user `user2' ... Warning: group `user2' has no more members. Done.
-
Nous ajoutons à nouveau
user2
de manière à ce qu’il dispose d’un nouveau répertoire utilisateur :root@debian:~# adduser user2 Adding user `user2' ... Adding new group `user2' (1001) ... Adding new user `user2' (1001) with group `user2' ... Creating home directory `/home/user2' ... Copying files from `/etc/skel' ... Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Changing the user information for user2 Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] y
-
Enfin, nous nous connectons en tant que
user2
et affichons tous les fichiers dans/home/user2
pour voir si tout s’est passé comme prévu :root@debian:~# su - user2 user2@debian:~$ pwd /home/user2 user2@debian:~$ ls -a . .. .bash_history .bash_logout .bashrc my_personal_scripts .profile
C’est le cas.
Exercices guidés
-
Regardez comment les shells ont été lancés dans la colonne "Shell démarré avec…" et complétez avec les informations requises :
Shell démarré avec… Interactif ? Connexion ? Résultat de echo $0
sudo ssh user2@machine2
Ctrl+Alt+F2
su - user2
gnome-terminal
Un utilisateur lambda utilise konsole pour lancer une instance de sakura
Un script nommé
test.sh
qui contient la commandeecho $0
-
Écrivez les commandes
su
etsudo
pour lancer le shell spécifié :- Shell de connexion interactif en tant que
user2
-
su
:sudo
: - Shell de connexion interactif en tant que
root
-
su
:sudo
: - Shell interactif simple en tant que
root
-
su
:sudo
: - Shell interactif simple en tant que
user2
-
su
:sudo
:
- Shell de connexion interactif en tant que
-
Quel fichier de démarrage est lu lorsque le shell dans la colonne "Type de shell" est démarré ?
Type de shell /etc/profile
/etc/bash.bashrc
~/.profile
~/.bashrc
Shell de connexion interactif en tant que
user2
Shell de connexion interactif en tant que
root
Shell interactif simple en tant que
root
Shell interactif simple en tant que
user2
Exercices d’approfondissement
-
Dans Bash, nous pouvons écrire une fonction simple
Hello world!
en incorporant le code suivant dans un fichier vide :function hello() { echo "Hello world!" }
-
Que devons-nous faire ensuite pour rendre la fonction utilisable par le shell ?
-
Une fois qu’elle est disponible dans le shell en cours, comment l’invoquer ?
-
Pour automatiser les choses, dans quel fichier pourriez-vous ranger la fonction et son invocation pour qu’elle soit exécutée lorsque
user2
ouvre un terminal depuis une session graphique ? De quel type de shell s’agit-il ? -
Dans quel fichier pourriez-vous ranger la fonction et son invocation pour qu’elle soit exécutée lorsque
root
lance un nouveau shell interactif, qu’il s’agisse d’un shell de connexion ou d’un shell simple ?
-
-
Jetez un œil à ce simple script Bash
Hello world!
:#!/bin/bash #hello_world: a simple bash script to discuss interaction in scripts. echo "Hello world!"
-
Admettons que nous rendions le script exécutable et que nous l’exécutions. Est-ce qu’il s’agirait d’un script interactif ? Pourquoi ?
-
Qu’est-ce qui rend un script interactif ?
-
-
Imaginez que vous ayez changé les valeurs de certaines variables dans
~/.bashrc
et que vous souhaitiez que ces changements prennent effet sans redémarrage. Depuis votre répertoire personnel, comment pourriez-vous y parvenir de deux manières différentes ? -
John vient de démarrer une session graphique sur un serveur Linux. Il ouvre un émulateur de terminal pour effectuer quelques tâches administratives mais, à sa grande surprise, la session se bloque et il doit ouvrir un terminal.
-
Comment peut-il ouvrir ce shell
tty
? -
Quels sont les fichiers de démarrage qui seront sourcés ?
-
-
Linda utilise un serveur Linux. Elle demande gentiment à l’administrateur de disposer d’un fichier
~/.bash_login
de manière à ce que l’heure et la date s’affichent à l’écran lorsqu’elle se connecte. D’autres utilisateurs apprécient cette idée et font de même. L’administrateur a du mal à créer le fichier pour tous les autres utilisateurs du serveur. Il décide donc d’ajouter une nouvelle politique et de créer~/.bash_login
pour tous les nouveaux utilisateurs potentiels. Comment l’administrateur peut-il accomplir cette tâche ?
Résumé
Voici ce que nous avons appris dans cette leçon :
-
Les shells définissent l’environnement des utilisateurs dans un système Linux.
-
Bash est le principal interpréteur de commandes de toutes les distributions GNU/Linux.
-
La première tâche d’un shell consiste à lire et à exécuter un ou plusieurs fichiers de démarrage.
-
Les concepts d’interaction et d’e connexion en rapport avec les shells.
-
Comment lancer différents types de shells avec
bash
,su
,sudo
et Ctrl+Alt+F1-F6. -
Comment vérifier le type de shell avec
echo $0
. -
Les fichiers de démarrage locaux
~/.bash_profile
,~/.profile
,~/.bash_login
,~/.bash_logout
et~/.bashrc
. -
Les fichiers de démarrage globaux
/etc/profile
,/etc/profile.d/*
,/etc/bash.bashrc
. -
Les fichiers locaux prennent le pas sur les fichiers globaux.
-
Comment rediriger la sortie d’une commande avec
>
(écrasement) et>>
(ajout). -
La signification du répertoire
skel
. -
Comment sourcer des fichiers.
Commandes utilisées dans cette leçon :
bash
-
Créer un nouveau shell.
su
-
Créer un nouveau shell.
sudo
-
Créer un nouveau shell.
usermod
-
Modifier un compte utilisateur.
echo
-
Afficher une ligne de texte.
ps
-
Afficher un aperçu des processus en cours.
less
-
Un visualiseur pour les fichiers longs.
ssh
-
Démarrer une connexion Open SSH (à distance).
chmod
-
Modifier les permissions d’un fichier, pour le rendre exécutable par exemple.
grep
-
Afficher les lignes qui correspondent à un motif.
ls
-
Afficher le contenu d’un répertoire.
cd
-
Changer de répertoire.
mkdir
-
Créer un répertoire.
deluser
-
Supprimer un utilisateur.
adduser
-
Ajouter un nouvel utilisateur.
.
-
Sourcer un fichier.
source
-
Sourcer un fichier.
tail
-
Afficher la dernière partie d’un fichier.
Réponses aux exercices guidés
-
Regardez comment les shells ont été lancés dans la colonne "Shell démarré avec…" et complétez avec les informations requises :
Shell démarré avec… Interactif ? Connexion ? Résultat de echo $0
sudo ssh user2@machine2
Oui
Oui
-bash
Ctrl+Alt+F2
Oui
Oui
-bash
su - user2
Oui
Oui
-bash
gnome-terminal
Oui
Non
bash
Un utilisateur lambda utilise konsole pour lancer une instance de sakura
Oui
Non
/bin/bash
Un script nommé
test.sh
qui contient la commandeecho $0
Non
Non
./test.sh
-
Écrivez les commandes
su
etsudo
pour lancer le shell spécifié :- Shell de connexion interactif en tant que
user2
su
-
su - user2
,su -l user2
ousu --login user2
sudo
-
sudo su - user2
,sudo su -l user2
ousudo su --login user2
- Shell de connexion interactif en tant que
root
su
-
su - root
ousu -
sudo
-
sudo su - root
,sudo su -
ousudo -i
- Shell interactif simple en tant que
root
su
-
su root
ousu
sudo
-
sudo su root
,sudo su
,sudo -s
ousudo -u root -s
- Shell interactif simple en tant que
user2
su
-
su user2
sudo
-
sudo su user2
ousudo -u user2 -s
- Shell de connexion interactif en tant que
-
Quel fichier de démarrage est lu lorsque le shell dans la colonne "Type de shell" est démarré ?
Type de shell /etc/profile
/etc/bash.bashrc
~/.profile
~/.bashrc
Shell de connexion interactif en tant que
user2
Oui
Oui
Oui
Oui
Shell de connexion interactif en tant que
root
Oui
Oui
Non
Non
Shell interactif simple en tant que
root
Non
Oui
Non
Non
Shell interactif simple en tant que
user2
Non
Oui
Non
Oui
Réponses aux exercices d’approfondissement
-
Dans Bash, nous pouvons écrire une fonction simple
Hello world!
en incorporant le code suivant dans un fichier vide :function hello() { echo "Hello world!" }
-
Que devons-nous faire ensuite pour rendre la fonction utilisable par le shell ?
Pour rendre la fonction utilisable par le shell en cours, nous devons sourcer le fichier dans lequel elle figure.
-
Une fois qu’elle est disponible dans le shell en cours, comment l’invoquer ?
Nous pouvons l’invoquer en tapant son nom dans le terminal.
-
Pour automatiser les choses, dans quel fichier pourriez-vous ranger la fonction et son invocation pour qu’elle soit exécutée lorsque
user2
ouvre un terminal depuis une session graphique ? De quel type de shell s’agit-il ?Le meilleur endroit pour la ranger serait
/home/user2/.bashrc
. Le shell invoqué serait un shell interactif simple. -
Dans quel fichier pourriez-vous ranger la fonction et son invocation pour qu’elle soit exécutée lorsque
root
lance un nouveau shell interactif, qu’il s’agisse d’un shell de connexion ou d’un shell simple ?Dans
/etc/bash.bashrc
puisque ce fichier est exécuté pour tous les shells interactifs, qu’il s’agisse d’un shell de connexion ou d’un shell simple.
-
-
Jetez un œil à ce simple script Bash
Hello world!
:#!/bin/bash #hello_world: a simple bash script to discuss interaction in scripts. echo "Hello world!"
-
Admettons que nous rendions le script exécutable et que nous l’exécutions. Est-ce qu’il s’agirait d’un script interactif ? Pourquoi ?
Non, étant donné qu’il n’y a pas d’interaction avec un humain et qu’aucune commande n’est saisie par l’utilisateur.
-
Qu’est-ce qui rend un script interactif ?
Le fait qu’il nécessite l’intervention de l’utilisateur.
-
-
Imaginez que vous ayez changé les valeurs de certaines variables dans
~/.bashrc
et que vous souhaitiez que ces changements prennent effet sans redémarrage. Depuis votre répertoire personnel, comment pourriez-vous y parvenir de deux manières différentes ?$ source .bashrc
ou bien
$ . .bashrc
-
John vient de démarrer une session graphique sur un serveur Linux. Il ouvre un émulateur de terminal pour effectuer quelques tâches administratives mais, à sa grande surprise, la session se bloque et il doit ouvrir un terminal.
-
Comment peut-il ouvrir ce shell
tty
?Il peut le faire en appuyant sur Ctrl+Alt+F1-F6 pour entrer dans l’un des six shells
tty
. -
Quels sont les fichiers de démarrage qui seront sourcés ?
/etc/profile
/home/john/.profile
-
-
Linda utilise un serveur Linux. Elle demande gentiment à l’administrateur de disposer d’un fichier
~/.bash_login
de manière à ce que l’heure et la date s’affichent à l’écran lorsqu’elle se connecte. D’autres utilisateurs apprécient cette idée et font de même. L’administrateur a du mal à créer le fichier pour tous les autres utilisateurs du serveur. Il décide donc d’ajouter une nouvelle politique et de créer~/.bash_login
pour tous les nouveaux utilisateurs potentiels. Comment l’administrateur peut-il accomplir cette tâche ?Il peut y parvenir en intégrant
.bash_login
dans le répertoire/etc/skel
.