Scrivo molti script PowerShell per l'organizzazione per cui lavoro attualmente. Più di recente ho collaborato alla stesura di uno strumento che, alla fine, avrà molte funzionalità (oltre a un singolo scopo), sarà configurabile e avrà sia una CLI che una GUI, tutte in PowerShell. Quindi quando uno script smette di essere uno script e quando puoi chiamarlo un'applicazione o un programma. Questo è solo un po 'negli occhi di chi guarda?
Uno "script" è un insieme di istruzioni che fanno qualcosa che l'utente potrebbe fare da sé, solo più velocemente e con meno possibilità di errore.
Sure, I could delete all my old log files manually, but the script Bob wrote does it just fine.
Una "applicazione" o "programma", al contrario, è un software automatico o interattivo di software che può essere pensato come fare le cose "da solo", piuttosto che il lavoro che l'utente farebbe da sé.
Help Desk asked me to run the "Log Import" program, so it send them the relevant data.
La differenza è in realtà di grado e di problema, e ci sono molti programmi che fanno cose che l'utente potrebbe fare da sé, e alcuni script che fanno cose che gli utenti non possono fare direttamente.
Se hai disegnato la linea da qualche parte in modo formale, disegna su "l'utente finale lo farà manualmente se questa cosa non fosse qui?"
Come altri hanno già detto, la risposta non è molto chiara. Per come la vedo io, uno script richiede poche o nessuna interazione da parte dell'utente una volta eseguito. Gli script sono meno flessibili in tal senso. Un'applicazione o un programma sarebbe più robusto, consentendo una maggiore interazione da parte dell'utente mentre è in esecuzione. Quello che stai scrivendo mi sembra più un programma che uno script, dal momento che sembra che ci sarà un bel po 'di interfaccia utente.
Dalla mia esperienza personale, uno script è qualcosa da fornire e alcuni parametri da eseguire. Sarebbe completamente o quasi completamente automatizzato. D'altra parte, se l'utente viene continuamente sollecitato o deve fornire input mentre viene eseguito il codice, questo è un po 'più robusto e meno automatizzato. Gli script riguardano più l'automazione rispetto a un programma più robusto con l'interazione dell'utente. Ad esempio, uno script può essere qualcosa che concatena una lista di file txt in un file txt. Un programma consentirebbe all'utente di scegliere continuamente i file da concatenare durante il runtime.
Non ci sono linee dure disegnate nella sabbia per questo. Spesso si riduce a chi sta facendo il lavoro e quanto sono comodi con i linguaggi non di scripting e quale livello di rigore hai sugli script vs applicazione. Le persone che scrivono script non sono generalmente considerati (generalmente) sviluppatori in piena regola che usano il controllo del codice sorgente, vari schemi di progettazione, test di unità, ecc. Gli script sono stati generalmente creati per evitare tutto quel rigore e fare un compito veloce. Gli sviluppatori spesso insisteranno sul fatto che gli script siano ancora nel controllo del codice sorgente, ma i posti in cui ho lavorato raramente si verificano perché generalmente non sono gli "sviluppatori" a scriverli e quindi il controllo è minimo attorno a loro. Sono le persone che vogliono qualcosa fatto e sanno abbastanza per essere pericoloso.
Leggi altre domande sui tag scripting