Unix è un affascinante sistema operativo. Originariamente concepito presso i Bell Labs alla fine del 1960, è stato sostenuto dalla frustrazione con il sistema operativo noto come” Multics ” (multiplexed information and computing service). Unix ha ormai più di 50 anni (!) e l’implementazione di Linux alimenta enormi fasce di Internet.
Quindi-perché Unix è così popolare?
Nella mia mente, il successo di Unix deriva dall’approccio filosofico allo sviluppo. La filosofia UNIX è documentata da Doug McIlroy nel Bell System Technical Journal in 1978:
1. Fai in modo che ogni programma faccia bene una cosa. Per fare un nuovo lavoro, costruisci di nuovo piuttosto che complicare i vecchi programmi aggiungendo nuove “funzionalità”.
2. Aspettatevi che l’output di ogni programma diventi l’input di un altro programma, ancora sconosciuto. Non ingombrare l’output con informazioni estranee. Evitare rigorosamente formati di input colonnari o binari. Non insistere sull’input interattivo.
3. Progettare e costruire software, anche sistemi operativi, da provare presto, idealmente in poche settimane. Non esitate a buttare via le parti goffi e ricostruirli.
4. Utilizzare strumenti di preferenza per aiutare non qualificati per alleggerire un compito di programmazione, anche se si deve deviare per costruire gli strumenti e si aspettano di buttare alcuni di loro fuori dopo aver finito di usarli.
Questo è stato più di 40 anni fa, e cattura SOLIDO (principio di responsabilità singola, aperto / chiuso), microservizi, pipeline funzionali, agile e lo spirito di DevOps!
Per maggiori dettagli sulla filosofia Unix, leggi questo libro (disponibile gratuitamente qui ma acquistane una copia per supportare l’autore!).
Diamo un’occhiata ad alcuni esempi della filosofia Unix in azione.
Fai in modo che ogni programma faccia bene una cosa. Per fare un nuovo lavoro, costruisci di nuovo piuttosto che complicare i vecchi programmi aggiungendo nuove “funzionalità”.
cat fa esattamente una cosa. Concatena i file e li visualizza sullo standard output. E ‘ tutto quello che fa. Non fa impaginazione. Non offre funzionalità di ricerca. Fa esattamente quello che dice sulla latta e non di più.
tr è simile. Fa “sostituzione testuale” leggendo dall’input, facendo traduzioni e scrivendo all’output.
tr -d aeiouAEIOU < file # Display file without vowels
tr eao 340 < file # Partially leet speak file
true e false sono forse i migliori esempi di fare bene una cosa. true non fa nulla, con successo! false non fa nulla.
false && echo Hi # does nothing
true && echi Hi # Prints Hi
Composizione
“Aspettatevi che l’output di ogni programma diventi l’input di un altro”
In Unix, la maggior parte delle operazioni ha la capacità di leggere e scrivere su standard output in un formato testuale ben compreso. Con alcuni comandi, come |, > e < possiamo alimentare l’output di un programma ad un altro. Diamo un’occhiata ad alcuni esempi:
In questo esempio, usiamo cat per produrre il contenuto di un file e alimentare l’output in wc che può contare il numero di righe in un file.
cat foo.txt | wc -l
In questo esempio, usiamo history per trovare i nostri comandi più usati combinandolo con cut, sort, uniq e head.
history | cut -f5 -d" " | sort -rn | uniq -c | sort -rn | head
xargs è l’ultimo swiss-army knife che consente di costruire i comandi da standard output. Usiamolo per cancellare tutto “.file ” tmp ” nella directory corrente dopo aver usato find per individuarli.
find -type f *.tmp | xargs rm
Tutto è un file
In UNIX tutto è un file (o più precisamente, tutto è un flusso di byte). Ciò significa che gli stessi API / comandi possono essere utilizzati per leggere un’unità CD-ROM, scrivere un socket di rete o scoprire informazioni sulla CPU.
Ad esempio, l’intero file system /proc su Linux non è realmente file: è una vista dinamica delle informazioni esposte come un gruppo di descrittori di file.
Alcuni esempi:
cat /proc/cpuinfo # Displays your CPU info exposed as a filefoo > /dev/null # Redirect output into a file called
# null (which discards everything)od -vAn -N1 -td1 < /dev/urandom # Display a random 1 byte number
# (via https://unix.stackexchange.com/a/268960
Automazione
molto prima che il “automatizzare-tutte-le-cose”, Unix era lì, errr, automatizzando tutte le cose
cron (di più qui) è stato l’automazione di tutte le cose che negli ultimi 40 anni. I lavori Cron sono script pianificati che possono essere eseguiti a orari fissi o intervalli fissi.
Ogni utente su un sistema Unix ha una serie di attività pianificate, visibili usando il comando crontab. Il file è in un formato molto semplice che fornisce la data e l’ora dello script che viene eseguito.
Il comando at è un’alternativa più amichevole, ecco un esempio di attivazione di un comando a 1145 il 31 gennaio (da qui).
echo "cc -o foo foo.c" | at 1145 jan 31
Puppet, Chef, CFEngine, Ansible — tutti questi strumenti DevOps e nati e cresciuti su sistemi basati su Unix.