As formas não canonizadas de caminhos do sistema de arquivos podem ser significativas? (por exemplo, “foo // bar”, “foo /./ bar” e “foo /../ bar”)

Question

Eu tenho um script para criar um sabor particular do compilador cruzado do GCC. Ao longo do script, há muitos caminhos que não estão no formato canônico, como os separadores de caminho duplicados ( /xxx/foo//bar/yyy ) e os diretórios "this" intervenientes ( /xxx/foo/./bar/yyy ).

Eu estava prestes a canonizar todos eles, mas me pergunto se essas formas são significativas, em vez de apenas um caso de o script não ser limpo. Além dos formulários mencionados, também estou curioso em saber se incluir um "diretório ativo" em um caminho também pode ser significativo em qualquer situação específica (por exemplo, " /xxx/foo/../bar/yyy em vez de /xxx/bar/yyy ). Por exemplo, um caminho como /xxx/foo/.//bar/yyy .

A única situação potencial em que consigo pensar é quando os links estão envolvidos. Posso imaginar que a forma .. possa se comportar de maneira diferente, mas e as outras duas formas acima?

Talvez haja também motivos específicos da plataforma para construir caminhos dessa maneira ...?

    

Answer 1

/./ você deve sempre ser capaz de recolher para / .
// geralmente deve ser colapsável, MAS eu vi os scripts de configuração verificarem, então eu suponho que pode haver sistemas onde não é o mesmo. Verifique, mas provavelmente ficará bem.
/../ só funcionará se o diretório anterior não for um symlink (ou, acredito, um hardlink). Como .. é um hardlink para seu diretório pai, ele vai até aquele branch, não aquele no caminho textual que você usa. (NB Seu shell pode ser configurado para não resolver links simbólicos em cd s, nesse caso ele irá para o diretório onde o link simbólico está; entretanto, este comportamento é quase inteiramente limitado a cd dentro de shells com este conjunto de opções.)

Use readlink -f "$path" , acredito que isso resolverá todos os casos corretamente.