Significato effettivo di "shell = True" nel sottoprocesso

Chiamo diversi processi con il subprocessmodulo. Tuttavia, ho una domanda.

Nei seguenti codici:

callProcess = subprocess.Popen(['ls', '-l'], shell=True)

e

callProcess = subprocess.Popen(['ls', '-l']) # without shell

Entrambi funzionano. Dopo aver letto i documenti, sono arrivato a saperloshell=True significa eseguire il codice attraverso la shell. Ciò significa che in assenza, il processo viene avviato direttamente.

Quindi cosa dovrei preferire per il mio caso: ho bisogno di eseguire un processo e ottenere il suo output. Che vantaggio ho nel chiamarlo all'interno della shell o al di fuori di esso.

Il vantaggio di non chiamare tramite la shell è che non si sta invocando un "programma misterioso". Su POSIX, la variabile di ambiente SHELLcontrolla quale file binario viene richiamato come "shell". Su Windows, non esiste alcun discendente bourne shell, solo cmd.exe.

Quindi invocare la shell invoca un programma a scelta dell'utente ed è dipendente dalla piattaforma. In generale, evitare le invocazioni tramite la shell.

Il richiamo tramite la shell consente di espandere le variabili di ambiente e i file glob secondo il normale meccanismo della shell. Sui sistemi POSIX, la shell espande i globs dei file in un elenco di file. Su Windows, un file glob (ad esempio "*. *") Non viene espanso dalla shell, comunque (ma le variabili di ambiente su una riga di comando vengono espanse da cmd.exe).

Se pensate di volere espansioni di variabili d'ambiente e file globs, cercate gli ILSattacchi del 1992 sui servizi di rete che eseguivano invocazioni di sottoprogrammi tramite la shell. Gli esempi includono le varie sendmailbackdoor che coinvolgono ILS.

In sintesi, utilizzare shell=False.

>>> import subprocess
>>> subprocess.call('echo $HOME')
Traceback (most recent call last):
...
OSError: [Errno 2] No such file or directory
>>>
>>> subprocess.call('echo $HOME', shell=True)
/user/khong
0

L'impostazione dell'argomento shell su un valore vero fa sì che il sottoprocesso generi un processo shell intermedio e gli dica di eseguire il comando. In altre parole, l'uso di una shell intermedia significa che le variabili, i modelli glob e altre funzioni speciali della shell nella stringa di comando vengono elaborati prima dell'esecuzione del comando. Qui, nell'esempio, $ HOME è stato elaborato prima del comando echo. In realtà, questo è il caso del comando con espansione della shell mentre il comando ls -l è considerato un semplice comando.

fonte: modulo sottoprocesso

Un esempio in cui le cose potrebbero andare storte con Shell = True è mostrato qui

>>> from subprocess import call
>>> filename = input("What file would you like to display?\n")
What file would you like to display?
non_existent; rm -rf / # THIS WILL DELETE EVERYTHING IN ROOT PARTITION!!!
>>> call("cat " + filename, shell=True) # Uh-oh. This will end badly...

Controlla il documento qui: subprocess.call ()

L'esecuzione di programmi tramite la shell significa che tutto l'input dell'utente passato al programma viene interpretato in base alla sintassi e alle regole semantiche della shell invocata. Nella migliore delle ipotesi, ciò causa solo inconvenienti all'utente, poiché l'utente deve rispettare queste regole. Ad esempio, i percorsi contenenti caratteri shell speciali come virgolette o spazi vuoti devono essere sottoposti a escape. Nel peggiore dei casi, provoca perdite di sicurezza, poiché l'utente può eseguire programmi arbitrari.

shell=Truea volte è utile utilizzare specifiche funzionalità della shell come la suddivisione delle parole o l'espansione dei parametri. Tuttavia, se è richiesta tale funzionalità, utilizzare altri moduli (ad es. os.path.expandvars()Per l'espansione dei parametri oshlex per la suddivisione delle parole). Ciò significa più lavoro, ma evita altri problemi.

In breve: evitare shell=Truecon ogni mezzo.

Le altre risposte qui spiegano adeguatamente le avvertenze di sicurezza che sono anche menzionate nella subprocessdocumentazione. Ma oltre a ciò, l'overhead di avviare una shell per avviare il programma che si desidera eseguire è spesso inutile e decisamente sciocco per le situazioni in cui non si utilizza effettivamente nessuna delle funzionalità della shell. Inoltre, l'ulteriore complessità nascosta dovrebbe spaventarti, soprattutto se non hai molta familiarità con la shell o i servizi che fornisce.

Laddove le interazioni con la shell non sono banali, ora è necessario che il lettore e il manutentore dello script Python (che può essere o meno il tuo sé futuro) per comprendere sia lo script Python sia lo script shell. Ricorda il motto di Python "esplicito è meglio che implicito";anche quando il codice Python sarà in qualche modo più complesso dello script di shell equivalente (e spesso molto conciso), potresti essere meglio rimuovere la shell e sostituire la funzionalità con costrutti Python nativi. Ridurre al minimo il lavoro svolto in un processo esterno e mantenere il controllo all'interno del proprio codice per quanto possibile è spesso una buona idea semplicemente perché migliora la visibilità e riduce i rischi di effetti collaterali - desiderati o indesiderati.

Espansione jolly, interpolazione variabile e reindirizzamento sono tutti semplici da sostituire con costrutti Python nativi. Una complessa pipeline di shell in cui parti o tutte non possono essere ragionevolmente riscritte in Python sarebbe l'unica situazione in cui forse potresti prendere in considerazione l'uso della shell. Dovresti comunque assicurarti di comprendere le prestazioni e le implicazioni sulla sicurezza.

Nel caso banale, per evitare shell=True, è sufficiente sostituire

subprocess.Popen("command -with -options 'like this' and\\ an\\ argument", shell=True)

con

subprocess.Popen(['command', '-with','-options', 'like this', 'and an argument'])

Si noti come il primo argomento sia un elenco di stringhe a cui passare execvp()e come non sia necessario (o utile o corretto) quotare stringhe e metacaratteri di shell con escape di backslash. Forse vedi anche Quando racchiudere le virgolette attorno a una variabile shell?

Per inciso, molto spesso vuoi evitare Popense uno dei wrapper più semplici nel subprocesspacchetto fa quello che vuoi. Se hai un Python abbastanza recente, probabilmente dovresti usarlo subprocess.run.

• Con check=Trueesso fallirà se il comando che hai eseguito non è riuscito.
• Con stdout=subprocess.PIPEesso acquisirà l'output del comando.
• Un po 'oscuramente, con universal_newlines=Trueesso decodificherà l'output in una stringa Unicode corretta (è solo bytesnella codifica del sistema altrimenti, su Python 3).

In caso contrario, per molte attività, si desidera check_outputottenere l'output da un comando, verificando che abbia avuto esito positivo o check_callse non è presente alcun output da raccogliere.

Chiuderò con una citazione di David Korn: "È più facile scrivere una shell portatile che uno script di shell portatile". Anche subprocess.run('echo "$HOME"', shell=True)non è portabile su Windows.