Stile di programmazione portatile

Dipende dal tuo pubblico previsto.

Se si tratta di un'app generale, potrebbe essere necessario associarli a questi strumenti, assicurarsi che funzionino ancora con le modifiche e gli aggiornamenti di Windows e assicurarsi che non si scontrino con i Windows built-in. Git deve farlo su Windows, raggruppa molti degli strumenti mingw

Se l'app è rivolta agli utenti non tecnici, ciò potrebbe essere più semplice poiché puoi attaccare gli strumenti in una sottodirectory locale e non dovresti preoccuparti di questi in conflitto con altri strumenti cygwin / mingw / etc.

Dovresti anche essere al corrente degli avvisi di sicurezza, se un utente esegue la tua app e riceve un messaggio su wget (di cui non hanno mai sentito parlare) cercando di violare il firewall potrebbero diventare nervosi!

Se vuoi scrivere una piccola sceneggiatura, per l'amor di dio scrivi una piccola sceneggiatura. Se vuoi scrivere un programma (anche se parte di quel programma usa programmi esterni), scrivi un programma. Se hai una piattaforma di destinazione ben definita, sentiti libero di usare le sue capacità in entrambi i modi. E sì, reinventare la ruota è male in entrambi i casi (ma sembra che tu abbia una definizione eccessivamente librale di quel termine, vedi sotto).

Quel particolare file .py sta praticamente facendo la stessa cosa di un gruppo di chiamate wget e tar ? Scommetterei che l'inferno si bloccherà prima che il file venga usato su un server non unix? Quindi scrivilo come uno script di shell (o se la tua logica è abbastanza semplice, scrivi semplicemente uno script di shell!). Cose del genere sono abbastanza semplici da riscrivere nel caso improbabile che debbano essere rese davvero portabili; ma fino ad allora, YAGNI.

Le cose sono diverse per il codice della libreria e le applicazioni generiche. Se puoi farlo senza aggiungere una dipendenza a un programma esterno, fallo. Ogni volta che lo fai, aggiungi la portabilità e facilita l'implementazione (GNU coreutils potrebbe essere disponibile su Windows, ma chi lo impacchetterà per l'inclusione nella tua app o, peggio, dirà agli utenti di scaricare questi cinquanta programmi?). E ogni oncia di ciò è sacro, potrebbe salvare il giorno di qualcuno in futuro (potrebbe essere te stesso, qualcun altro che lavora al tuo progetto, o anche il proverbiale psicopatico violento che sa dove vivi). Incollare insieme moduli di libreria standard in poche righe è non reinvenzione ruota. Riscrivere l'intero modulo è reinventare le ruote. Ma anche quello può essere accettabile come un male necessario se la ruota che stai reinventando funziona solo in modo nativo su due piattaforme, funziona solo con Cygwin su un terzo e non funziona affatto sul quarto ... ma questo è un altro argomento, un argomento che è stato ampiamente trattato in passato e sarà discusso ancora di più in futuro.

When you target *nix do you glue tools together or you tend to implement all the functionality in your scripting language of choice?

Si noti che la maggior parte dei linguaggi di scripting è in grado di interagire con altri programmi, quindi quando li uso al posto di sh o bash, raramente si tratta di "implementare tutte le funzionalità".

Il punto decisionale che ho trovato è, quanto è necessario aritmetica o strutture di dati . Spesso uno script di shell va bene. Altre volte è meglio un programma perl o python.

In bash ci sono variabili di matrice, operazioni su stringhe e aritmetica di interi, ma qualsiasi uso non banale di questi tende ad essere scomodo e produce un codice brutto.

Un plus con la famiglia Bourne Shell, è il molto utile costrutto case-esac.