A expansão do nome do arquivo acrescenta uma barra a um link simbólico?

Question

Do manual de coreutils:

Some GNU programs (at least cp and mv) allow you to remove any trailing slashes from each source argument before operating on it. The --strip-trailing-slashes option enables this behavior.

This is useful when a source argument may have a trailing slash and specify a symbolic link to a directory. This scenario is in fact rather common because some shells can automatically append a trailing slash when performing file name completion on such symbolic links. Without this option, mv, for example, (via the system’s rename function) must interpret a trailing slash as a request to dereference the symbolic link and so must rename the indirectly referenced directory and not the symbolic link. Although it may seem surprising that such behavior be the default, it is required by POSIX and is consistent with other parts of that standard.

O negrito significa que a expansão de nome de arquivo por shell acrescenta uma barra a um link simbólico?

Onde você vê isso no manual Bash ou nas especificações POSIX?

Originalmente, pensei que cabe ao comando (em vez do shell) como interpretar um link simbólico com ou sem uma barra final, dada como seu argumento de linha de comando.

    

Answer 1

O comportamento exigido pelo POSIX é que mv interpreta uma barra como uma solicitação para excluir a referência do link simbólico. Ou seja, se foo for um link simbólico, POSIX afirma que mv (como qualquer outro comando) deve interpretar

mv foo/ bar/

como uma solicitação para mover o diretório apontado por foo , em vez de foo em si. Isso é indicado na seção sobre resolução do nome do caminho :

A pathname that contains at least one non-slash character and that ends with one or more trailing slashes shall be resolved as if a single dot character (.) were appended to the pathname.

Em outras palavras, foo/ é equivalente a foo/. .

O POSIX não permite, ou mesmo permite, que a expansão do nome do caminho adicione uma barra aos links simbólicos. Isso é algo que alguns shells fazem quando definem opções não padrão. Eu não sei se o bash tem uma opção para isso. Em ksh, é set -o markdirs . O Zsh também possui essa opção, mas afeta somente diretórios, e não links simbólicos para diretórios.

Existem outros casos em que uma barra final terminaria naturalmente no final de um parâmetro. Com um glob que termina com uma barra, o glob corresponde apenas a diretórios e links simbólicos para diretórios, e a expansão de nome de arquivo mantém a barra final. Portanto, mv a*/ /somewhere move todos os subdiretórios do diretório atual cujo nome começa com a e todos os destinos de links simbólicos no diretório atual, de forma que o link simbólico comece com a e o destino seja um diretório. Outro caso está em conclusão; Não vou entrar em detalhes porque o bash e o zsh têm tantas opções de conclusão, mas dependendo das opções pode ser bastante fácil acabar com foo/ quando completar foo e foo é um link simbólico para um diretório.

    

Answer 2

Does the bold mean that the filename expansion by shell appends a slash to a symbolic link?

Não. Isso significa que um shell pode fazê-lo plausivelmente, no caso em que o link aponta para um diretório, e que eles ofereceram a opção '--strip-trailing-slashes em parte, para permitir que o usuário evite o que, de outra forma, seriam efeitos colaterais dessa ação. Este é o significado literal do texto que você citou.

Where do you see this in Bash manual or POSIX specifications?

Em nenhum lugar, porque não é verdade. POSIX não especifica o comportamento de conclusão do nome do arquivo.

A segunda passagem em negrito refere-se ao comportamento descrito na frase imediatamente anterior em que você não negrita, e o Requisito de resolução de nome de caminho POSIX de que os caminhos que terminam em / devem ser tratados como diretórios , se possível, e resultar em erros, se não for possível. Não está se referindo à frase não relacionada anteriormente na passagem que você fez em negrito.

Originally I thought that it is up to the command (instead of the shell) how to interpret a symbolic link with or without a trailing slash given as its command line argument.

De fato, essa mesma opção é um exemplo desse fato.