desenv-web-rp.com

Existe uma razão pela qual "." e ".." aparece depois de fazer ls -a?

Se eu executar ls -a

[email protected]:~$ ls -a
.           ..

Eu recebo . e .. (diretório atual e diretório pai?)

Existe uma razão para que eles apareçam após ls -a, eles fazem algo interessante?

14
Margo Oka

Porque -a significa mostrar todos os arquivos. É útil quando combinado com -l. Por que mostrar esses arquivos inúteis quando não está usando -l, devido à consistência e ao Unix não tentar adivinhar o que é bom para você.

Existe uma opção -A (pelo menos GNU ls) que exclui esses dois (.. e .).

Curiosamente, a idéia de arquivos ocultos no Unix surgiu por um bug em ls onde ele tentava ocultar esses dois arquivos. Para simplificar o código, a implementação original verificou apenas o primeiro caractere. As pessoas usavam isso para ocultar arquivos, e depois se tornaram um recurso, e o -a opção foi adicionada para mostrar os arquivos ocultos. Mais tarde, alguém se perguntou, como você, por que . e .. são mostrados, sabemos que eles estão lá. O -A opção nasceu.

Nota: O Unix tem um significado de arquivo muito mais flexível do que você pode ter.
ARQUIVO ⊇ {arquivo normal, diretório, pipe nomeado, soquete unix, link simbólico, dispositivos}.

67
ctrl-alt-delor

Como há um ponto para eles aparecerem lá?

Eles mostram a propriedade e as permissões. Geralmente, é a coisa mais importante a verificar quando você tem dois usuários e um diz que eles não podem ver o arquivo da outra pessoa que estavam esperando.

43
Aaron D. Marasco

Como mostrado em https://ss64.com/bash/ls.html quando você adiciona o -a parâmetro para ls
você recebe todas as entradas, mesmo as que começam com .; eles são considerados entradas ocultas e não são mostrados com um simples ls.

8
K7AAY

Existe uma razão para que eles apareçam após ls -a?

Eu apostaria que é apenas um acidente histórico, como muitas coisas são.


De acordo com um história de Rob Pike, os arquivos "ocultos" (dotfiles) foram criados por um acidente:

Há muito tempo, quando o design do sistema de arquivos Unix estava sendo elaborado, as entradas . e .. apareceu, para facilitar a navegação. Não tenho certeza, mas acredito que .. entrou durante a reescrita da Versão 2, quando o sistema de arquivos se tornou hierárquico (ele tinha uma estrutura muito diferente desde o início). Quando se digitou ls, no entanto, esses arquivos apareceram, então Ken ou Dennis adicionaram um teste simples ao programa. Estava no assembler, mas o código em questão era equivalente a algo como isto:

if (name[0] == '.') continue;

Essa afirmação foi um pouco mais curta do que deveria, que é

if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;

mas ei, foi fácil.

Duas coisas resultaram.

[...] Segundo, e muito pior, foi criada a idéia de um arquivo “oculto” ou “ponto”. Como conseqüência, mais preguiçoso programadores começaram a soltar arquivos no diretório pessoal de todos.

Com base nisso, não parece muito difícil adivinhar que ls -a foi adicionado para mostrar os arquivos de ponto criados por esses programadores preguiçosos. E a implementação simples para isso seria apenas desativar o teste acima, resultando em . e .. mostrando, novamente.

Independentemente do histórico, mostrá-los é o comportamento especificado no padrão agora:

-uma
Escreva todas as entradas do diretório, incluindo aquelas cujos nomes começam com um <período> ('.').

Mas há também ls -A para fazer a coisa um pouco mais saudável. Não sei quanto mais recente é essa:

-UMA
Escreva todas as entradas do diretório, incluindo aquelas cujos nomes começam com um <período> ('.'), Mas excluindo as entradas ponto e ponto (se existirem).


Eles fazem algo interessante?

Listá-los com ls simples não é muito interessante.

Mas procurando por ex. . no /path/subdir fornece o mesmo inode que procura por subdir em /path. A propriedade e as permissões do diretório controlam quem pode acessar os arquivos lá, para que seja recomendável que as informações estejam disponíveis por meio de ., também. No entanto, sempre se pode fazer ls -ld . ou ls -ld /path/subdir se eles precisarem das propriedades do próprio diretório.

7
ilkkachu

Esta opção ls requer mostrar todos os arquivos com ls -a...

Mas a existência física de . e .. na maioria dos sistemas de arquivos é um artefato da década de 1970, quando os computadores eram muito pequenos e as pessoas tentavam encontrar implementações que precisavam apenas de um tamanho pequeno de código. Isso resultou na criação de links físicos para o diretório atual e o diretório pai.

Desde mais de 30 anos isso é visto como um erro.

De fato, o UNOS (o primeiro clone do UNIX de 1980) não tinha . e .., meu WOFS (a primeira cópia no sistema de arquivos de gravação) e o ZFS também não os possuem.

O que é exigido pelo POSIX é apenas para lidar com dir/. e dir/.. da maneira esperada, quando passado para syscalls que manipulam nomes de arquivos.

Infelizmente, a maioria dos softwares atualmente ainda está mal escrita e apresenta problemas quando essas entradas estão ausentes, por isso o ZFS emula a existência ....

Como resultado, não é especificado se ls -a imprime linhas para . e ... Isso depende do sistema de arquivos. Se você estiver em um sistema de arquivos que não inclua entradas físicas para . e .. e que não pretende tê-los (como o ZFS), você precisa chamar: ls -ld . ..

BTW: POSIX decidiu recentemente que echo .* não é mais necessário incluir . e .., mesmo quando eles existem fisicamente. Uma vez que todas as conchas se comportem dessa maneira, será uma grande vitória.

5
schily

No Unix (folclore diz que por engano) nomes de arquivos/diretórios começando com . não foram mostrados por ls (porque os nomes . e .. havia sido reservado para "este diretório" e "pai deste diretório", e mostrá-los era considerado inútil). Então, usando essas peculiaridades, as pessoas começaram a usar nomes como .profile ou .something-or-other-rc (o RC é do Run Command, nome do arquivo de inicialização de outro sistema extinto) para arquivos (e diretórios) que eram "desinteressantes". Portanto ls -a (show a ll) e, é claro, ele mostrará . e ..

4
vonbrand

enquanto o design do sistema de arquivos Unix estava sendo elaborado, as entradas. e .. apareceu, para facilitar a navegação

Nenhuma resposta parece ter utilidade nessas entradas em primeiro lugar. De alguma forma, eles provêm da lista vinculada hierárquica. "Navegação fácil": não com ls, mas com um programa C usando readdir (3) ou mais.

Eu acredito .. entrou durante a reescrita da versão 2, quando o sistema de arquivos tornou-se hierárquico


Existe uma razão para que eles apareçam depois de ls -a, eles fazem algo interessante?

A) Sim (razões históricas/técnicas) B) Sim, a menos que você encontre cd .. desinteressante. (Ou clique no arquivo (pseudo) .. em um navegador de arquivos gráfico)

(OK, eles não precisam aparecer para serem usados ​​... é por isso que é uma opção e também há -A)


Até encontra em um diretório vazio:

]# find
.

Assim eu sei: o achado encontrou algo: nada.


]# stat  . .. |grep Device
Device: 36h/54d         Inode: 154051      Links: 6
Device: 803h/2051d      Inode: 393219      Links: 26
]# cd /
]# stat  . .. |grep Device
Device: 803h/2051d      Inode: 2           Links: 18
Device: 803h/2051d      Inode: 2           Links: 18

Isso define o topo da hierarquia. Os direntries de. e .. são idênticos no diretório superior /. E se você não perceber, um cd .. é como cd .. Não recebo uma mensagem, apenas funciona/falha silenciosamente.


Somente os campos d_name e (como uma extensão XSI) d_ino são especificados no POSIX.1. Além do Linux, o campo d_type está disponível principalmente apenas em sistemas BSD.

struct dirent {
           ino_t          d_ino;       /* Inode number */
           off_t          d_off;       /* Not an offset; see below */
           unsigned short d_reclen;    /* Length of this record */
           unsigned char  d_type;      /* Type of file; not supported
                                          by all filesystem types */
           char           d_name[256]; /* Null-terminated filename */
       };

A função readdir () retorna [um ponteiro para] uma estrutura dirent representando a próxima entrada do diretório no fluxo do diretório apontado pelo dirp.

Sem um campo de tipo, você (ls) precisaria examinar o conteúdo do inode antes que ele possa informar o arquivo, o diretório ou o canal. E sem o . e .., você teria que armazenar esses inodes em uma variável.


É assim que essas entradas podem simplificar a navegação, para o script e o usuário. A opção "1" faz isso com o diretório atual, fingindo . está contido nele, como um dir.

]# select ans in $(ls -af); do ls -l $ans; done
1) .
2) ..
3) child3
4) child2
5) child1
#? 1
total 0
drwxr-xr-x 2 root root 40 Feb 21 07:36 child1
drwxr-xr-x 2 root root 60 Feb 21 07:40 child2
drwxr-xr-x 2 root root 60 Feb 21 07:40 child3
#? 2   
total 0
drwxr-xr-x 5 root root 100 Feb 21 07:36 myself
drwxr-xr-x 2 root root  40 Feb 21 07:37 sibling1
drwxr-xr-x 2 root root  40 Feb 21 07:37 sibling2
#? 3
total 0
-rw-r--r-- 1 root root 0 Feb 21 07:40 f.b
#? 4
total 0
-rw-r--r-- 1 root root 0 Feb 21 07:40 f.a
#? 5
total 0

(Seria mais interessante se cds e depois listasse o novo diretório como uma seleção novamente, e assim por diante ...)

1
rastafile

Existe uma razão para que eles apareçam após ls -a, eles fazem algo interessante?

Bem, eles aparecem depois de ls -a porque essa é a função do - a alterne para ls . Você pediu ls para mostrar os arquivos que começavam com um ponto e assim foi. Receio que não haja uma resposta melhor; é para isso que serve - a .

O interessante que eles fazem é permitir especificação relativa do caminho. Você pode especificar um local de arquivo em relação ao padrão atual, e não como um caminho absoluto da raiz. Isso é muito útil, além de interessante.

0
Medievalist

Ninguém parece ter mencionado explicitamente a premissa básica de sistemas do tipo Unix1:

Tudo é um arquivo .

Isso inclui diretórios.

Desde a ls -a lista todos os arquivos e diretórios são arquivos, significa que . e .. seria incluído.

"Eles fazem algo interessante?"

Sim, eles fazem. Eles fornecem referências úteis; . representa o diretório atual e .. representa o diretório pai. Isso permite que você faça coisas como mv /file/elsewhere . e cd ... Claro, isso é pedantismo e você provavelmente já sabia disso. :)


1 Embora a resposta de @ ctrl-alt-delor implique isso.

0
Lorem Ipsum