<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-03-01 9:38 GMT+00:00 Nicola Larosa <span dir="ltr"><<a href="mailto:nico@teknico.net" target="_blank">nico@teknico.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">enrico franchi wrote:<br>
> Io sinceramente per lanciare 4 programmi in stecca scriverei 4 righe<br>
> di bash.<br>
<br>
Il riduzionismo degli shell script scritti "tanto sono quattro righe" è<br>
pernicioso.<br></blockquote><div><br></div><div>Anche volere fare tutto in un dato linguaggio perche' e' "migliore" della shell e' pernicioso.</div><div>Con questa logica ho visto aggeggi fatti in Java che funzionano male quando sarebbero *veramente* bastate quattro righe di bash. Poi certo, in Python e' un po' meglio.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Non sono mai quattro righe: sappiamo bene che ogni frammento di codice ha<br>
la tendenza ad allungarsi, col tempo.<br></blockquote><div><br></div><div>Si, boh... in generale e' cosi'. Quando sara' il momento li riscrivero' in Python se e quando e' fattibile.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
La sintassi imbarazzante degli shell script disincentiva dallo scrivere<br>
codice robusto, che controlla i processi lanciati e ne gestisce i codici<br>
di ritorno.<br></blockquote><div><br></div><div>Vero. Ora... sinceramente, bash avra' sintassi imbarazzante per varie cose. Pero' anche tutto il visual noise che subprocess genera quando viene usato al posto di uno shell script (ovvero, non per un caso tipico di "subprocess", ma proprio per fare il mestiere della shell)  non e' che sia bello.</div><div><br></div><div>Poi ci sono un sacco di discorsi accessori sui bachi che usare subprocess "blindly" ti introduce. Allora, abbiamo per esempio tar che quando hai un -z/-j sotto il cofano tira su una pipe, ma Python non ne sa nulla e a seconda di quello che fai hai grosso modo solo una linea di errore nello standard error. E si, si mette a posto con due calci a prefork_exec... probabilmente quando ti capita una volta poi te lo ricordi. Il problema non si limita a tar, e' generale. In generale, il fatto che Python debba farsi un po' i fatti suoi con i signal handlers (per permettere un'esperienza piu' Pythonica a chi ci scrive applicazioni) tende ad essere un problema quando invece lo si usa come "glorified shell". <a href="http://bugs.python.org/issue1652">http://bugs.python.org/issue1652</a></div><div><br></div><div>Oppure il fatto che quando si usa subprocess.PIPE come output e un processo ti genera piu' di 64K di dati ti si inchioda Python. Solo per nominare i primi due che mi passano per la testa.</div><div><br></div><div>Entrambe le cose possono essere aggiustate dall'utente; ma si complica il codice, diventa piu' brutto e soprattutto non e' per un accidenti intuitivo. Richiede conoscenze sull'implementazione interna di subprocess oppure dettagli non completamente diffusi fra gli sviluppatori medi su concetti di base Unix e sul comportamento leggermente non standard che Python ha in proposito. Ovvero, dando in mano subprocess a scatola chiusa, si hanno un po' di bachi tutti li da scoprire. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Disincentiva anche dallo scrivere test: avete mai visto shell script<br>
corredati di test, anche quelli molto lunghi? E purtroppo ce ne sono<br>
ancora tanti, di questi ultimi.<br></blockquote><div><br></div><div>Se e' per questo ho anche visto fin troppi programmi "top level" senza test. Va bene se le funzioni che chiamano sono testate.</div><div>Scusa, ma io non credo che lo sviluppatore che non scrive i test per un semplice shell script magicamente li scriverebbe se quelle quattro righe di bash diventano 10 righe di Python. </div><div><br></div><div>Aggiungo poi che di fatto sono anche test particolarmente pelosi da scrivere in ogni caso. Il problema e' acchiappare quanto va mockato e quanto no; entrambi gli approcci possono portare a test fragili, troppo specifici e inutili. Poi spesso e volentieri bisognerebbe anche che il processo interno supportasse di essere mockato *da fuori* per fare cose sensate. Ovvero il problema di fare testing di questo tipo di cose e' particolarmente incasinato di suo e lo lascerei temporaneamente fuori. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
L'assenza di documentazione e commenti nella totalità degli script in<br>
circolazione è poi ben al di là dell'imbarazzante.<br></blockquote><div><br></div><div>E allo stesso modo la stessa cosa si puo' dire per l'equivalente fatto con altre tecnologie.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Abbiamo uno strumento molto migliore per scrivere script, anche corti,<br>
anche di sistema: usiamolo.<br></blockquote><div><br></div><div>Anche qui si pone un problema... e' *davvero* uno strumento "di sistema"? Per me non lo e'. </div><div>E' qualcosa che posso installare, certo. Probabilmente quando l'applicazione principale e' Python non mi costa troppo avere Python gia' pronto in fase di bootstrap. Ma quando non lo e'? Non voglio dichiarare Python come dipendenza per ogni maledetto ambiente che creo.</div><div><br></div><div>E ci sono ancora altri casi... chesso'... fabric. Fabric funziona bene, ma di non mi risolve il problema di avere sugli host un env configurato a modo (a meno di non averlo *pre* configurato). Viceversa gli equivalenti costruiti su ssh mitigano il problema perche' tipicamente si basano su un ambiente molto piu' semplice e standardizzato.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
E chi trovasse il codice basato su subprocess ancora troppo prolisso può<br>
usare quel gioiello della libreria "sh" <<a href="http://amoffat.github.io/sh/" target="_blank">http://amoffat.github.io/sh/</a>>.<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Prima del mio arrivo avemmo parecchi problemi con suddetta libreria. Se ripesco qualcuno dei "vecchi" chiedo meglio le specifiche.</div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>