execução direta de scripts python

Question

Tenho notado que, às vezes, os scripts python não estão sendo iniciados diretamente, isto é, /foo/bar.py , mas sim de um script de shell, que não faz nada além de /usr/bin/python -O /foo/bar.py $@

Um exemplo é wicd network manager. /usr/bin/wicd-gtk é um script de shell, que inicia o wicd-client.py :

$ cat /usr/bin/wicd-gtk

exec /usr/bin/python -O /usr/share/wicd/gtk/wicd-client.py $@

Qual é o objetivo dessa etapa extra?

Qual seria a diferença se eu iniciei /usr/share/wicd/gtk/wicd-client.py diretamente (desde que seja executável)?

    

Answer 1

Você não postou o script completo - o script faz outras coisas antes de executar wicd-client.py . Em primeiro lugar, garante que existe um determinado diretório e um determinado link simbólico:

# check_firstrun()
if [ ! -d "$HOME/.wicd" ]; then
    mkdir -p "$HOME/.wicd"
fi
# Make sure the user knows WHEREAREMYFILES ;-)
if [ -e "/var/lib/wicd/WHEREAREMYFILES" ] && [ ! -L "$HOME/.wicd/WHEREAREMYFILES" ]; then
    ln -s "/var/lib/wicd/WHEREAREMYFILES" "$HOME/.wicd/WHEREAREMYFILES"
fi

Em seguida, ele executa o Python com a opção -O , o que faz com que otimize o bytecode. Eu não sei o quão útil isso é.

O script de wrapper também força /usr/bin/python a ser usado, enquanto /usr/share/wicd/gtk/wicd-client.py começa com #!/usr/bin/env python , então pega o que for igual a python no caminho de pesquisa do comando. Na maioria dos sistemas, isso não fará diferença.

Observe que há um bug neste script: $@ deve ser "$@" . O script do wrapper falhará se algum argumento contiver espaços em branco ou caracteres curinga \[*? .

Você pode executar com segurança /usr/share/wicd/gtk/wicd-client.py manualmente, contanto que ~/.wicd exista. O pacote Debian não o torna executável; talvez outras distribuições façam.

    

Answer 2

(especulação pura segue.)

O que você tem é uma versão empacotada do Wicd, e os mantenedores do pacote testaram com a versão do Python empacotada pela distribuição. No entanto, /usr/share/wicd/gtk/wicd-client.py está escrito com este shebang:

#!/usr/bin/env python

Pode muito bem acontecer que /usr/bin/env escolha um python diferente de /usr/bin/python , especialmente se você fizer alguma programação em Python. O empacotador pode ter desejado evitar isso, apenas para diminuir as chances de problemas aparecerem devido ao Wicd ser executado sob uma versão diferente do Python, ou as bibliotecas sendo usadas de uma versão diferente.

E eles podem querer fazer outras tarefas preparatórias. wicd-gtk no Ubuntu 14.04 tem esse /usr/bin/wicd-gtk :

#!/bin/sh

# check_firstrun()
if [ ! -d "$HOME/.wicd" ]; then
    mkdir -p "$HOME/.wicd"
fi
# Make sure the user knows WHEREAREMYFILES ;-)
if [ -e "/var/lib/wicd/WHEREAREMYFILES" ] && [ ! -L "$HOME/.wicd/WHEREAREMYFILES" ]; then
    ln -s "/var/lib/wicd/WHEREAREMYFILES" "$HOME/.wicd/WHEREAREMYFILES"
fi

exec /usr/bin/python -O /usr/share/wicd/gtk/wicd-client.py $@