Que signifie le point (.) Au début d’un nom de fichier dans une commande de terminal?
Dans chmod -R 421 .gimp, que signifie la période précédant directement le g dans gimp? Est-ce similaire au caractère générique *?
Le point dans cette situation fait partie du nom du fichier et, dans le contexte Linux/Unix, signifie que le fichier ou le répertoire est masqué. Vous ne pouvez pas le voir dans l'explorateur de fichiers (Nautilus, qui est la valeur par défaut pour Vanilla Ubuntu), à moins presse CTRL+H.
Et, si vous utilisez uniquement lsdans le terminal, vous ne le verrez pas, sauf si vous utilisez l'indicateur -a ou -A avec (i.e. ls -a ou ls -A ou ls --all ou ls --almost-all.
Cependant, le point (.) a différentes significations dans différents contextes:
- Par exemple, dans un chemin (
./file), il décrit le répertoire dans lequel vous vous trouvez, alors que../filefait référence àfiledans le répertoire parent. - Et il existe même une commande
.qui sources (exécute) fichiers de script bash. Donc,. ./file(attention à l'espacement) devrait générer le script nomméfiledans le répertoire en cours. - et dans un contexte REGEX, le point signifie "n'importe quel caractère".
.gimp dans votre exemple est un nom de fichier, le "." est le premier personnage.
L’importance de cela est qu’un ls normal (ls = liste des fichiers) n’affiche pas les fichiers avec "." en tant que premier caractère, il ne liste qu'avec ls -a (ou list files --all)
Rien. Cela fait partie du nom du fichier.
Vous semblez avoir un répertoire appelé .gimp.
Période. (lol)
Toute autre discussion à ce sujet relève de la question de savoir pourquoi les gens choisissent certains noms de fichiers.
Le premier point dans les noms de fichiers ou de répertoires n’a pas de signification particulière en ce qui concerne Linux lui-même. Cependant, certains utilitaires (tels que ls ou le gestionnaire de fichiers Nautilus) considèrent ces noms de fichiers comme "cachés", c’est-à-dire qu’ils les ignorent dans leur sortie et ne les affichent que si vous fournissez une option spécifique.
En réalité, cela provient de ce qui peut techniquement être considéré comme un bug. Rob Pike , une des premières personnes ayant travaillé sur l'équipe UNIX raconte ( source ):
Il y a bien longtemps, alors que la conception du système de fichiers Unix était en cours d'élaboration, les entrées. et .. est apparu, pour faciliter la navigation. Je ne suis pas sûr, mais je crois que… est entré lors de la réécriture de la version 2, lorsque le système de fichiers est devenu hiérarchique (sa structure était très différente au début). Cependant, quand on tapait ls, ces fichiers apparaissaient. Ken ou Dennis ajoutèrent donc un simple test au programme. C'était en assembleur alors, mais le code en question était équivalent à quelque chose comme ceci:
if (name[0] == '.') continue;Cette déclaration était un peu plus courte que ce qu’elle aurait dû être, ce qui est
if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;mais bon, c'était facile.
Deux choses ont résulté.
Premièrement, un mauvais précédent a été créé. Beaucoup d'autres programmeurs paresseux ont introduit des bugs en faisant la même simplification. Les fichiers réels commençant par des périodes sont souvent ignorés lorsqu'ils doivent être comptés.
Deuxièmement, et bien pire, l’idée d’un fichier "caché" ou "pointé" a été créée. En conséquence, davantage de programmeurs paresseux ont commencé à déposer des fichiers dans le répertoire personnel de tout le monde. Je n'ai pas beaucoup de choses installées sur la machine que j'utilise pour taper cela, mais mon répertoire personnel contient une centaine de fichiers .dot et je ne sais même pas ce que la plupart d'entre eux sont ou s'ils sont toujours nécessaires. . Chaque évaluation de nom de fichier qui passe par mon répertoire personnel est ralentie par ces boues accumulées.
Je suis presque sûr que le concept de fichier caché était une conséquence inattendue. C'était certainement une erreur.
De nos jours, cette sorte de convention est devenue une convention pour les appeler "cachés" même si leur contenu n'est pas caché du tout. Un vrai fichier caché ou anonyme/ inode anonyme , serait implémenté via l'ouverture du fichier en maintenant son descripteur de fichier ouvert, mais en le dissociant du répertoire, ce qui rend les données elles-mêmes accessibles uniquement au programme. qui détient ce fichier et ses processus enfants (de préférence fourchus après avoir dissocié le fichier), car les processus enfants héritent des descripteurs de fichier. En fait, voici comment bash implémente here-docs .
Une histoire très différente est lorsque le nom de fichier est lui-même un point . ou .., qui a en réalité un peu d’histoire derrière eux, et je vous suggère de lire Pourquoi le répertoire en cours dans la commande ls est-il identifié comme lié à lui-même? =
Un point au début d'un nom de fichier masque le fichier dans les gestionnaires de fichiers communs et pour les programmes Shell communs.
La raison en est historique, lorsque ls a masqué les répertoires spéciaux . et .. en masquant tout ce qui commence par un point. Ensuite, les personnes utilisaient des noms de fichiers commençant par un point pour masquer des fichiers. Elles ne sont donc répertoriées que par ls -a, par exemple pour rendre invisibles les fichiers de configuration qui ne sont généralement pas nécessaires dans la sortie ls.
Ainsi, le point dans chmod -R 421 .gimp n'est pas un modificateur de la commande, mais une partie du nom de répertoire réel.