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

Estou trabalhando em um script python que passa os locais dos arquivos para um subprocesso scp. Tudo bem, mas estou em uma 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ê tiver vários separadores de arquivos, mas estou me perguntando como exatamente isso é corrigido. É o bash que tira /s extras ou isso realmente não importa nunca?

Eu pergunto porque isso me poupará várias linhas de código para verificar se há /s extras enquanto concatenamos. Sei que não é grande coisa, mas também estou curioso. 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

São permitidas várias barras e são equivalentes a uma única barra. Na especificação Single Unix (versão 3) , as definições de base §3.266 nome do caminho : "Várias barras sucessivas são consideradas iguais a uma barra".

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

Um final /no final de um nome de caminho força o nome do caminho a se referir a um diretório. Nas definições de base ( POSIX 1003.1-2001 (Single Unix v3), §4.11 , resolução de nome de caminho , um final /é equivalente a um final /.. As definições de base POSIX 1003.1-2008 (Single Unix v4), §4.12, eliminam o requisito de torná-lo equivalente /., a fim de para lidar com diretórios inexistentes (por exemplo, mkdir foo/é necessário que funcione, enquanto mkdir foo/.que não - veja a lógica da mudança).

Para programas que atuam em uma entrada de diretório, se foohouver um link simbólico para um diretório, a passagem foo/é uma maneira de fazer com que o programa atue 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 maneira diferente. Por exemplo, basenamee dirnameignore as barras finais.}

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

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

http://docs.python.org/library/os.path.html#os.path.normpath

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

Um nome de caminho que começa com duas barras sucessivas pode ser interpretado de uma maneira definida pela implementação, embora mais de duas barras principais sejam tratadas como uma única barra.

portanto, ele pode ser tratado especialmente, dependendo do seu sistema. (Algumas versões mais antigas do Unix usavam uma vantagem dupla /para acesso remoto ao sistema de arquivos, e ainda pode haver outras que o fazem.)

Use os.path.joinem Python e você não terá várias barras. A criação de nomes de arquivos concatenando seqüências de caracteres é considerado um estilo pobre do Python.

Não há diferença.

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

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

Obviamente, você pode normalizar um caminho com possíveis múltiplos / (barras) passando-o através tr -s

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

... e depois use $NORMALIZED

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