Spoiler Alert!! Non cette article ne va pas sauver votre ordinateur.
Tout au plus donner quelques pistes, informations, et commandes, ce n’est pas un tuto plutôt un livre de recettes.
FileSystem Hierarchy Standard
Ou plus sobrement FHS est le projet maintenant porté par la Linux Foundation pour standardiser l’organisation de l’arborescence du système de fichiers, car non tous les systèmes Gnu/Linux ne sont pas strictement organisé de la même manière.
Il y a tout de même beaucoup de similarité d’un système à l’autre comme le:
/home/etc/mnt/media
Mais prenons le répertoire:
/srv
censé être utilisé pour héberger les données static d’un service, on s’aperçoit qu’en réalité si on installe apache2 sous débian, ou httpd sous AlmaLinux les fichiers web seront dans:
/var/www
Prenons maintenant:
/opt
Censé être le répertoire d’installation des applications dites optionnelles à la survie du système.
Le mien par exemple:
tree -L 1 /opt
/opt
├── containerd
├── Element
├── google
└── gzdoom
Containerd , je comprends qu’il soit dans cette partie de l’arborescence, puisque c’est un vrai service, et qu’il faut explicitement lui indiquer d’être dans l’espace utilisateur pour être en mode rootless (sans droit root).
Pourquoi Element, Google-earth, et gzdoom sont là… et pas keepass, zotero, ou RStudio ?
Au passage gzdoom fonctionne très bien sous debian, si j’avance pas dans le jeu, c’est juste que je suis nul, et que tuer des gens n’est pas ma passion (contrairement au grand chauve).
Si je continu; les fichiers de configuration des applications installées dans /opt, sont censées se trouver dans /etc/opt, alors allons voir:
tree -L 1 /etc/opt
/etc/opt
0 directories, 0 files
Ah bah c’est pas là … Par contre si vous installez unbound, oui.
Voilà, linux ça marche très bien, mais il y a des contradictions qui peuvent perdre un nouvel utilisateur.
Et fun fact, linux ce n’est pas un truc de gamer ?
whereis gzdoom
gzdoom: /usr/games/gzdoom
which gzdoom
/usr/games/gzdoom
Le GUI <=> le CLI le <=> les TUI
-
GUI pour Graphic User Interface
-
CLI pour Command Line Interface
-
TUI pour Text-based User Interface
-
Le GUI
Pour faire court sur le sujet, la bataille des bureaux linux ne m’intéresse pas, en réalité un bureau est un DE pour desktop envionment . Il y en a de très bien, pas de doute là dessus. Mais la guéguerre des users qui défendent coûte que coûte un DE plutôt qu’un autre me fatigue. Ils s’épanchent, pédant, étalant leur savoir, et s’étripent.
J’ai bien mon DE préféré, mais la n’est pas le sujet, je n’ai d’ailleurs pas de DE.
J’ai un simple gestionnaire de fenêtre, qui me suffit largement, et ça ne m’empêche pas d’utiliser les librairies GTK et Qt pour lancer des applications.
-
Le CLI
Quel confort !! Pas besoin de savoir quel DE est utilisé, un terminal et ça roule. Souvent, on peut faire beaucoup plus de choses en une ligne de commande qu’en … je met un exemple après, et vous pourrez compter le nombres de clics de souris. (Même sous windows, vu qu’on sera en graphique).
Tous mes exemple dans l’article seront en ligne de commande.
-
Les TUI
Alors, ça c’est une chouette intention de la part des gars qui développent des applis, on dispose d’un environnement graphique dans le terminal. Plutôt que taper Y ou N pour répondre, on a des trucs à cliquer, un peu tout rustique.
Ça fait très années 80, mais c’est tellement classe de leur part.
Allez un awesome
Créer des répertoires, et des sous répertoires
On va comparer le GUI et le CLI, vous pouvez le faire sous windows.
Vous allez compter le nombres de clics de souris pour créer un répertoire nommé:
- example-mkdir
- un sous répertoire dossier1
- son sous répertoire dossier1-a
- un second sous répertoire dossier1-b
- un autre sous répertoire dossier2
- un autre sous répertoire dossier3
- son sous répertoire dossier3-a
- un autre sous répertoire dossier3-b
- un sous répertoire dossier1
Vous n’avez pas oublié de compter ?
Voici la commande en CLI
mkdir -p example-mkdir/{dossier1/{dossier1-a,dossier1-b},dossier2,dossier3/{dossier3-a,dossier3-b}}
ordinatous@gallyair:~$ tree -L 2 example-mkdir/
example-mkdir/
├── dossier1
│ ├── dossier1-a
│ └── dossier1-b
├── dossier2
└── dossier3
├── dossier3-a
└── dossier3-b
8 directories, 0 files
Trouver l’executable d’une application
Les commande whereis et which sont là pour ça.
whereis rstudio
rstudio: /usr/bin/rstudio /usr/lib/rstudio
which rstudio
/usr/bin/rstudio
Whereis donne les répertoires concernés, et which le dossier contenant l’exécutable.
Le $PATH ou le chemin des executables
Le $PATH est une variable d’environnement qui contient, dèjà une partie des chemins, comme /bin, /usr/bin, /local/bin, /usr/local/bin.
Pour connaitre vos chemins taper simplement $PATH dans le terminal:
$PATH
bash: /home/ordinatous/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/go/bin
Mais il arrive qu’une application a un chemin un peu exotique, par exemple go.
Il faut se l’ajouter dans son .bashrc en ajoutant ceci:
export PATH=$PATH:/usr/local/go/bin
.bashrc est lu au lancement du terminal, la ligne export va ajouter le nouveau chemin, à ceux déjà existant. Mais cela ne concernera que l’utilisateur. Si on veut l’ajouter à tout le système, donc pour tout les utilisateurs, il faut l’ajouter dans /etc/profil.
history Retrouver une commande
history est là pour ça. C’est top pour vérifier ce que l’on a fait, ou retrouver une commande.
L’historique des commandes est déjà accessible avec la flêche du haut, mais plutôt que remonter l’history indéfiniment, mieux vaut piper | (combinaison altgr 6)
Piper à grep, c’est encore plus efficace.
history | grep git
1089 git clone https://github.com/Linus2punkt0/bluesky-crossposter.git
1178 ssh-add ~/.ssh/githubblogdown
1179 git status
1180 git add *
1181 git commit -m "publication du 2nd article blogdown"
1182 git push –set-upstream origin main
1183 history | grep git
1185 git status
1186 git push
1212 history | grep git
La sortie de l’history est pipée (envoyé) à grep qui parse son entrée à la recherche de l’occurrence git.