Conseils pour mémoriser l'ordre des paramètres de ln?
J'ai utilisé ln pour écrire des liens symboliques pendant des années, mais je reçois toujours l'ordre des paramètres dans le mauvais sens.
Cela me fait généralement écrire:
ln -s a b
puis en regardant la sortie pour me rappeler.
J'imagine toujours être a -> b comme je l'ai lu alors que c'est le contraire b -> a. Cela semble contre-intuitif, donc je trouve que je suis toujours en train de me remettre en question.
Quelqu'un a-t-il des conseils pour m'aider à me souvenir de la bonne commande?
J'utilise ce qui suit: ln a une forme à un argument (2e forme répertoriée dans le manpage ) dans laquelle seule la cible est requise (car comment ln pourrait-elle fonctionner du tout sans connaître la cible) et ln crée le lien dans le répertoire courant. La forme à deux arguments est un ajout à la forme à un argument, donc la cible est toujours le premier argument.
Je dis "ln est comme cp. La 'source' doit venir en premier."
La plupart des Unices documentent la commande ln comme
ln source target
(J'omet des options, etc. ici)
Exemples:
ln [-fs] [-L|-P] source_file target_fileOpenBSD :
ln [-fhLnPs] source [target]ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file]macOS
ln [-Ffhinsv] source_file [target_file]/usr/bin/ln [-fns] source_file [target]ln [ -f | -n ] [ -s ] SourceFile [ TargetFile ]
Le manuel GNU ln appelle le source target et le target linkname.
ln [option]… [-T] target linkname
Ignorant le choix de mots GNU, l'utilitaire ln suit le même type de sémantique que par exemple mv et cp en ce que la cible est ce qui est créé à partir de la source.
Donc,
ln -s a b
créerait le lien symbolique b pointant vers a.
Notez également que lors de la création de liens symbolique, la source est simplement une chaîne représentant ce vers quoi le lien symbolique doit pointer. Il n'y a généralement pas de vérification pour valider qu'il pointe vers quelque chose d'utile:
$ ln -s "hello world" README.txt
$ ls -l
total 0
lrwxr-xr-x 1 kk wheel 11 Sep 15 11:39 README.txt -> hello world
Au cas où cela aiderait quelqu'un: je me suis habitué à le considérer comme "ln quoioù", ce qui m'aide à me rappeler que le premier argument ("quoi") est le fichier existant, le second ("où") est l'endroit où le mettre (un lien). Contrairement au raisonnement de la plupart des autres réponses, ce n'est rien de plus qu'une phrase concise que je peux me réciter mentalement en tapant une commande, qui sert d'aide-mémoire. Cela ne sera probablement pas utile à tout le monde mais je soupçonne que cela aidera certaines personnes.
Il est utile que les autres commandes de manipulation de fichiers standard utilisent la même convention, donc je peux faire de même pour cp et mv.
J'ai récemment entendu un excellent moyen de se souvenir de cette chose en particulier: ne rime
Quelque chose de vieux, quelque chose de nouveau,
quelque chose d'emprunté, quelque chose de bleu,
et six pence dans sa chaussure.
Le premier verset est ce que sont les arguments de ln: quelque chose d'ancien suivi d'un nom de la nouvelle entrée de répertoire.
NAME ln -- make a link
SYNOPSIS ln name1[ name2 ]
DESCRIPTION ln creates a link to an existing file name1.
If name2 is given, the link has that name;
A partir de 1971 nix First Edition Manuals .
Il existe une seconde forme de syntaxe simple.
edit: Je mets FILE ou FILENAME au lieu de TARGET --- voir les commentaires etc. voir aussi l'ajout très long en bas, adressant le iceberg, dur et mou de ln, pas seulement la pointe de celui-ci.
Donc GNU ln a ceci:
ln [opt] FILENAME
In the 2nd form, create a link to FILENAME in the current directory.
où vous n'avez pas besoin du nom du lien. Après ln -s /usr/lib/modules vous obtenez un
modules -> /usr/lib/modules
avec le même nom que FILENAME ("cible" ou "source"), là où vous êtes. Pas de choix, pas de confusion.
Maintenant, si vous êtes plus exigeant et voulez que le lien soit créé sous un autre nom et/ou ailleurs , vous ajoutez ce souhait comme nom ou chemin. La vraie cible vient en premier, le nouveau nom de lien extra-fantastique en second.
Ou vous dites: "Je connais cette notation de flèche dans ls -l pour les liens. Je n'ai pas de flèche dans le shell pour indiquer la direction de mon lien. Je dois donc inverser la tendance. "
Vous le créez dans un sens, vous pouvez donc l'utiliser dans l'autre.
(FIN DE LA RÉPONSE À LA QUESTION)
À un autre niveau, le mot "lien" lui-même porte une double signification profonde et cachée. Les liens symboliques sont venus plus tard, donc au début, un lien n'était qu'un lien. Il n'y avait ni mou ni dur, ni -s option. Et maintenant j'utilise même le symbolisme source-cible:
mv A B --- move the whole file to B (dir or new name)
cp A B --- copy whole file (mv and cp are "the same" here)
ln A B --- copy whole file MINUS data blocks (=copy only inode and name), and increase "link count" for track keeping
À ce stade, il existe des liens, mais pas de liens durs et mous, et ls -l n'affiche pas de flèches, car il n'y a pas de direction dans un lien (dur). Un "lien" à ce stade de l'évolution d'Unix signifiait que le nom de fichier "B" (entrée de répertoire "B") dans le système de fichiers pointe vers le même inode que le nom de fichier "A" pointe vers.
Les fichiers A et B sont "liés" ensemble, car ils partagent les mêmes blocs. Alors maintenant, à chaque rm, le noyau doit vérifier: est-ce que je supprime/libère les blocs de ce fichier sur le disque, ou y a-t-il un autre fichier lié aux mêmes blocs? Pour cela, un compteur de liens est utilisé.
Supposons que vous souhaitiez conserver un gros fichier sur/tmp grom en cours de suppression et faites ln /tmp/bigfile. Vous avez maintenant un gros fichier volumineux dans votre répertoire de travail. Après avoir nettoyé/tmp et retiré l'original, vous continuez avec plaisir à utiliser les mêmes blocs de données. Vous n'obtenez pas de lien mort ou pendant, vous avez un fichier normal. Pointant sur aucun fichier mais uniquement sur les blocs du système de fichiers comme le fait chaque entrée de répertoire. Seulement maintenant, le "nettoyage"/tmp n'est pas aussi efficace qu'il l'était. Il semble vide, et il l'est, mais les blocs de la partition ne sont pas libérés.
Même si un lien dur ne coûte pas d'espace lui-même comme le fait cp, il le peut indirectement.
Ajouter ln -s à la séquence ci-dessus:
ln -s A B --- copy only the file's name to "B"
Maintenant, "B", le lien logiciel, a seulement une chaîne avec un chemin d'accès. Ceci est une information "douce". Techniquement, "A" et "B" ne sont pas liés. Mais toujours B est un "lien" dans le nouveau sens que vous pouvez utiliser ce chemin d'accès stocké comme raccourci vers "A". Maintenant, c'est "un lien vers A" (point) et non "lié avec l'inode du fichier A"
Les deux types de liens peuvent confondre non seulement les humains mais aussi le noyau/fs. La page de manuel de 1971 note: "BOGUES: les liens sont sauvegardés deux fois et restaurés en tant que fichiers séparés avec des inodes séparés."
Les liens physiques vers des répertoires (rares/non autorisés) peuvent facilement entraîner un blocage.
Les liens logiciels vers des répertoires (très courants) peuvent conduire à des boucles éternelles - doivent être reconnus par les utilitaires/noyau.
Exemple pratique en bash
En commençant par un fichier régulier "F" ...
ln F Fhard
... donne à Fhard la même taille que F, mais ils LES DEUX apparaissent maintenant dans un rouge foncé SANS flèches dans ls -l --color. En raison de stat montrant "Links: 2" en liaison avec "Inode: xyz". Un lien dur F transforme F lui-même en un lien dur. Les deux sont/restent le type de fichier "fichier normal". Mais les deux ont un inode avec un nombre de liens supérieur à 1.
ln -s F Fsoft
... crée un petit fichier "irrégulier" "Fsoft" avec le type de fichier "lien symbolique" --- encore plus d'économie d'espace qu'un répertoire vide. UNE ls -l n'affiche rien de spécial pour "F". Pour Fsoft, la taille indiquée est de 1 octet car la chaîne est "F" et Fsoft -> F s'affiche comme nom. Pas besoin de coloriser un lien logiciel pour en reconnaître un. Parce que sous la forme abrégée ls -F vous obtenez une chaîne enroulée @ ajouté: Fsoft@
Avec ls -l cela ressemble à ceci:
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 F
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 Fhard
lrwxrwxrwx 1 root root 1 Sep 16 16:31 Fsoft -> F
Fhard a la taille et le type de F.
Fsoft a le nom de F et la longueur du nom de F comme taille, et un type de fichier différent.
Court ls -sF:
5932 F 5932 Fhard 0 Fsoft@
ajouter --block-size=1 ne donne pas les mêmes tailles non plus. Fsoft a la taille "un octet, zéro bloc". F et Fhard s'écartent en parallèle:
6074368 F 6074368 Fhard 0 Fsoft@
Pour voir si Fsoft est suspendu ou non, ls vous permet d'utiliser des couleurs.
Orphan 40;31;01 # symlink to nonexistent file, or non-stat'able file
Il est vraiment utile de se rappeler que le nom du lien est facultatif. S'il n'est pas donné, le nom de base de la cible du lien est utilisé.
ln -s /path/to/file1 file1
est identique à supprimer complètement le nom du lien:
ln -s /path/to/file1
Cela n'aurait aucun sens si la cible du lien était mentionnée en dernier.
Pensez Unix -> AT&T -> destination à droite:
mov %eax, %ebx ;; AT&T style assembler syntax: %ebx register gets value of %ecx
mv foo bar ;; foo renamed to bar
cp foo bar ;; contents of foo go to bar
foo | bar ;; data moves left to right in pipeline
ln abc def ;; link to abc installed as def
Personnellement, je préfère éviter se souvenir X, en faveur de savoir où chercher pour X quand j'en ai besoin. Je suis également fan de l'attitude "mieux vaut prévenir que guérir", donc j'aime toujours vérifier attentivement ce que j'écris, en particulier en tant que root.
Dans ce cas, la réponse se trouve littéralement dans les premières lignes de la page de manuel:
ln [OPTION]... [-T] TARGET LINK_NAME
(...)
In the 1st form, create a link to TARGET with the name LINK_NAME.
Je ne l'aurais pas suggéré s'il fallait fouiller dans la page de manuel, mais comme c'est juste au début, à mon humble avis ça vaut les 3 secondes qu'il faut pour taper man ln et quittez.