Ceci est simplement une question de vocabulaire, mais qui ne cesse de tourner dans ma tête.
Il provient d'un examen pratique d'un livre de préparation LPIC . La réponse correcte selon le livre est qu’il ~/Documents
s’agit d’un répertoire relatif, car il est relatif au répertoire de base.
Cependant, ce livre contient un nombre honorable de fautes de frappe et d’erreurs et je ne peux donc pas tenir pour acquis tout ce qui y est écrit. Ici, je ne suis pas d’accord, car ~
j’agis comme une variable développée par le shell dans le contenu de la $HOME
variable ou dans le chemin du répertoire de base de l’utilisateur actuel (cf. man bash
). Le chemin réel est /home/myuser/Documents
donc un répertoire absolu.
Même Wikipedia , pour une fois, ne me semble d'aucune aide sur ce sujet (même s'il semble confirmer que le livre est faux sur celui-ci):
Un chemin absolu ou complet pointe vers le même emplacement dans un système de fichiers, quel que soit le répertoire de travail en cours. Pour ce faire, il doit contenir le répertoire racine.
En revanche, un chemin relatif commence à partir d’un répertoire de travail donné, évitant ainsi de fournir le chemin absolu complet.
Là encore, je ne suis pas d'accord: selon cette définition, le chemin /opt/kde3/bin/../lib
qui ne dépend pas du répertoire de travail actuel devrait être absolu, mais ma compréhension actuelle correspond à celle de l'auteur du livre, ce qui en fait un chemin relatif.
Une recherche rapide sur le Web ne fait qu'ajouter à ma frustration, selon le dictionnaire Webster :
chemin absolu - Un chemin relatif au répertoire racine. Son premier caractère doit être le séparateur de chemin d'accès.
Alors $HOME/Documents
, ou même tout simplement $HOME
, ne seraient pas considérés comme des répertoires absolus? Ou cette définition implique-t-elle une expansion variable? Qu'en est-il du ~
caractère de la coquille ? Existe-t-il une définition fiable du répertoire relatif par rapport au répertoire absolu que je peux trouver quelque part et que je me trompe complètement?
/
et ceux que nous appelons absolus. Ainsi , tout ce qui commence par/
je qualifierais absolue (même si cela est/usr/../etc
) et tout ce que j'appelleraient relatif (~/Doc
,Doc
,../john/Doc
,$HOME/...
, ...). Le fait est que absolute devrait fonctionner quel que soit le répertoire de travail en cours ou l'utilisateur actuel. Un parent ne peut fonctionner que dans certains cas précis.~/foo
un chemin relatif. Vous voulez en venir à la différence entre codage en dur et paramétrage. Voir ma réponse pour plus de détails.~/Documents
et$HOME/Documents
ne sont pas des chemins. Ils identifient les chemins (absolus) après l'expansion, mais ils ne sont pas eux-mêmes des chemins. Je pense que cela correspond au nombre d'utilisateurs d'Unix / Linux qui utilisent ce terme, mais il ne fait aucun doute que ces chaînes sont également appelées chemins.Réponses:
Si l'auteur essayait de vous surprendre en parlant de cette chaîne littérale (sans expansion du shell) sous la forme d'un chemin, il s'agit d'un chemin relatif (
mkdir -p './~/Documents'
). Autrement:C'est un chemin absolu , car sa résolution ne dépend pas du répertoire de travail actuel du processus. Chemin relatif signifie toujours relatif au répertoire de travail du processus. Ou dans le cas de cibles de lien symbolique, par rapport à l'emplacement du lien symbolique. (
gcc -> gcc-5.2
vsgcc -> /usr/bin/gcc-5.2
). Cela est important pour les montages NFS et les autres cas où vous pouvez obtenir le même lien symbolique via différents chemins absolus. par exempleDebian installe parfois des liens symboliques vers
../../doc/whatever/whatever
, au lieu d’une cible absolue, de sorte que cela fonctionne lorsque NFS est monté ailleurs ou lorsque vous regardez un chroot sans ychroot(8)
entrer.Chaque processus Unix a son propre cwd. La
pwd
commande existe juste pour l'imprimer.voir: http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html pour plus d'informations sur la modification de répertoires avec des appels système POSIX.
Comme tout le monde l’a dit,
~
le shell le développe avant que le chemin ne soit utilisé. L'utilisation~/bin/myprog
dans un script shell le fera fonctionner différemment pour différents utilisateurs. La différence entre~/bin/foo
et/home/peter/bin/foo
est que l'un d'eux a codé en dur l'emplacement, tandis que l'autre l'a paramétré. C'est une erreur (IMO) d'appeler la~
version un chemin relatif.Parler des choses comme étant "relatives à une variable d'environnement" est simplement déroutant. Il est déconseillé d’utiliser des termes différents en anglais qui ont une signification technique spécifique dans le contexte dans lequel vous les utilisez.
Sur un système en panne, avec
HOME=a/relative/path
,~/foo
se développerait sur un chemin relatif. Ce ne serait pas du tout une configuration utilisable.la source
/opt/kde3/bin/../lib
par exemple , est classé à tort comme un chemin relatif: il est un chemin absolu mais pas celui canonique. Comme vous l'avez dit, cela rend simplement tout confus, alors merci pour votre clarification et les informations relatives à NFS :)!realpath(1)
) font les deux choses: canoniser et rendre absolu (ainsi que suivre les liens symboliques), de sorte qu'une certaine confusion s'est peut-être glissée dedans.C’est essentiellement une question de définition des termes. Donc, pour vos besoins, la réponse est ce que veut LPIC. Mais nous pouvons tirer des conclusions sur la base de faits techniques:
Si vous passez
'~/Documents'
à un appel système , il cherchera un répertoire nommé exactement~
dans le répertoire actuel (et échouera probablement). Donc, par la notion de chemin d'accès utilisée par le noyau , c'est un chemin relatif - mais ce n'est pas ce que nous voulions dire.~
est une syntaxe implémentée par le shell (et d’autres programmes qui l’imitent pour plus de commodité) qui l’ élargit en un véritable chemin. Pour illustrer,~/Documents
est à peu près la même chose que$HOME/Documents
(encore une fois, la syntaxe du shell). Puisque$HOME
devrait être un chemin absolu, la valeur de$HOME/Documents
est aussi un chemin absolu. Mais le texte$HOME/Documents
ou~/Documents
doit être développé par le shell pour devenir le chemin que nous voulons dire.Donc, si je voulais être précis et cohérent, je dirais que
~/Documents
c'est un fragment de script shell qui se développe en chemin absolu.la source
$HOME
veut dire, tout comme il n’a aucune idée de ce que cela~
signifie. Toutefois, j’estime que l’affirmation selon laquelle le développement de la coque est douteux; la plupart des applications supportent cela, ce qui pointe vers la bibliothèque C plutôt que vers le shell. L'expansion des variables d'environnement est toutefois une caractéristique de la coque; vous pouvez ouvrir~/somefile.odt
dans LibreOffice, mais pas$HOME/somefile.odt
, même si LibreOffice a été lancé à partir d'un shell dans lequel $ HOME est correctement défini.~
syntaxe à l'imitation du shell, car c'est un raccourci utile. Je ne sais pas vraiment s'il existe une fonction de bibliothèque qui développe, mais c'est certainement quelque chose qui se fait séparément de l'utilisation du chemin.glob
etwordexp
faire tilde expansion entre autres choses.~
expansion; la plupart ne le font pas. Par exemple, si vous tapezls -l ~
, lels
programme ne voit jamais le~
caractère; il est développé par le shell avant d'ls
être appelé. Si vous passez réellement~
àls
, il ne le traitera pas spécialement; tryls -l '~
'`(qui essayera de lister un fichier nommé littéralement~
).Si votre
$HOME
est -/home/white/
,~/Documents
(même que$HOME/Documents
) est étendu par la coque (voir ici pour une explication) à/home/white/Documents
, qui est un absolu chemin.Un chemin relatif est un chemin qui ne commence pas par un
/
(après le développement du shell), comme../Documents
oufoo/bar
Quelques vieilles coquilles ne se développent pas
~
(la voiebash
,tcsh
,zsh
, etc ... faire); ils verraient~/Documents
comme un chemin relatif commençant par~
; mais vous n'avez généralement pas le même nom de répertoire~
(mais vous pouvez en créer unmkdir '~'
, ce que je ne recommande pas).la source
~
Un chemin absolu commence à
/
(ce à quoi il fait référence est fixe), un chemin relatif commence dans le répertoire en cours (et donc, il fait référence aux modifications apportées en même temps que le répertoire en cours). La plupart des shells utilisent~
au début comme une abréviation pour le chemin absolu du répertoire personnel de l'utilisateur, par exemple,~/Documents
est le répertoireDocuments
dans le de base de l'utilisateur actuel, quel que soit le répertoire actuel. C'est donc un chemin absolu.la source
Le chemin pourrait être étendu à un autre emplacement en fonction de l'utilisateur. Cela dit, c'est toujours un chemin absolu, pas un chemin relatif, à mon avis. Cependant, je ne pense pas que les définitions de chemin absolu et relatif soient aussi précisément définies. Ce ne sont pas des mathématiques. Cette question ne teste pas vraiment la compréhension, à mon avis, et est inutile.
la source
L'utilisation de ~ / au début rend le chemin absolu car (quelle que soit la définition), la capacité de trouver des documents ne dépend pas de l'endroit où vous vous trouvez. Cependant, l’expansion est réalisée par le shell, pas par le noyau. Par conséquent, si vous utilisez un shell qui ne reconnaît pas cette syntaxe (tel que / bin / sh, le shell Bourne original, pas l’alias bash), vous ne pourrez plus vous connecter. la chance.
Il est intéressant de noter que si vous utilisez ~ root / plutôt que ~ /, l’optimisation de la lecture de $ HOME ne s’applique généralement pas et le résultat sera toujours absolu si / etc / passwd est correct.
la source
Le livre semble considérer qu’un chemin absolu est tout chemin commençant par un
/
, et un chemin relatif est tout le reste.Vous pouvez voir
..
et$HOME
comme des types similaires de jetons. Les deux doivent être substitués, pour un composant de chemin, avant que le chemin ne soit résolu en chemin absolu.la source
..
quelque chose comme$HOME
?..
peut être au début d'un chemin transmis directement à un appel système, aucune extension de shell n'est requise. Un tel chemin n'est pas un chemin absolu; il est toujours relatif au processus cwd ou à l'emplacement du lien symbolique. Sauf si l'auteur essayait de vous surprendre en parlant de cette chaîne littérale (sans extension de shell) comme chemin. Je pense que vous essayez de trouver des excuses pour le livre, mais je suis plus enclin à dire que c'est faux et à ne pas laisser les choses se brouiller.