Ls está mostrando algum script bash para o symlink morto em vez de um nome de arquivo

Question

Este é o diretório bin/ do Symfony PHP Framework, saída para ls -la
Por alguma razão, está mostrando um script bash em vez de um nome de arquivo. A versão do Linux é o Debian Stretch.

Esteéoresultadodocomandophpcomposer.pharupdateexecutadoatravésdoscriptAtlassianPipelines.Seomesmocomandoforexecutadomanualmente,tudoestáOK.Aparterelevantedobitbucket-pipelines.ymlseparececom

pipelines:custom:manual_preprod:-step:script:-ssh$PREPROD_USER@$PREPROD_HOST-t"cd ${FULLPATH} && php composer.phar update"

Eu suponho que há um bug no compositor php que faz com que ele forneça um conteúdo de arquivo em vez de um nome de arquivo ao criar o symlink? Como isso é possível?

O código parece ser de um dos scripts do compositor, BinaryInstaller.php

Editar:

Parece que é um problema do git + Windows para o Linux.

Esses arquivos foram adicionados ao git repo no Windows e, nesse sistema, são apenas arquivos regulares com o conteúdo, como

#!/usr/bin/env sh
dir=$(d=\${0%[/\\]*}; cd "\$d" > /dev/null; cd $binDir && pwd)
# See if we are running in Cygwin by checking for cygpath program
if command -v 'cygpath' >/dev/null 2>&1; then
    # Cygwin paths start with /cygdrive/ which will break windows PHP,
    # so we need to translate the dir path to windows format. However
    # we could be using cygwin PHP which does not require this, so we
    # test if the path to PHP starts with /cygdrive/ rather than /usr/bin
    if [[ $(which php) == /cygdrive/* ]]; then
        dir=$(cygpath -m "\$dir");
    fi
fi

após o comando git pull emitido no Debian Stretch, esses arquivos se tornam tais links simbólicos estranhos, o conteúdo se torna um nome de arquivo do arquivo de destino.

    

Answer 1

Parece que você tem core.symlinks definido como false no seu .gitconfig (globalmente ou local no seu repositório). De git-config(1) :

core.symlinks
If false, symbolic links are checked out as small plain files that contain the link text. git‑update‑index(1) and git‑add(1) will not change the recorded type to regular file. Useful on filesystems like FAT that do not support symbolic links.

The default is true, except git-clone(1) or git-init(1) will probe and set core.symlinks false if appropriate when the repository is created.

Você pode verificar o status da configuração executando:

git config core.editor