Eu tenho alguns scripts Python, que eu mantenho em um repositório; eles são arquivos de texto simples, mas se o bit executável estiver definido, a página do repositório on-line os servirá como downloads binários, não como páginas de texto simples. Assim, prefiro manter esses scripts não executáveis.
No entanto, eu também gostaria de usá-los também. Em princípio, eu poderia fazer:
sudo ln -s /path/to/wherever/I/have/put/myscript.py /usr/bin/
... e então, se o script fosse executável (e tivesse um shebang), eu poderia simplesmente chamar a linha de comando:
myscript.py [ARGS]
... é o que eu quero. Mas se eu tornar o script em si mesmo executável, então eu tenho o problema de download do repositório conforme indicado acima. E, contanto que o script seja não-executável, eu teria que chamá-lo com um python - e um which extras (caso contrário, python apenas procuraria no diretório atual pelo arquivo):
python 'which myscript.py' [ARGS]
... que ainda é um pouco de digitação, que eu não gosto. Além disso, desde que o arquivo seja não executável, nem mesmo a conclusão da tabulação funcionará para my[TAB] , mesmo se estiver em /usr/bin ; somente which funcionará.
Agora, grosseiramente - se eu pudesse ter permissões executáveis separadas no symlink, eu poderia esperar manter o original não-executável, e ainda ser capaz de rodar diretamente via apenas myscript.py na linha de comando. Não tenho certeza se há possibilidade para o Mac OSX - mas como Como o arquivo permissões se aplicam a links simbólicos? - Super User , o Linux definitivamente não oferece opções para isso: somente as permissões de arquivo originais são levadas em conta, a permissão do link simbólico não é.
Então eu estava pensando:
Um link simbólico não funcionará. Um link físico (quando possível) não funcionará porque ambos os arquivos terão as mesmas permissões. Mas eu faria o seguinte: em vez de um link, escreva um script de shell /usr/bin/myscript.py que executa o script em si:
#!/bin/sh
exec python /path/to/wherever/I/have/put/myscript.py "$@"
O "$@" transmite todos os parâmetros; Se o seu script não aceitar nenhum parâmetro, você poderá remover essa parte com segurança.
Um link simbólico não afeta as permissões do seu destino, é apenas uma maneira de armazenar um caminho que é seguido automaticamente pelo kernel. De fato, muitos sistemas ignoram completamente as permissões dos links simbólicos.
Um link físico não ajudaria, já que é uma maneira de ter o mesmo arquivo (mesmo conteúdo, mesmos metadados, incluindo permissões) em vários locais no sistema de arquivos.
Você pode usar bindfs para criar uma visão alternativa de um sistema de arquivos onde os arquivos têm uma permissão diferente.
bindfs --perms=a+x /path/to/wherever/I/have/put ~/bin/wherever
Isso tornaria todos os arquivos no modo de exibição alternativo executável. Provavelmente não é um método conveniente no seu caso, mas pode ser útil para outras pessoas com um problema semelhante.
A solução real para você seria consertar o sistema de repositório para que ele não se importe com as permissões, supondo que o sistema de download seja capaz de tornar os arquivos executáveis. Caso contrário, o que eu faria seria alterar a permissão dos arquivos após o download.
#!/bin/sh
actual-download-command
chmod +x /path/to/wherever/I/have/put/*.py
Tags linux filesystems symlink