one-liner vs script

Ho notato molte domande, risposte e commenti che esprimono disprezzo per (e talvolta persino paura di) scrivere script invece di una riga. Quindi, vorrei sapere:

• Quando e perché dovrei scrivere una sceneggiatura autonoma piuttosto che un "one-liner"? O vice versa?

• Quali sono i casi d'uso, i pro ei contro di entrambi?

• Alcune lingue (ad es. Awk o perl) sono più adatte ad una riga rispetto ad altre (ad esempio python)? Se è così, perché?

• È solo una questione di preferenza personale o ci sono buone ragioni (cioè oggettive) per scrivere l'una o l'altra in circostanze particolari? Quali sono questi motivi?

definizioni

• one-liner: qualsiasi sequenza di comandi digitata o incollata direttamente in una riga di comando della shell . Oleodotti che spesso coinvolgono e / o l'uso di linguaggi come sed, awk, perl, e / o strumenti come grepo cuto sort.

  È l'esecuzione diretta sulla riga di comando che è la caratteristica che definisce - la lunghezza e la formattazione sono irrilevanti. Un "one-liner" può essere tutto su una riga, oppure può avere più righe (ad esempio sh for loop, o codice awk o sed incorporato, con avanzamenti di riga e rientro per migliorare la leggibilità).

• script: qualsiasi sequenza di comandi in qualsiasi lingua interpretata che viene salvata in un file e quindi eseguita. Uno script può essere scritto interamente in una lingua, oppure può essere un wrapper shell-script attorno a più "one-liners" usando altre lingue.

Ho la mia risposta (che posterò più avanti), ma voglio che diventi una domanda e risposta canonica sull'argomento, non solo la mia opinione personale.

Un'altra risposta basata sull'esperienza pratica.

Userei una riga se fosse il codice "butta via" che potrei scrivere direttamente al prompt. Ad esempio, potrei usare questo:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

Userei uno script se decidessi che vale la pena salvare il codice. A questo punto aggiungerei una descrizione nella parte superiore del file, probabilmente aggiungerei un po 'di controllo degli errori e magari lo verificherei anche in un repository di codice per il controllo delle versioni. Ad esempio, se decidessi che controllare il tempo di attività di un set di server fosse una funzione utile che avrei usato più e più volte, il one-liner sopra potrebbe essere esteso a questo:

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Generalizzando, si potrebbe dire

• One-liner

  • Codice semplice (ovvero solo "alcune" dichiarazioni), scritto per uno specifico scopo unico
  • Codice che può essere scritto rapidamente e facilmente ogni volta che è necessario
  • Codice usa e getta

• copione

  • Codice che (probabilmente) verrà utilizzato più di una volta o due volte
  • Codice complesso che richiede più di "alcune" istruzioni
  • Codice che dovrà essere gestito da altri
  • Codice che deve essere compreso dagli altri
  • Codice da eseguire incustodito (ad esempio, da cron)

Vedo un discreto numero di domande qui su unix.SE chiede un one-liner per svolgere un compito particolare. Usando i miei esempi sopra, penso che il secondo sia molto più comprensibile del primo, e quindi i lettori possono imparare di più da esso. Una soluzione può essere facilmente derivata dall'altra, quindi nell'interesse della leggibilità (per i futuri lettori) dovremmo probabilmente evitare di fornire il codice inserito in una riga per qualsiasi cosa diversa dalla più banale delle soluzioni.

Scrivi una sceneggiatura quando:

• è richiesto più codice
• apprezzi la leggibilità
• è necessario / utile aggiungere commenti, per mostrare cosa fa il codice
• devi passare i parametri
• si desidera eseguire lo script nel proprio ambiente (variabili, ecc.)
• probabilmente stai per riutilizzare / adattare il codice per scopi più complessi

Scrivi una riga quando:

• è necessaria solo una piccola quantità di codice
• si desidera accedere alle variabili definite nella shell corrente
• hai bisogno di una soluzione rapida e sporca

Quando una serie richiesta di comandi è piuttosto breve e / o produce un risultato che potrebbe essere utilizzabile come parte di una pipeline più grande o di un alias di comando, potrebbe essere un buon one-liner.

Fondamentalmente, penso che le linee guida di solito siano cose che un esperto amministratore di sistema ha familiarità con il problema e i comandi usati potrebbero scrivere sul posto, senza pensarci troppo.

Quando un one-liner diventa eccessivamente lungo o coinvolge più di semplici condizionali o loop, di solito è meglio scriverli come script multi-linea o funzione shell, per leggibilità. Inoltre, se si tratta di qualcosa che si scrive per essere utilizzato più e più volte, o qualcosa che verrà utilizzato (e possibilmente risoluzione di problemi) da altre persone, si dovrebbe essere disposti a trascorrere il tempo per scrivere la soluzione in un chiaro (er), commentato, modulo di script.

In Python, il rientro fa parte della sintassi, quindi non puoi letteralmente usare le funzionalità del linguaggio nella loro massima estensione se scrivi una riga.

Perl e awk one-liner riguardano spesso l'utilizzo del potere grezzo delle espressioni regolari. Ma alcuni chiamano le espressioni regolari un linguaggio di sola scrittura, non del tutto senza motivo. Scrivere uno script multilinea ti consente di scrivere nei commenti per descrivere cosa dovrebbe fare una particolare espressione regolare, il che sarà molto utile quando guarderai di nuovo lo script, dopo aver fatto altre cose per sei mesi tra.

Questa è intrinsecamente una domanda molto basata sull'opinione, in quanto implica la valutazione di quanta complessità sia accettabile e dei compromessi tra leggibilità e compattezza; tutte queste sono molte questioni di giudizio personale. Anche la scelta di una lingua può dipendere da questioni personali: se una determinata lingua sarebbe teoricamente ottimale per un particolare problema, ma non hai familiarità con esso e sai già come risolvere il problema con un'altra lingua, puoi scegliere il linguaggio familiare per portare a termine il lavoro rapidamente e con il minimo sforzo, sebbene la soluzione potrebbe essere tecnicamente alquanto inefficiente.

Il meglio è spesso nemico del abbastanza buono , e questo vale molto qui.

E se hai familiarità con Perl, potresti aver già sentito parlare di TMTOWTDI: c'è più di un modo per farlo.

Questa è un'opinione personale; prendilo con un granello di sale.

1. Se il comando si adatta a, diciamo, 80 caratteri, usa una riga. Le righe di comando lunghe sono difficili da lavorare. C'è anche il problema della ricorrenza, vedi # 2

2. Se è necessario eseguire i comandi più di una volta, utilizzare uno script. Altrimenti, usa un solo strato, a condizione che sia soddisfatta la condizione 1.

3. Questo è molto soggettivo, ma sì, vedo shell, Perl o awk come i miei strumenti di riferimento per i one-liner.
4. Vedi # 1, # 2, # 3.

Visualizzo e utilizzo un one-liner come strumento di sviluppo temporaneo per modificarlo ripetutamente fino a quando non fa quello che voglio, o capisco come funziona la sottigliezza di un comando secondario.

Quindi viene annotato (e annotato) in un file di testo sull'argomento su cui stavo indagando, oppure viene ripulito in uno script che viene inserito nel mio cestino personale PATH, possibilmente per ulteriore raffinamento, parametrizzazione e così via. In genere, una riga verrà suddivisa in più leggibile, anche se non vengono apportate altre modifiche o non uso mai più lo script.

Ho impostato la mia cronologia della shell su oltre 5000 linee, con una cronologia separata per terminale e per accesso su un telecomando e così via. Odio non riuscire a trovare in queste storie un comando a una riga che ho sviluppato qualche settimana fa e non pensavo di aver bisogno di nuovo, quindi la mia strategia.

A volte, è necessario che un intero gruppo di comandi faccia qualcosa, come configurare un po 'di hardware; alla fine li copio tutti fuori dalla storia, li pulisco minimamente e li aggiungo a uno script di shell RUNMEproprio come note su ciò che ho fatto, ma anche in modo che siano quasi pronti per essere riutilizzati da qualcun altro. (Questo è il motivo per cui trovo strumenti che forniscono solo una GUI per configurarli come un tale dolore.) Trovo che questo sia un incredibile guadagno in termini di efficienza, poiché così spesso qualcosa che ti aspetti di fare solo una volta, deve essere fatto altre 5 volte .. .

Vorrei che le persone del mio team scrivessero script per qualsiasi operazione che potrebbe essere necessaria per essere eseguita più di una volta (ad es. "Flussi di lavoro" o "pipeline") e per qualsiasi attività una tantum che deve essere documentata (in genere cose come "modificare alcune cose in alcuni set di dati per correggere dati forniti in modo errato" nel nostro caso). A parte questo, "one-liners" o script non contano troppo.

Non riuscire a documentare correttamente i flussi di lavoro (come script o equivalenti) rende più difficile introdurre nuovo personale in un progetto e rende anche più difficile la transizione delle persone da un progetto. Inoltre, rende difficile qualsiasi tipo di controllo e potrebbe essere impossibile rintracciare i bug.

Ciò è indipendente dal linguaggio utilizzato per la programmazione.

Altri luoghi di lavoro possono avere consuetudini / aspettative simili / diverse, forse anche scritte.

A casa, fai quello che vuoi.

Ad esempio, scrivo script non appena faccio qualcosa di non banale nella shell, come prima di inviare una risposta a una domanda U&L, o ogni volta che ho bisogno di testare i singoli componenti di un comando o set di comandi prima di eseguirlo "per vero".

Scrivo anche script per compiti ripetitivi che voglio fare sempre allo stesso modo ogni volta, anche se sono semplici, come

• aggiornare il mio sistema OpenBSD e tutti i pacchetti installati (questo si riduce a tre brevi comandi e ad alcuni altri per le pulizie, raccolti in un breve script), oppure
• il backup del mio sistema su un archivio fuori sede (essenzialmente un singolo comando, ma di nuovo con un bel po 'di pulizie e lo script mi ​​consente anche di fare differenze tra istantanee ecc. e deve funzionare in modo leggermente diverso su sistemi diversi, e Lo eseguo da un cron job), oppure
• recupero della posta (di nuovo, essenzialmente un singolo comando, ma voglio che si comporti in modo diverso quando viene chiamato come cron job e quando lo uso dalla riga di comando, e in alcuni casi non dovrebbe cercare di recuperare la posta e scrive un breve messaggio di registro in un file).

Uso le funzioni della shell (molto raramente alias) per comodità nelle shell interattive, ad esempio per aggiungere opzioni a determinati comandi di default ( -Fper ls) o per creare varianti specializzate di alcuni comandi ( pmanecco un mancomando che guarda solo i manuali POSIX, per esempio) .

Sembra che io abbia una visione di minoranza su questo.

Il termine "sceneggiatura" è intenzionalmente confuso, liberarsene. Questo è il software che stai scrivendo lì, anche se stai usando esclusivamente bashe awk.

All'interno di un team, preferisco scrivere software con processo di revisione del codice applicato da uno strumento (github / gitlab / gerrit). Questo dà il controllo della versione come bonus. Se si dispone di più sistemi, aggiungere strumenti di distribuzione continua. E alcune suite di test, se i sistemi target sono importanti. Non sono religioso su questi, ma soppesare benefici e costi.

Se hai un team di amministratori, il più semplice vim /root/bin/x.shè principalmente un disastro in termini di comunicazione legata al cambiamento, leggibilità del codice e distribuzione tra sistemi. Spesso un grave malfunzionamento costa più tempo / denaro rispetto al processo apparentemente "pesante".

In realtà preferisco le battute singole per tutto ciò che non merita questo processo "pesante". Possono essere riutilizzati rapidamente, con pochi tasti, se sai come usare la cronologia della shell in modo efficace; facilmente incollato tra sistemi non correlati (ad es. clienti diversi).

Differenza cruciale tra le righe singole (non visualizzate!) E il software rivisto ("script"): la responsabilità è totalmente a carico dell'utente quando si esegue una riga singola. Non puoi mai dire a te stesso "Ho appena trovato questo one-liner da qualche parte, l'ho eseguito senza capire, ciò che è seguito non è colpa mia" - sapevi che stai eseguendo bit-of-software non revisionato e non testato, quindi è colpa tua. Assicurati che sia abbastanza piccolo da poter prevedere i risultati - sii dannato se non lo fai.

Talvolta è necessario questo approccio semplicistico e l'impostazione della barra su circa una riga di testo funziona in pratica (vale a dire, il confine tra codice rivisto e non rivisto). Alcuni dei miei one-liner sembrano terribilmente lunghi, ma funzionano efficacemente per me. Fintanto che li grugnisco e non lo spingo su altri colleghi più giovani, va tutto bene. Nel momento in cui ho bisogno di condividerli, passo attraverso un processo di sviluppo software standard.

Devo dire che sono in qualche modo inorridito dalle implicazioni delle prime parti della domanda. I linguaggi di scripting Unix sono linguaggi di programmazione completi, e i linguaggi di programmazione sono linguaggi , il che significa che sono quasi infinitamente malleabili e flessibili come i linguaggi umani. E uno dei tratti distintivi di "malleabilità e flessibilità infinite" è che non c'è quasi mai "un modo giusto" di esprimere qualcosa - ci sono vari modi, e questa è una buona cosa! Quindi sì, certo , è una questione di preferenze personali, e non c'è nulla di sbagliato in questo. Chiunque dica che esiste un solo modo di fare qualcosa,

Una volta, la mia ~/binera piena di piccoli "utili" script che avevo scritto. Ma mi sono reso conto che la maggior parte di loro si è abituata il giorno in cui li ho scritti e mai più. Quindi più passa il tempo, più piccola bindiventa la mia directory.

Non credo ci sia nulla di sbagliato nello scrivere una sceneggiatura. Se immagini che tu o qualcun altro possa usarlo di nuovo, scrivete una sceneggiatura. Se si desidera "progettare correttamente" uno script sostenibile per il gusto di farlo, lo si deve assolutamente fare. (Anche se nessuno lo usa mai, scriverlo è una buona pratica.)

Motivi per cui non scrivo più script (e, immagino, preferisco "one-liners"):

• binil disordine di directory ha un costo. Non ci metto più le cose se non le appartengono davvero.
• I linguaggi di scripting che utilizzo sono le lingue che utilizzo ; Ormai sono davvero facile con loro. Riscrivere un one-liner ogni volta che ne ho bisogno non mi sembra di lavorare; Non ho il mandato di conservare, salvare e usare una sceneggiatura solo per alleviare l'onere di (ri) battitura. (Tra le altre cose, a un certo punto l'onere della riscrittura diventa inferiore all'onere della memoria di ricordare cos'è una sceneggiatura.)
• Un'altra ragione per cui riscrivere le cose non sembra un peso è la cronologia dei comandi. Ci sono molte righe che non ho incluso come script, anche se le uso tutti i giorni - ma non devo riscriverle; Li ricordo solo dalla storia. In questo modo sono una specie di script o pseudonimi di un uomo povero.

Credo che la maggior parte delle volte la richiesta di un "one-liner" sia in realtà una richiesta di un "morso sonoro", ovvero:

Nel contesto del giornalismo, un morso sonoro è caratterizzato da una breve frase o frase che cattura l'essenza di ciò che l'oratore stava cercando di dire e viene utilizzato per riassumere le informazioni ...

Le persone vogliono e richiedono il codice più breve che dimostra una soluzione alla domanda posta.

A volte, non c'è modo di ridurre un discorso a un "morso sonoro" e potrebbe essere impossibile ridurre una sceneggiatura a un breve "one-liner". In tali casi l'unica risposta possibile è una sceneggiatura.

E, in generale, un "morso sonoro" non è mai un buon sostituto dell'intero discorso. Quindi, un "one liner" è generalmente buono solo per trasmettere un'idea o per dare un esempio pratico di quell'idea. Quindi, dopo che l'idea è stata compresa, dovrebbe essere espansa (applicata) in uno script.

Quindi, scrivi un "one-liner" per trasmettere un'idea o un concetto.

Scrivi il tuo codice generale come script completi non a una riga.

Ti chiedi "paura e disprezzo degli script". Ciò è dovuto alla situazione Q + A, in cui spesso la risposta dice: ha bisogno di questo passaggio e di questo, ma posso anche metterlo in una riga (quindi puoi copiarlo incollandolo e usarlo come un lungo comando semplice).

A volte puoi indovinare solo se Q è meglio servito da una soluzione copia e incolla veloce o sporca, o se uno script "carino" è esattamente ciò che la Q deve capire.

Molti pro e contro qui sono veri, ma mancano ancora il punto. Direi anche che le definizioni in Q non sono utili.

I file della cronologia della shell sono "una linea", ma vengono comunque salvati. La funzione bash operate-and-get-next (C-o)ti consente persino di ripeterli semi-automaticamente.

Non vedo quasi la parola funzione menzionata. Questo è il modo di memorizzare sia "script" che "one liner". E con pochi tasti puoi passare da un formato all'altro. Un comando composto può spesso adattarsi a entrambi.

history -r fileè il modo di leggere una o più righe di comando (e commenti) da qualsiasi file, non solo dal file di cronologia predefinito. Ci vuole solo una minima organizzazione. Non dovresti fare affidamento su una grande dimensione del file di cronologia e sulla ricerca della cronologia per recuperare (alcune) versioni di una riga di comando.

Le funzioni dovrebbero essere definite in modo simile. Per cominciare, inserisci thisfunc() {...}un file "funzioni" nella tua home directory e procedi con il sorgente. Sì, questo è un po 'di spese generali, ma è la soluzione generale.

Se memorizzi ogni riga di comando e ogni variazione di script in un file separato, si tratta di uno spreco (teorico, ma oggettivo) di blocchi di filesystem.

Un liner non ha nulla di veloce e sporco da solo. È più la parte copia-incolla che è un po 'malvista, e come facciamo affidamento sulla cronologia dei comandi per salvarla per noi.

@sitaram: il tuo one liner ha davvero caratteristiche non on- line: linea shebang, newline, quattro chiamate di utilità - due delle quali sono "programmi". Penso che lo script perl originale fosse più bello e funzionasse più velocemente e non sprecasse alcun byte distribuendo su 60 righe. E perl ti consente anche di spremere un po '.

Per me, questo è esattamente il tipo di una fodera da evitare. Vorresti averlo (incollato) sulla tua riga di comando? No, e quindi, se lo memorizzi comunque in un file (indipendentemente dallo script o dalla funzione), potresti investire due o tre byte di nuova riga per renderlo bello.

10 minuti. più tardi: volevo solo verificare se posso dire "due programmi sed" o se si tratta di "due sostituzioni / chiamate sed". Ma la risposta di Sitaram è sparita. La mia risposta ha ancora senso, spero.