execução direta de scripts python

Notei que algumas vezes scripts python não estão sendo iniciados diretamente, ou seja /foo/bar.py, mas a partir de um shell script, que nada mais faz do que/usr/bin/python -O /foo/bar.py $@

Um exemplo é wicdo gerenciador de rede. /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 desta etapa extra?

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

Você não publicou o script completo - o script faz outras coisas antes de executar wicd-client.py. Primeiro, ele garante a existência de 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 -Oopção, o que faz com que ele otimize o bytecode. Não sei o quanto isso é útil.

O script do wrapper também força /usr/bin/pythona ser usado, ao passo que /usr/share/wicd/gtk/wicd-client.pycomeça com #!/usr/bin/env python, portanto, ele pega o que ocorrer pythonprimeiro no caminho de busca do comando. Na maioria dos sistemas, isso não fará nenhuma diferença.

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

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

(Segue-se especulação pura.)

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

#!/usr/bin/env python

Pode muito bem ser o caso que /usr/bin/envpega um diferente pythondo que /usr/bin/python, especialmente se você fizer qualquer tipo de programação Python. O empacotador pode querer evitar isso, apenas para diminuir as chances de problemas surgirem devido ao Wicd ser executado sob uma versão diferente do Python ou às bibliotecas usadas para uma versão diferente.

E eles poderiam querer fazer outras tarefas preparatórias. wicd-gtkno Ubuntu 14.04 tem o seguinte /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 $@