Como o Linux lida com vários separadores de caminho consecutivos (/ home //// username /// file)?

Question

Estou trabalhando em um script python que passa os locais dos arquivos para um subprocesso scp. Tudo bem, mas estou numa situação em que posso acabar concatenando um caminho com um nome de arquivo, de modo que haja um duplo ' / no caminho. Eu sei que o bash não se importa se você tem vários separadores de arquivos, mas eu estou querendo saber exatamente como isso é retificado. É o bash que tira / s extra ou isso realmente não importa nunca?

Eu pergunto porque ele me salvará várias linhas de código para verificar se há / s extras durante a concatenação. Eu sei que não é grande coisa, mas estou curioso também. Eu tenho um script bash que tem a linha cd //usr (em vez de cd /usr ), o que parece implicar que pode haver um significado para usar vários / s em um caminho

    

Answer 1

Várias barras são permitidas e equivalem a uma única barra. Da Especificação Unix única (versão 3) , definições básicas §3.266 nome do caminho :“ Várias barras sucessivas são consideradas as mesmas que uma barra. ”

Existe uma exceção: se um nome de caminho começa com exatamente duas barras, ele pode ser tratado de forma diferente (ref: definições básicas §4.11 resolução do nome do caminho ). O próprio Linux não faz isso, embora alguns aplicativos possam, e outros sistemas unix-ish (por exemplo, Cygwin).

Um / no final de um nome de caminho força o nome do caminho a se referir a um diretório. Em ( definições base POSIX 1003.1-2001 (Single Unix v3) §4.11 resolução do nome do caminho , um / à direita é equivalente a um /. à direita. POSIX 1003.1-2008 (Single Unix v4 ) definições de base §4.12 elimina o requisito para torná-lo equivalente a /. , a fim de lidar com diretórios não existentes (por exemplo, mkdir foo/ é necessário para trabalhar, enquanto mkdir foo/. não - ver o justificativa para a mudança).

Para programas que agem em uma entrada de diretório, se foo for um link simbólico para um diretório, então passar foo/ é uma maneira de fazer o programa agir no diretório em vez do link simbólico.

¹ _{Observe que isso se aplica apenas à resolução do nome do caminho, ou seja, ao acessar arquivos. Manipulações de nome de arquivo podem funcionar de forma diferente. Por exemplo, basename e dirname ignore as barras finais.}

    

Answer 2

O sistema operacional também não parece se importar com isso, tendo acabado de testar um programa em C com um syscall direto para abrir com // no caminho.

Você pode usar a função da biblioteca python os.path.normpath para normalizá-la, o que evita que você tenha que digitalizar através da string procurando extras. Outros idiomas têm funções semelhantes.

link

    

Answer 3

Em todos os sistemas Unix que eu vi, é o mesmo que um único / , mas o Padrão Unix especifica que

A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.

por isso pode ser tratado especialmente, dependendo do seu sistema. (Algumas versões mais antigas do Unix usaram um / duplo para o acesso remoto ao sistema de arquivos, e ainda pode haver algumas que o façam.)

    

Answer 4

Use os.path.join em Python e você não pegue várias barras. Criar nomes de arquivos por meio da concatenação de strings é considerado um estilo pobre do Python.

    

Answer 5

Não há diferença.

Várias barras são ignoradas (sem efeito), por exemplo:

ls -al //usr///////bin/sed

    

Answer 6

É claro que você pode normalizar um caminho com possíveis / (barras) nele, passando-o por tr -s

NORMALIZED=$(echo "$UNHYGIENIC" | tr -s / /)

... e, em seguida, use $NORMALIZED

No entanto, isso deve ser necessário. Eu sei que qualquer kernel UNIX deve ignorar os separadores de caminhos simultâneos - ou conceitualmente tratá-los como ... /./ ...