Conseils pour vous rappeler l'ordre des paramètres pour ln?

64

J'avais l'habitude lnd'écrire des liens symboliques pendant des années mais j'obtiens toujours l'ordre des paramètres à l'envers.

Cela m'a généralement écrit:

ln -s a b

et puis en regardant la sortie pour me rappeler.

J'imagine toujours être a -> bcomme je le lis quand c'est en fait le contraire b -> a. Cela me semble contre-intuitif, alors je me rends toujours compte de moi-même.

Quelqu'un a-t-il des conseils pour m'aider à retenir le bon ordre?

Zhro
la source
11
Parfois, il est utile de le dire à voix haute lorsque vous le tapez dans "lien symbolique vers a, et appelez-le b"
jsotola
2
Vous créez le deuxième paramètre comme avec cp et vous créez le lien. Mais si vous obtenez le mauvais sens, pas de problème, car vous ne pouvez pas écraser un fichier existant ou un lien symbolique avec un nouveau lien.
sudodus le
1
Connexes: direction d'un lien symbolique
G-Man dit 'Réintégrez Monica' le
1
Pensez-y comme à un "pseudonyme de méchant". Il est toujours mentionné en premier par son vrai nom, puis par ses pseudonymes. Ex: Tony Baloney alias Oscar Meyer. Ou, dans le cas de votre lien, ln -sab signifie "Fichier-a est également appelé fichier-b".
Scottie H le
1
ln source target. Même que cp source target, mv source target; ...
user207421

Réponses:

40

J'utilise ce qui suit: lna un formulaire à un argument (le second formulaire est répertorié dans la page de manuel ) dans lequel seule la cible est requise (car comment pourrait lnfonctionner sans connaître la cible) et lncrée le lien dans le répertoire en cours. La forme à deux arguments est un ajout à la forme à un argument, ainsi la cible est toujours le premier argument.

Gary
la source
3
Notez que le formulaire sans chemin de destination / cible est une extension de la spécification POSIX de ln.
Kusalananda
1
@kusa: avez-vous vu le manuel de 1971 dans ma réponse avec la forme à un argument? Comment cela peut-il être une extension de Posix s'il était là en 1971? --- "Si name2 est donné, le lien a ce nom"
@SP Je ne suis pas sûr de comprendre ce que vous voulez dire. Voulez-vous dire qu'une implémentation historique dépasse en quelque sorte le standard POSIX actuel?
Kusalananda
1
Je vois aussi. Différents noms, mêmes arguments, au moins. Je n'avais aucune idée que Gnu est le seul à avoir ces noms de arguments.
2
Il y avait beaucoup de bonnes réponses ici (spécialement la comptine de @loa_in_) mais je vais y aller avec celui-ci. En indiquant que l'ordre des paramètres est cohérent (en ignorant -t), on a presque l'impression d'être une preuve. " lncrée le lien dans le répertoire courant. La forme à deux arguments est un ajout à la forme à un argument et la cible est donc toujours le premier argument". Parce qu'il est logique que ce soit le cas lors de l'examen de la deuxième forme, je pense que cela m'aidera à m'en souvenir.
Zhro
85

Je passe par " lnest comme cp. La" source "doit venir en premier."

Hermann
la source
20
... et comme mv. mv, cpEt lntous prennent un fichier existant comme premier argument, et le fichier de destination ou le nom du répertoire comme deuxième argument.
Hans-Martin Mosner le
7
C'est dommage que memcpy, strcpyetc. fonctionnent dans l'autre sens.
Arkadiusz Drabczyk le
6
@ Hans-MartinMosner, sauf que lorsque vous créez un lien symbolique, il ne doit pas nécessairement s'agir d'un fichier existant ...
ilkkachu
1
@ilkkachu Vous avez raison. Aucune règle sans exception :-)
Hans-Martin Mosner
1
@ArkadiuszDrabczyk D'autre part, quelque chose comme les memcpy(dest,src,n);cartes très bien à dest = src;. En d'autres termes, définissez (les premiers noctets de) dest égal à (les premiers noctets de) src.
un CVn
10

La plupart des Unices documentent la lncommande en tant que

ln source target

(J'omissionne des options, etc. ici)

Exemples:

  • Le standard POSIX

    ln [-fs] [-L|-P] source_file target_file
    
  • OpenBSD :

    ln [-fhLnPs] source [target]
    
  • NetBSD et FreeBSD

    ln [-L | -P | -s [-F]] [-f | -iw] [-hnv] source_file [target_file]
    
  • macOS

    ln [-Ffhinsv] source_file [target_file]
    
  • Solaris

    /usr/bin/ln [-fns] source_file [target]
    
  • AIX

    ln [ -f | -n ] [ -s ] SourceFile [ TargetFile ]
    

Le lnmanuel GNU appelle la source cible et le target nom du lien .

Ignorant le choix de mots GNU, l' lnutilitaire suit le même type de sémantique que par exemple mvet cpen ce que la cible est ce qui est créé à partir de la source .

Donc,

ln -s a b

créerait le lien symbolique bpointant vers a.

Notez également que lors de la création de liens symboliques , la source est simplement une chaîne représentant ce que le lien symbolique doit désigner. Il n’ya généralement pas de vérification faite pour confirmer que cela pointe sur 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
Kusalananda
la source
5
Je blâme entièrement la documentation GNU pour le fait que les gens se trompent du tout. Leur formulation est compréhensible avec le recul mais objectivement déroutante.
Konrad Rudolph
6
@ KonradRudolph, au contraire, le libellé de GNU me semble parfait. L'utilitaire crée un lien avec un nom, pointant quelque part. « Nom du lien » est un peu évident, et « cible » est une très bonne description de quelque chose qui est pointé à . Comme anecdote, il me faut encore parfois penser à la manière dont cela ln -s a bfonctionne. Cela n'a rien à voir avec la formulation de GNU, car je ne pense pas avoir déjà consulté le phrasé de la page de manuel. : D (C'est plus facile de courir ln -si a bquand on n'est pas sûr, ça va se plaindre si ça bexiste déjà.)
ilkkachu
1
@ KonradRudolph, bien que techniquement, l'appeler "cible" dans le cas d'un lien dur est faux , car ce n'est pas le nom existant, mais l'inode qui est la cible réelle. Je me demande si les gens de GNU ont pensé qu'un utilisateur commun ne devrait pas avoir à y penser en détail.
ilkkachu le
Il est intéressant de noter, comme mentionné dans les commentaires de la réponse de @ gary, que la cible n'est pas facultative dans le standard POSIX.
Zhro
@kusa: avec "ln -s AB --- copiez uniquement le nom du fichier en B" J'ai adopté votre interprétation dans un contexte légèrement modifié. Je peux même être d'accord avec votre exemple radical de "bonjour le monde". "Seul le nom du fichier" EST une chaîne. Je veux juste vous signaler que j'ai édité un peu et ajouté beaucoup.
7

Au cas où cela aiderait quelqu'un: je me suis habitué à le considérer comme "ln quoi ", ce qui m'aide à me rappeler que le premier argument ("quoi") est le fichier existant, le second ("où") est le lieu mettre (un lien vers). Contrairement au raisonnement de la plupart des autres réponses, ce n’est rien de plus qu’une phrase simpliste que je peux me réciter mentalement lorsque je tape une commande, qui sert d’aide à la mémoire. Cela ne sera probablement pas utile à tout le monde mais je pense que cela aidera certaines personnes.

Il est utile que les autres commandes de manipulation de fichier standard utilisent la même convention. Je peux donc faire de même pour cpet mv.

David Z
la source
4
Je suis curieux de savoir pourquoi cela a été voté. Il n'y a pas grand chose qui pourrait être faux - est-ce que j'ai mélangé l'ordre ou quelque chose?
David Z
Personnellement, je pense que "Dans quoi" n'est toujours pas clair sans explication: que pourrait être "quel est le lien pointant vers?" (correct) ou "qu'est-ce qui lie à quelque chose?" (faux). Même avec où: "où le lien pointe-t-il?" (faux) ou "où le lien doit-il être créé" (correct). Donc, cela n’aide pas nécessairement beaucoup si vous vous posez des questions. Se souvenir de cp et mv devrait cependant aider.
125_m_125 le
Nous nous attendons tous à ce qu'une commande UNIX inclue ses arguments de fichier après d'autres types d'arguments (comme le fait grep, par exemple). ln crée un fichier d'un certain type avec un contenu donné. Que le système de fichiers fasse quelque chose de spécial et que nous mettions habituellement le chemin d'accès à un fichier source est accessoire à ln. Par exemple, je pourrais écrire un éditeur de texte qui stockerait le contenu de sa première ligne dans un lien symbolique appelé 1, etc. Cela serait idiot, mais cela souligne que ln crée un type de fichier avec du contenu textuel, rien de plus, et rend l'ordre des arguments semble logique.
Dannie
@ 125_m_125 L'autre interprétation que vous avez présentée n'a pas beaucoup de sens pour moi, mais ça va; Cet aide-mémoire n'est pas pour tout le monde.
David Z
6

J'ai récemment entendu une excellente façon de se souvenir de cette chose en particulier: une comptine

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 indique quels sont les arguments de ln: quelque chose d’ancien suivi du nom de la nouvelle entrée de répertoire.

loa_in_
la source
3
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; 

À partir de 1971 Unix First Edition Manuals .

Il existe une seconde forme simple, à syntaxe.


edit: je mets FILE ou FILENAME au lieu de Target --- voir les commentaires , etc. voir aussi très long ajout au fond, adressant l' iceberg, dur et doux de ln, non seulement la pointe de celui - ci.


Donc, GNU lna 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 avoir ln -s /usr/lib/modulesobtenu 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 souhaitez que le lien soit créé sous un autre nom et / ou ailleurs , vous ajoutez ce souhait sous forme de nom ou de chemin. La vraie cible vient en premier, le nouveau nom de lien extra fantastique en second.


Ou vous dites: "Je connais cette notation en forme ls -lde flèche pour les liens. Je n’ai pas de flèche dans la coque pour indiquer la direction de mon lien. Je dois donc le retourner."

Vous le créez dans un sens, vous pouvez donc l'utiliser dans l'autre.

(FIN DE LA RÉPONSE DE LA PARTIE QUESTION)


Sur un autre plan, le mot "lien" porte lui-même une double signification cachée. Les liens symboliques sont venus plus tard, alors au début, un lien n'était qu'un lien. Il n'y avait pas de soft et hard, pas d' -soption. 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

A ce stade, il y a des liens, mais pas de liens durs ou indirects, et ls -lne montre pas de flèches, car il n'y a pas de direction dans un lien (dur). Un "lien" à ce stade d’évolution unix signifie que le nom de fichier "B" (entrée de répertoire "B") dans le système de fichiers pointe sur le même inode que le nom de fichier "A".

Les fichiers A et B sont "liés" ensemble, car ils partagent les mêmes blocs. Alors maintenant, avec 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 et que vous le supprimiez ln /tmp/bigfile. Vous avez maintenant un gros bigfile dans votre répertoire de travail. Après avoir nettoyé / tmp et déplacé l'original, vous continuez à utiliser les mêmes blocs de données. Vous n'obtenez pas un lien mort ou en suspens, vous avez un fichier normal. Pointant sur aucun fichier mais uniquement sur le système de fichiers, comme le fait chaque entrée de répertoire. Seulement maintenant, "nettoyer" / tmp n’est plus aussi efficace qu’il l’était. Cela semble vide, et ça l'est, mais les blocs de la partition ne sont pas libérés.

Même si un lien physique ne coûte pas l’espace lui-même comme cp, indirectement, il le peut.

Ajout ln -sà la séquence ci-dessus:

ln -s A B   --- copy only the file's name to "B"   

Maintenant, "B", le lien symbolique, a seulement une chaîne avec un chemin d'accès. C'est info "soft". 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 stocké comme raccourci vers "A". Maintenant c'est "un lien vers A" (point) et pas "lié à 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 disait: "BOGUES: les liens sont sauvegardés deux fois et restaurés sous forme de fichiers séparés avec des inodes distincts."

Les liens durs vers les répertoires (rares / non autorisés) peuvent facilement conduire à un encrassement.

Les liens symboliques vers les répertoires (très fréquents) peuvent conduire à des boucles éternelles - doivent être reconnus par les utilitaires / noyau.

Exemple pratique à bash

Commençant par un fichier régulier "F" ...

ln F Fhard

... donne à Fhard la même taille que F, mais ils apparaissent tous les deux dans un rouge foncé SANS les flèches ls -l --color. En raison de statmontrer "Links: 2" en relation avec "Inode: xyz". Liaison dure F transforme F en un lien dur. Les deux sont / restent un 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 un type de fichier "lien symbolique" - encore plus d'économie d'espace qu'un répertoire vide. A ls -lne montre rien de spécial pour "F". Pour Fsoft, la taille indiquée est de 1 octet puisque la chaîne est 'F' et Fsoft -> Fest affichée comme nom. Pas besoin de coloriser un lien virtuel pour en reconnaître un. Parce que dans la forme courte, ls -Fvous obtenez une chaîne enroulée @ :Fsoft@

Avec ls -lça ressemble à ça:

-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@

l'ajout --block-size=1ne donne pas les mêmes tailles non plus. Fsoft a la taille "un octet, zéro bloc". F et Fhard dévient en parallèle:

6074368 F  6074368 Fhard    0 Fsoft@

Pour voir si Fsoft est suspendu ou non, lspermet d'utiliser des couleurs.

ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file

la source
2

Il est vraiment utile de se rappeler que le nom du lien est facultatif. S'il n'est pas indiqué, le nom de base du lien cible 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 le lien cible était mentionné en dernier.

rexkogitans
la source
1

Il suffit de penser 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
Kaz
la source
"cp foo bar" signifie "barrer". "ln abc def" signifie "à abc". Si vous aviez gardé les symboles: "tromper". C'est exactement le problème.
@ user370539 Cela n'est pas du tout vrai; après ln abc def, abcet defsont le même objet; ils sont indiscernables. De plus, l’opération n’a aucun effet abcautre que l’augmentation du nombre de liens. La destination est def. Un pointeur sur l'objet est nouvellement installé à l' defemplacement.
Kaz
@ user370539 Si le lien est symbolique, ln -s abc defcela signifie que le contenu abcest écrit à l'emplacement def. abcn'a même pas à résoudre à rien; cela peut être un lien qui pende.
Kaz
Votre commentaire est exactement ... faux. Il devrait être l'inverse.
rexkogitans
@ rexkogitans Mon point est que c'est cohérent. Si l'ordre est « mauvais » et doit être inversée, alors il devrait être pour toutes ces commandes: mv dest src, ln [ -s ] dest src, cp dest src, ...
Kaz
0

Personnellement, je préfère éviter de me souvenir de X, plutôt que de savoir où chercher X lorsque 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, surtout en tant que root.

Dans ce cas, la réponse est 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 était nécessaire d'explorer la page de manuel, mais comme c'est juste au début, à mon humble avis, cela vaut les 3 secondes qu'il faut pour taper man lnet arrêter.

dr01
la source
-1

Semblable à cp, que je lis mentalement comme "copier ceci dans cela", je lis les commandes ln comme "lier ceci à cela".

jl6
la source
2
Cela ressemble beaucoup à la réponse la mieux notée .
Michael
Donc "ln -s AB 'relie A à B? Est-ce maintenant A -> B ou B -> A? Je pense que la plupart n’ont même pas passé le premier degré de confusion. Ils disent que c’est simple, mais c’est tout simplement faux.
-2

Voici comment je m'en souviens: oublie la cible. En d'autres termes, si je suis dans dir1 et que je veux créer un lien symbolique ici vers fichier1 qui existe dans / some / other / dir /, je ferais simplement:

ln -s /some/other/dir/file1

Vous obtiendrez un lien symbolique appelé fichier1 dans rép1 qui pointe vers / une autre / autre / dir / fichier1. De la page de manuel de ln:

ln [OPTION] ... CIBLE (2ème formulaire) ... Dans le 2ème formulaire, créez un lien vers TARGET dans le répertoire en cours.

Gardez simplement à l'esprit que cela ne fonctionne que si vous souhaitez que le lien symbolique porte le même nom que la cible (ce qui est très probablement le cas).

Hopping Bunny
la source
Quelqu'un peut-il s'il vous plaît expliquer pourquoi cela a été voté? Je viens de copier-coller de la page de manuel (et donc d’être attribué). Cela aidera les autres à comprendre comment publier sur SE. Merci.
Hopping Bunny le
Je peux expliquer: c'est un choc culturel. Ne t'inquiète pas. Consultez les autres réponses, commentaires ...
-3

Je voudrais développer la réponse de @ gary.

En plus de son réponse: la lncommande peut accepter un nombre arbitraire d'arguments, ce qui vous permet de créer plusieurs liens symboliques en une seule invocation (ce qui est pratique lorsque vous en avez besoin).

  1. Avec cette connaissance, quand vous rencontrez ln -s foo bar baz, quelle est l'explication la plus logique que les arguments veulent dire quoi?
  2. Avec la réponse à # 1, quand vous rencontrez ln -s foo bar, quelle est l'explication la plus logique qui soit, quel argument veut dire quoi?
Yegle
la source
1
Si vous avez un ajout à la réponse de Gary, veuillez le suggérer en tant que vérification. En l'état, vos deux dernières questions (hypothétiques?) Font en sorte que cette "réponse" ressemble davantage à une deuxième question.
Jeff Schaller
-3

Imaginez une version de celle- lnci vous permettant de créer plusieurs liens (symboliques) en une seule commande.

Synopsis: ln -s TARGET NEW_LINK...
Example: ln -s target_file  new_link_1  new_link_2  new_link_3

Cela ne servirait à rien puisque inverser cela, puisqu'un lien symbolique ne peut pointer que l' TARGETun après l'autre et la convention normale de la ligne de commande est de mettre la partie répétée à la fin de la ligne de commande, par exemplegrep PAT [FILE]...

jrw32982 prend en charge Monica
la source
-6

" lsmontre a -> bsi ln a b"

Rappelez-vous simplement que c'est faux.

Oh mon Dieu
la source
6
Je me souviens toujours de "quelque chose-quelque chose ne va toujours pas". Mais de quel côté est le problème? C'est le problème. Le problème devient alors mon deuxième doute moi-même, même lorsque je le fais correctement. Parce que je ne me souviens pas du bon ordre!
Zhro
Je pense comprendre ce que vous voulez dire: le résultat de ls -l: link -> targetpeut confondre votre idée de la configuration de la lnligne de commande. Mais je crains que cela ne va pas aider beaucoup.
sudodus le