Suggerimenti per ricordare l'ordine dei parametri per ln?


64

Ho usato lnper scrivere collegamenti simbolici per anni, ma continuo a correggere l'ordine dei parametri.

Questo di solito mi fa scrivere:

ln -s a b

e poi guardando l'output per ricordare a me stesso.

Immagino sempre di essere a -> bcome l'ho letto quando in realtà è il contrario b -> a. Questo sembra controintuitivo, quindi trovo che sono sempre secondo me stesso.

Qualcuno ha qualche consiglio per aiutarmi a ricordare l'ordine corretto?


11
a volte aiuta a dirlo a voce alta quando lo digiti in "link simbolico a a, e lo chiami b"
jsotola

2
Si crea il secondo parametro proprio come con cp e si crea il collegamento. Ma se lo capisci nel modo sbagliato, non preoccuparti, perché non puoi sovrascrivere un file esistente o un link simbolico con un nuovo link.
sudodus,


1
Pensalo come un "alias del cattivo". Viene sempre indicato prima con il suo vero nome, poi con i suoi alias. Es: Tony Baloney aka Oscar Meyer. O nel caso del tuo link, ln -sab significa "File-a è anche noto come File-b".
Scottie H,

1
ln source target. Uguale a cp source target, mv source target; ...
user207421

Risposte:


40

Uso quanto segue: lnha un modulo a argomento singolo (2 ° modulo elencato nella manpage ) in cui è richiesto solo il target (perché come potrebbe lnfunzionare senza conoscere il target) e lncrea il collegamento nella directory corrente. La forma a due argomenti è un'aggiunta alla forma a un argomento, quindi l'obiettivo è sempre il primo argomento.


3
Si noti che il modulo senza percorso di destinazione / destinazione è un'estensione della specifica POSIX di ln.
Kusalananda

1
@kusa: hai visto il manuale del 1971 nella mia risposta con il modulo a argomento unico? Come può essere un'estensione di posix se fosse lì nel 1971? --- "Se si specifica name2, il collegamento ha quel nome"

@SP Non sono sicuro di aver capito cosa intendi. Stai dicendo che un'implementazione storica supera in qualche modo l'attuale standard POSIX?
Kusalananda

1
Vedo anche io. Nomi diversi, stessi argomenti, almeno. Non avevo idea che Gnu fosse l'unico con questi nomi arg.

2
Ci sono state molte buone risposte qui (in particolare la rima di @loa_in_) ma ho intenzione di andare con questo. Dichiarare che l'ordine dei parametri è coerente (ignorando -t), quindi sembra quasi una prova. " lncrea il collegamento nella directory corrente. Il modulo a due argomenti è un'aggiunta al modulo a un argomento e quindi la destinazione è sempre il primo argomento". Poiché ha senso che ciò avvenga considerando la seconda forma, penso che questo mi aiuterà a ricordare.
Zhro

85

Vado " lnè come cp. La 'fonte' deve venire prima."


20
... e mi piace mv. mv, cpE lntutti prendono un file esistente come primo argomento, e il file di destinazione o il nome di directory come secondo argomento.
Hans-Martin Mosner,

7
È un peccato che memcpy, strcpyecc. , Facciano il contrario.
Arkadiusz Drabczyk,

6
@ Hans-MartinMosner, tranne per il fatto che quando si crea un collegamento simbolico, non deve essere un file esistente ...
ilkkachu

1
@ilkkachu Hai ragione. Nessuna regola senza eccezioni :-)
Hans-Martin Mosner,

1
@ArkadiuszDrabczyk D'altra parte, qualcosa come le memcpy(dest,src,n);mappe molto bene dest = src;. In altre parole, impostare (i primi nbyte di) dest uguale a (i primi nbyte di) src.
un CVn il

10

La maggior parte degli Unici documenta il lncomando come

ln source target

(Sto omettendo le opzioni ecc. Qui)

Esempi:

  • Lo standard POSIX

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

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

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

    ln [-Ffhinsv] source_file [target_file]
    
  • Solaris

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

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

Il lnmanuale GNU chiama la source destinazione e il nome del target collegamento .

Ignorando la scelta di parole GNU, l' lnutilità segue lo stesso tipo di semantica di eg mve cpin quanto l' obiettivo è ciò che viene creato dalla sorgente .

Perciò,

ln -s a b

creerebbe il collegamento simbolico che bpunta a a.

Si noti inoltre che durante la creazione di collegamenti simbolici , l'origine è semplicemente una stringa che rappresenta ciò a cui dovrebbe puntare il collegamento simbolico. Di solito non viene effettuato alcun controllo per confermare che punti a qualcosa di 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

5
Incolpo completamente la documentazione GNU per il fatto che le persone sbagliano. La loro formulazione è comprensibile col senno di poi ma obiettivamente confusa.
Konrad Rudolph,

6
@KonradRudolph, al contrario, la formulazione GNU mi sembra perfetta. L'utilità crea un collegamento con un nome, che punta da qualche parte. "Link name" è un pò ovvio, e "target" è una perfetta buona descrizione di qualcosa che è puntato a . Come aneddoto, a volte devo ancora pensare in che modo ln -s a bfunziona e ciò non ha nulla a che fare con la formulazione GNU, dal momento che non penso di aver mai visto il fraseggio nella pagina man. : D (È più semplice correre ln -si a bse non b
sei

1
@KonradRudolph, sebbene tecnicamente, chiamarlo "target" nel caso di un hard link è sbagliato , dal momento che non è il nome esistente ma l'inode è il target effettivo. Mi chiedo se la gente GNU pensasse che un utente comune non avrebbe dovuto pensarci in modo così dettagliato.
ilkkachu,

È interessante sottolineare, come menzionato nei commenti della risposta di @ gary, che l' obiettivo non è facoltativo nello standard POSIX.
Zhro

@kusa: con "ln -s AB --- copia solo il nome del file in B" Ho adottato la tua interpretazione in un contesto leggermente cambiato. Posso anche essere d'accordo con il tuo radicale esempio di "ciao mondo". "Solo il nome del file 'È una stringa. Voglio solo segnalarti che ho modificato un po' e aggiunto molto.

7

Nel caso questo aiuti qualcuno: mi sono abituato a pensarlo come "ln cosa dove ", il che mi aiuta a ricordare che il primo argomento ("cosa") è il file esistente, il secondo ("dove") è il posto per metterlo (un link a). A differenza del ragionamento nella maggior parte delle altre risposte, questo non è altro che una frase pithy che posso recitare mentalmente a me stesso mentre sto digitando un comando, che serve da ausilio alla memoria. Questo probabilmente non sarà utile a tutti, ma sospetto che possa aiutare alcune persone.

Aiuta gli altri comandi standard di manipolazione dei file a utilizzare la stessa convenzione, quindi posso fare lo stesso per cpe mv.


4
Sono curioso di avere un'idea del perché questo è stato sottoposto a downgrade. Non c'è molto qui che potrebbe essere sbagliato - ho confuso l'ordine o qualcosa del genere?
David Z,

Personalmente penso che "In quale luogo" non è ancora inequivocabile senza la spiegazione: quale potrebbe essere o "a cosa sta puntando il collegamento?" (corretto) o "che cosa sta collegando a qualcosa?" (sbagliato). Lo stesso con dove: "dove punta il link?" (errato) o "dove deve essere creato il collegamento" (corretto). Quindi questo non aiuta necessariamente tanto se stai indovinando te stesso. Ricordare cp e mv dovrebbe aiutare però.
125_m_125

Ci aspettiamo tutti che un comando UNIX includa i suoi argomenti di file dopo altri tipi di argomenti (come fa grep, per esempio). Crea un file di un certo tipo con un determinato contenuto. Che il filesystem faccia qualcosa di speciale e di solito inseriamo il percorso di alcuni file sorgente in esso è secondario. Per esempio, potrei scrivere un editor di testo che memorizza il contenuto della sua prima riga in un link simbolico chiamato 1, ecc. Questo sarebbe stupido ma sottolinea che ln crea un qualche tipo di file con alcuni contenuti di testo, niente di più o di meno, e rende logico l'ordine degli argomenti.
Dannie,

@ 125_m_125 L'interpretazione alternativa che hai presentato non ha molto senso per me, ma va bene; questo aiuto di memoria non è per tutti.
David Z,

6

Di recente ho sentito un ottimo modo per ricordare questa cosa particolare: una rima

Qualcosa di vecchio, qualcosa di nuovo,

qualcosa in prestito, qualcosa di blu,

e un sixpence nella sua scarpa.

Il primo verso è quello che sono gli argomenti di ln: qualcosa di vecchio seguito da un nome della nuova voce della directory.


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; 

Dal 1971 Manuali Unix Prima edizione .

Esiste una seconda , semplice forma di sintassi.


edit: ho messo FILE o FILENAME invece di TARGET --- vedere i commenti ecc vedi anche molto lungo, oltre al fondo, rivolgendosi al iceberg, duro e morbido di ln, non solo la punta di esso.


Quindi GNU lnha questo:

ln [opt] FILENAME

In the 2nd form, create a link to FILENAME in the current directory.

dove non è necessario il nome del collegamento. Dopo ln -s /usr/lib/modulesaver ottenuto un

modules -> /usr/lib/modules

con lo stesso nome di FILENAME ("target" o "source"), proprio dove ti trovi. Nessuna scelta, nessuna confusione.

Ora, se sei più esigente e desideri che il link venga creato con un altro nome e / o da qualche altra parte , aggiungi quel desiderio come nome o percorso. Il vero obiettivo viene prima di tutto, il nuovo nome di fantasia extra secondo.


Oppure dici: "Conosco questa notazione di freccia ls -lper i collegamenti. Non ho una freccia nella shell per mostrare la direzione del mio collegamento. Quindi devo girarlo."

Lo crei in una direzione, quindi puoi usarlo nell'altra.

(FINE DI RISPOSTA ALLA PARTE DOMANDA)


Ad un altro livello, la parola "link" stessa ha un doppio significato nascosto. I collegamenti simbolici sono arrivati ​​dopo, quindi all'inizio un collegamento era solo un collegamento. Non c'è stato morbido e duro, nessuna -sopzione. E ora uso persino il simbolismo sorgente-bersaglio:

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

In questa fase, ci sono collegamenti, ma non hard e soft, e ls -lnon mostra le frecce, perché non c'è direzione in un (hard) link. Un "collegamento" in quella fase dell'evoluzione unix significava che il nome file "B" (voce di directory "B") nel filesystem punta allo stesso inode del nome file "A".

I file A e B sono "collegati" insieme, perché condividono gli stessi blocchi. Quindi ora con ogni rm, il kernel deve controllare: posso cancellare / liberare i blocchi di questo file sul disco o c'è un altro file collegato agli stessi blocchi? Per questo, viene utilizzato un contatore di collegamenti.

Supponiamo che tu voglia mantenere un file di grandi dimensioni su / tmp grom da eliminare e farlo ln /tmp/bigfile. Ora hai un grosso file nella directory di lavoro. Dopo aver pulito / tmp e rimosso l'originale, si continua felicemente a utilizzare gli stessi blocchi di dati. Non ottieni un collegamento morto o penzolante, hai un file normale. Indicando nessun file ma solo il filesystem si blocca come fa ogni voce dir. Solo ora "cleaning" / tmp non è così efficace come lo era. Sembra vuoto, e lo è, ma i blocchi sulla partizione non vengono liberati.

Anche se un hard link non costa spazio stesso come cp, indirettamente, può farlo.

Aggiungendo ln -salla sequenza sopra:

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

Ora "B", il soft link, ha solo una stringa con un nome percorso. Queste sono informazioni "soft". Tecnicamente "A" e "B" non sono correlati. Ma ancora B è un "collegamento" nel nuovo senso che è possibile utilizzare quel percorso memorizzato come scorciatoia per "A". Ora è "un collegamento ad A" (punto) e non "collegato all'inode del file A"

Entrambi i tipi di collegamenti possono confondere non solo gli umani ma anche il kernel / fs. La pagina man del 1971 nota: "ERRORI: i collegamenti vengono sottoposti a backup due volte e ripristinati come file separati con inode separati".

I collegamenti rigidi alle directory (rari / non consentiti) possono facilmente causare un intasamento.

I collegamenti soft alle directory (molto comuni) possono portare a cicli eterni - devono essere riconosciuti da utility / kernel.

Esempio pratico in bash

A partire da un normale file "F" ...

ln F Fhard

... rende Fhard delle stesse dimensioni di F, ma ENTRAMBE appaiono ora in un rosso scuro SENZA frecce all'interno ls -l --color. A causa della statvisualizzazione di "Link: 2" in connessione con "Inode: xyz". L'hard linking F trasforma F stesso in un hard link. Entrambi sono / stay il tipo di file "file normale". Ma entrambi hanno un inode con un conteggio dei collegamenti superiore a 1.

   ln -s F Fsoft

... crea un piccolo file "non regolare" "Fsoft" con il tipo di collegamento "link simbolico" --- ancora più spazio di un dir vuoto. A ls -lnon mostra nulla di speciale per "F". Per Fsoft, la dimensione visualizzata è 1 byte in quanto la stringa è 'F' e Fsoft -> Fviene visualizzata come nome. Non è necessario colorare un collegamento software per riconoscerne uno. Perché in forma abbreviata ls -Fsi @ aggiunge una catena a spirale :Fsoft@

Con ls -lsembra così:

-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 ha dimensioni e tipo di F.

Fsoft ha il nome e la lunghezza del nome F come dimensione e un diverso tipo di file.

Breve ls -sF:

5932 F    5932 Fhard     0 Fsoft@

l'aggiunta --block-size=1non produce nemmeno le stesse dimensioni. Fsoft ha dimensioni "un byte, zero blocchi". F e Fhard si discostano in parallelo:

6074368 F  6074368 Fhard    0 Fsoft@

Per vedere se Fsoft è penzolante o meno, lsti consente di usare i colori.

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

2

È davvero utile ricordare che il nome del collegamento è facoltativo. Se non viene specificato, viene utilizzato il nome di base della destinazione del collegamento.

ln -s /path/to/file1 file1

è identico a eliminare completamente il nome del collegamento:

ln -s /path/to/file1

Ciò non avrebbe alcun senso se il target del link fosse menzionato per ultimo.


1

Basti pensare a Unix -> AT&T -> destinazione a destra:

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

"cp foo bar" significa "to bar". "ln abc def" significa "abc". Se avessi mantenuto i simboli: "to foo". Questo è esattamente il problema.

@ user370539 Questo è semplicemente non vero; dopo ln abc def, abce defsono lo stesso oggetto; sono indistinguibili. Inoltre, l'operazione non ha alcun effetto abc, se non quello di aumentare il conteggio dei collegamenti. La destinazione è def. Un puntatore all'oggetto è stato appena installato nella defposizione.
Kaz,

@ user370539 Se il collegamento è simbolico, ln -s abc defsignifica che il contenuto abcè scritto nella posizione def. abcnon deve nemmeno risolvere nulla; può essere un anello penzolante.
Kaz,

Il tuo commento è esattamente ... sbagliato. Dovrebbe essere il contrario.
rexkogitans,

@rexkogitans Il mio punto è che è coerente. Se l'ordine è "sbagliato" e dovrebbe essere invertito, allora dovrebbe essere per tutti quei comandi: mv dest src, ln [ -s ] dest src, cp dest src, ...
Kaz

0

Personalmente, preferisco evitare di ricordare X, a favore di sapere dove cercare X quando ne ho bisogno. Sono anche un fan dell'atteggiamento "meglio prevenire che curare", quindi mi piace sempre controllare attentamente ciò che sto scrivendo, soprattutto come root.

In questo caso, la risposta è letteralmente nelle prime righe della manpage:

   ln [OPTION]... [-T] TARGET LINK_NAME
   (...)
   In the 1st form, create a link to TARGET with the name LINK_NAME.

Non l'avrei suggerito se fosse necessario approfondire la manpage, ma poiché è giusto all'inizio, IMHO vale i 3 secondi necessari per digitare man lned uscire.


-1

Simile a cp, che leggo mentalmente come "copia questo in quello", leggo i comandi come "collega questo a quello".


2
Questo è molto simile alla risposta più votata .
Michael,

Quindi "ln -s AB" collega A a B? Ora è A -> B o B -> A? Penso che la maggior parte non abbia nemmeno superato il primo stadio di confusione. Dicono che sia semplice, ma è solo sbagliato.

-2

È così che me lo ricordo: dimentica il bersaglio. In altre parole, se mi trovo in dir1 e voglio creare qui un link simbolico al file1 che esiste in / some / other / dir /, farei semplicemente:

ln -s /some/other/dir/file1

Otterrai un link simbolico chiamato file1 in dir1 che punta a / some / other / dir / file1. Dalla pagina man di ln:

[OPZIONE] ... TARGET (2 ° modulo) ... Nel 2 ° modulo, creare un collegamento a TARGET nella directory corrente.

Tieni presente che questo funziona solo se vuoi che il link simbolico abbia lo stesso nome del target (che molto probabilmente è il caso).


Qualcuno può spiegare perché questo è stato sottoposto a downgrade? Ho appena copiato e incollato dalla pagina man (e di conseguenza attribuito). Aiuterà gli altri a capire come pubblicare post su SE. Grazie.
Hopping Bunny il

posso spiegare: è uno scontro culturale. Non ti preoccupare. Controlla le altre risposte, commenti ...

-3

Vorrei espandere la risposta di @ gary.

Oltre alla sua risposta: il lncomando può accettare un numero arbitrario di argomenti, in modo da poter creare più collegamenti simbolici in un'unica chiamata (che è utile quando ne hai bisogno).

  1. Con questa conoscenza, quando ti imbatti ln -s foo bar baz, qual è la spiegazione più logica quali argomenti significano cosa?
  2. Con la risposta al n. 1, quando ti imbatti ln -s foo bar, qual è la spiegazione più logica di quali argomenti significhino cosa?

1
Se hai un'aggiunta alla risposta di Gary, ti preghiamo di suggerirla come modifica. Così com'è, le tue due domande finali (ipotetiche?) Rendono questa "risposta" più simile a una seconda domanda.
Jeff Schaller

-3

Immagina una versione lnche ti ha permesso di creare più collegamenti (simbolici) in un solo comando.

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

Non farebbe nulla da allora per invertire ciò, poiché un collegamento simbolico può puntare solo a uno TARGETalla volta e la normale convenzione della riga di comando è quella di mettere la parte ripetuta alla fine della riga di comando, ad es.grep PAT [FILE]...


-6

" lsmostra a -> bcosì ln a b"

Ricorda solo che è sbagliato.


6
Ricordo sempre "qualcosa, qualcosa è sempre sbagliato". Ma da che parte è sbagliato? Questo è il problema. Il problema diventa quindi il mio secondo tentativo di indovinare me stesso anche quando lo capisco bene. Perché in realtà non riesco a ricordare l'ordine corretto!
Zhro

Penso di capire cosa intendi: l'output di ls -l: link -> targetpuò confondere la tua idea di come impostare la lnriga di comando. Ma temo che non aiuterà molto.
sudodus,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.