Percebi no Ubuntu que os seguintes comandos vão para locais aparentemente diferentes no sistema de arquivos, mas os locais têm os mesmos arquivos:
cd /
cd //
ls-ing de ambos os locais produz o mesmo resultado:
vm@virtual-machine://$ ls
bin dev initrd.img lib64 mnt root snap sys var
boot etc initrd.img.old lost+found opt run srv tmp vmlinuz
cdrom home lib media proc sbin swapfile usr
Existe uma distinção nos comportamentos destes para aparentemente diferentes, mas os mesmos caminhos de arquivo?
Nota: ' cd ///
' não é um caminho de arquivo válido, mas ' //usr/
' e ' //bin/
' são caminhos válidos.
Nota-2: Então, executando cd .. em cada aponta para si mesmo, então // -> cd .. -> //
e/ -> cd .. -> /
De acordo com a especificação POSIX, os caminhos que começam com exatamente duas barras têm semântica definida pela implementação.
Várias barras em um caminho são recolhidas em uma barra, exceto no caso em que há exatamente duas barras exatamente no início do caminho.
Assim,
/foo
,///foo
,////foo
, e///////////////////foo
são garantidos como sendo o mesmo caminho,/foo/bar
,/foo//bar
,/foo///bar
e assim por diante são garantidos como sendo o mesmo caminho, mas/foo
e não//foo
são garantidos como sendo o mesmo caminho, e nem são e – qualquer implementação pode definir a semântica como eles desejam. Eles podem escolher definir para significar a mesma coisa que e , mas não precisam .//foo
///foo
//foo
/foo
///foo
A intenção é que os sistemas operacionais possam usar caminhos começando com
//
para implementar semânticas diferentes da semântica do sistema de arquivos POSIX.Por exemplo, um híbrido hipotético de Windows e Unix poderia usar
//
a semântica do sistema de arquivos do Windows. Cygwin realmente usa//
para caminhos de rede, semelhante a como o Windows usa\\
.No Cygwin, por exemplo,
cd //; ls
listaria todos os servidores de arquivos SMB na rede local, não o diretório raiz!