Risposta.

L'interazione con programmi esterni è una caratteristica critica di Perl, ereditata sin dalla creazione del linguaggio nel 1987 per compiti di amministrazione di sistema e automazione di routine shell. Perl fornisce diversi modi per eseguire un comando esterno: l'operatore system, le virgolette inverse (``) o qx//, la funzione open con pipe, e wrapper modulari come IPC::Open3.

Il problema principale nell'eseguire processi esterni è ottenere correttamente l'output (stdout e stderr), gestire errori di esecuzione, la sicurezza dei parametri (per evitare iniezioni), e la differenza tra esecuzione sincrona e asincrona.

La soluzione consiste nella scelta del modo corretto per un compito specifico. Per comandi semplici si usano system o virgolette inverse, per casi più complessi si usano i moduli IPC::*:

Esempio di codice (lettura dell'output del comando e gestione degli errori):

my $command = 'ls -l /tmp';
my $output = qx{$command};
if ($? == -1) {
    die "Errore di esecuzione: $!";
} elsif ($? & 127) {
    warn sprintf "Il comando è terminato con segnale %d", ($? & 127);
} else {
    print "Output: $output";
}

Caratteristiche principali:

È possibile interagire simultaneamente con stdin, stdout, stderr tramite open e IPC::Open3.
Non tutti i metodi garantiscono il ritorno di errori, o consentono di inserire variabili in modo sicuro nel comando.
Per scenari asincroni è necessario studiare moduli come IPC::Run, Proc::Background e controllare il PID del processo.

Domande insidiose.

Qual è la differenza tra system ed exec in Perl?

Risposta: system esegue un comando in un processo esterno e restituisce il controllo a Perl dopo il completamento, mentre exec sostituisce completamente il processo corrente di Perl con il programma eseguito, il codice Perl successivo non verrà eseguito.

Esempio:

system('echo Hello');
exec('ls', '-l'); # Tutto, il programma Perl è sostituito da ls, Perl non funziona più

È sicuro passare variabili utente a comandi shell?

Risposta: Solo utilizzando un elenco di argomenti (non stringhe) ed evitando l'interpolazione nella shell. Altrimenti, è possibile un'iniezione di comandi.

# Sicuro:
system("ls", "-l", $user_supplied_dir);
# Pericoloso:
system("ls -l $user_supplied_dir");

Come posso ottenere sia stdout che stderr da un comando esterno?

Risposta: Un modo affidabile è utilizzare IPC::Open3 o reindirizzare stderr in stdout a livello di shell:

my $out = qx{ls /notexists 2>&1};

o tramite IPC::Open3 (un modo più universale e fine).

Errori comuni e anti-pattern

Passare variabili non elaborate in stringhe shell (iniezioni).
Aspettarsi un valore di ritorno da system (restituisce lo stato, non l'output).
Mescolare stdout e stderr senza controllo esplicito.

Esempio dalla vita reale

Caso negativo

L'amministratore passa tramite system("rm -rf $dir") un valore fornito dall'utente.

Pro:

Realizzazione semplice e rapida.

Contro:

Possibile iniezione critica (ad esempio, in $dir è arrivato "; rm -rf /;") — intero sistema cancellato.

Caso positivo

Si utilizza system('rm', '-rf', $dir), $dir viene convalidato, è stato implementato il logging.