Suggerimenti per ricordare l'ordine dei parametri per ln?

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?

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.

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

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 .

• Manuale GNU per ln

  ln [option]… [-T] target linkname
  

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

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.

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.

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

È 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.

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

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.

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

È 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).

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?

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]...

" lsmostra a -> bcosì ln a b"

Ricorda solo che è sbagliato.