Dicas para lembrar a ordem dos parâmetros para ln?

Eu digo " lné como cp. A 'fonte' precisa vir primeiro."

Eu uso o seguinte: lntem um formulário de um argumento (2º formulário listado na página de manual ) no qual apenas o destino é necessário (porque como poderia lnfuncionar sem conhecer o destino) e lncria o link no diretório atual. A forma de dois argumentos é uma adição à forma de um argumento, portanto, o alvo é sempre o primeiro argumento.

A maioria dos Unices documenta o lncomando como

ln source target

(Estou omitindo opções etc. aqui)

Exemplos:

• O padrão 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 ]
  

O manual GNU lné o estranho e chama o source destino e o nome do target link .

• Manual GNU paraln

    ln [option]… [-T] target linkname
  

Ignorando a escolha de palavras do GNU, o lnutilitário segue a mesma semântica que, por exemplo, mve cpem que o destino é o que é criado a partir da fonte .

Portanto,

ln -s a b

criaria o link simbólico bapontando para a. Ou seja, bé o alvo da operação que cria um link simbólico usando acomo fonte.

Observe que ao criar links simbólicos , a fonte é simplesmente uma string representando o que o link simbólico deve apontar. Geralmente, não há verificação feita para validar que aponta para algo útil:

$ 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

Um pensamento pessoal sobre a escolha do GNU de usar "target" e "link name" em vez de "source" seguido de "target":

Pode parecer óbvio que o segundo argumento, a coisa que é criada, deve ser o "nome do link" e que o primeiro argumento, o destino do link, é "destino". No entanto, isso só é verdade quando você usa o link.

Quando você cria o link, que é o que você está fazendo com ln, o segundo argumento, o que é criado, é o "destino" da lnoperação, e é criado usando o primeiro argumento, a "origem".

Isso, junto com a ordenação análoga "fonte"->"destino" de argumentos para outras ferramentas básicas, faz com que a documentação não-GNU lnpareça mais natural.

Recentemente, ouvi uma ótima maneira de lembrar essa coisa em particular: uma rima

Algo velho, algo novo,

algo emprestado, algo azul,

e seis pence em seu sapato.

O primeiro verso é quais são os argumentos de ln: algo antigo seguido por um nome da nova entrada do diretório.

Caso isso ajude alguém: eu me acostumei a pensar nisso como "ln what where ", o que me ajuda a lembrar que o primeiro argumento ("what") é o arquivo existente, o segundo ("where") é o local para colocar (um link para) ele. Ao contrário do raciocínio na maioria das outras respostas, isso nada mais é do que uma frase concisa que posso recitar mentalmente para mim mesmo enquanto digito um comando, que serve como auxiliar de memória. Isso provavelmente não será útil para todos, mas suspeito que ajudará algumas pessoas.

Ajuda que os outros comandos de manipulação de arquivos padrão usem a mesma convenção, para que eu possa fazer o mesmo para cpe mv.

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; 

De 1971 Manuais Unix Primeira Edição .

Existe uma segunda forma de sintaxe simples.

Eu coloco FILE ou FILENAME em vez de TARGET --- veja comentários etc. Veja também adição muito longa na parte inferior, abordando o iceberg, duro e mole de ln, não apenas a ponta dele.

Então o GNU lntem isso:

ln [opt] FILENAME

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

onde você não precisa do nome do link. Depois ln -s /usr/lib/modulesde obter um

modules -> /usr/lib/modules

com o mesmo nome de FILENAME ("destino" ou "origem"), exatamente onde você está. Sem escolha, sem confusão.

Agora, se você for mais exigente e quiser que o link seja criado com outro nome e/ou outro lugar , adicione esse desejo como nome ou caminho. O alvo real vem em primeiro lugar, o novo nome de link extra sofisticado em segundo lugar.

Ou você diz: "Eu conheço essa notação de seta ls -lpara links. Eu não tenho uma seta no shell para mostrar a direção do meu link. Então eu tenho que dar a volta por cima."

Você a cria em uma direção, para que possa usá-la na outra.

(FIM DA PARTE RESPOSTA À PERGUNTA)

Em outro nível, a própria palavra "link" carrega um duplo significado profundamente oculto. Links simbólicos vieram mais tarde, então nos primeiros dias um link era apenas um link. Não havia macio e duro, não havia -sopção. E agora até uso o simbolismo fonte-alvo:

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

Nesta fase, existem links, mas não hard e soft, e ls -lnão apresenta setas, pois não há direção em um link (hard). Um "link" nesse estágio de evolução do unix significava que o nome de arquivo "B" (entrada de diretório "B") no sistema de arquivos aponta para o mesmo inode que o nome de arquivo "A" está apontando.

Os arquivos A e B estão "vinculados" entre si, pois compartilham os mesmos blocos. Então agora com cada rm, o kernel tem que verificar: eu apago/libro os blocos deste arquivo no disco, ou existe outro arquivo vinculado aos mesmos blocos? Para isso, é utilizado um contador de links.

Digamos que você queira evitar que um arquivo grande em /tmp seja excluído e faça ln /tmp/bigfile. Agora você tem um grande arquivo grande em seu diretório de trabalho. Depois de limpar /tmp e remover o "original", você continua usando os mesmos blocos de dados. Você não recebe um link morto ou pendente, você tem um arquivo normal. Apontando para nenhum arquivo, mas apenas blocos do sistema de arquivos, como todas as entradas de diretório. Só que agora "limpar" /tmp não é tão eficaz quanto era. Parece vazio, e é, mas os blocos na partição não são liberados.

Mesmo que um link físico não custe espaço em si cp, ele pode indiretamente.

Adicionando ln -sà sequência acima:

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

Agora "B", o soft link, tem apenas uma string com um nome de caminho. Esta é uma informação "suave". Tecnicamente "A" e "B" não estão relacionados. Mas ainda B é um "link" no novo sentido de que você pode usar esse nome de caminho armazenado como um atalho para "A". Agora é "um link para A" (ponto) e não "vinculado ao inode do arquivo A"

Ambos os tipos de links podem confundir não apenas os humanos, mas também o kernel/fs. A página de manual de 1971 observa: "BUGS: links são copiados duas vezes e restaurados como arquivos separados com inodes separados."

Links físicos para diretórios (raros/não permitidos) podem facilmente levar a um entupimento.

Soft links para diretórios (muito comuns) podem levar a loops eternos - estes precisam ser reconhecidos por utilitários/kernel.

Exemplo prático no bash

Começando com um arquivo normal "F"...

ln F Fhard

...faz com que Fhard tenha o mesmo tamanho de F, mas ambos aparecem agora em vermelho escuro SEM setas em ls -l --color. Por statmostrar "Links: 2" em conexão com "Inode: xyz". O hard linking F transforma o próprio F em um hard link. Ambos são/permanecem o tipo de arquivo "arquivo regular". Mas ambos têm um inode com uma contagem de links acima de 1.

   ln -s F Fsoft

...faz um pequeno arquivo "não regular" "Fsoft" com o tipo de arquivo "link simbólico" --- economizando ainda mais espaço do que um diretório vazio. A ls -lnão mostra nada de especial para "F". Para Fsoft, o tamanho mostrado é de 1 byte, pois a string é 'F' e Fsoft -> Fé exibida como nome. Não há necessidade de colorir um soft link para reconhecê-lo, porque na forma abreviada ls -Fvocê obtém uma corrente enrolada @anexada:Fsoft@

Com ls -lele fica assim:

-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 tem tamanho e tipo de F.

Fsoft tem o nome de F e o comprimento do nome de F como tamanho e um tipo de arquivo diferente.

Curto ls -sF:

5932 F    5932 Fhard     0 Fsoft@

a adição --block-size=1também não produz os mesmos tamanhos. Fsoft tem tamanho "um byte, zero blocos". F e Fhard se desviam em paralelo:

6074368 F  6074368 Fhard    0 Fsoft@

Para ver se o Fsoft está pendurado ou não, lspermite usar cores.

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

É muito útil lembrar que o nome do link é opcional. Se não for fornecido, o nome base do destino do link será usado.

ln -s /path/to/file1 file1

é idêntico a descartar completamente o nome do link:

ln -s /path/to/file1

Isso não faria sentido se o destino do link fosse mencionado por último.

Basta pensar em Unix -> AT&T -> destino à direita:

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

Semelhante ao cp, que eu li mentalmente como “copiar isso para aquilo”, eu li os comandos ln como “vincule isso a aquilo”.

Pessoalmente, prefiro evitar lembrar de X, em favor de saber onde procurar X quando preciso. Também sou fã da atitude "melhor prevenir do que remediar", então sempre gosto de verificar cuidadosamente o que estou escrevendo, especialmente como root.

Nesse caso, a resposta está literalmente nas primeiras linhas da página de manual:

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

Eu não teria sugerido isso se fosse necessário mergulhar na página de manual, mas como está bem no início, IMHO vale a pena os 3 segundos necessários para digitar man lne sair.