martedì 20 settembre 2011

Ubuntu: utilizzare gli Alias per creare comandi personalizzati

Ubuntu: utilizzare gli Alias per creare comandi personalizzati:

Diventare padroni del terminale Linux è sicuramente cosa buona e giusta che ci permetterà di essere anche padroni del sistema in modo completo, in qualsiasi situazione. Dovete sapere che è possibile impostare alcuni alias in modo da creare il proprio “comando personalizzato” per lanciare facilmente alcuni comandi di sistema difficili da ricordare o trascrivere. L’alias ​​è il modo più semplice ed utilizzato per personalizzare i comandi, dando loro pseudonimi (nickname). Questo è molto utile per poterli usare per ricordare i comandi difficili, lunghi o che non contengono stringhe semplici da memorizzare.


(...)
Continua la lettura di: Ubuntu: utilizzare gli Alias per creare comandi personalizzati




© Tanino Rulez per Chimera Revo, 2011. |
Permalink |
Nessun commento |
Aggiungi su
del.icio.us


Post tags: , , , , ,


Feed enhanced by Better Feed from Ozh

domenica 18 settembre 2011

Ubuntu: come ottenere un indicatore meteo Conky ispirato ad HTC

Ubuntu: come ottenere un indicatore meteo Conky ispirato ad HTC:


Ecco come configurare Conky in modo da renderlo un indicatore meteo con un interfaccia in perfetto stile HTC. Il widget meteo HTC è una delle prime cose che colpisce quando si ammira un prodotto della celebre casa Taiwanese e che ormai la identifica nel campo dei tablet e smartphone. Andiamo a vedere nel dettaglio come poterlo configurare e utilizzare sul nostro desktop in Ubuntu.


1) Se non abbiamo già intallato Conky sul nostro pc digitiamo da terminale:


sudo apt-get install conky


2) Sarà inoltre indispensabile l’estensione Meteo, potrete comodamente scaricare il pacchetto Conky Forecast.deb da qui:



3) Ora scarichiamo il tema Conky-HTC:



4) Estraiamo il file .zip , e premiamo Ctrl+H all’interno della cartella appena estratta per visualizzare i file nascosti. Copiamo i file .fonts, .images, .conkyForecast.config, .conkyrc, .conky_start and .vreme.template nella nostra cartella home.


5) Configuriamo Conky-HTC da terminale:



gedit ~/.conkyForecast.config


e andiamo a sostituire il valore: “LOCALE =pt_br” con “LOCALE =pt_en


purtroppo è disponibile solo in inglese ma, per fortuna, le previsioni meteo sono perfettamente funzionanti nel nostro territorio e facilmente personalizzabili. Salvate e chiudete il file.


Configurare il meteo


Rechiamoci sul sito di The Weather Channel e cerchiamo le previsioni per la nostra città (nel mio caso ho scelto Milano) e copiamo il codice alla fine dell’url:


http://www.weather.com/weather/today/ITXX0042


ora inseriamo il codice della nostra località nella configurazione di Conky-HTC da terminale:



gedit ~/.conkyrc


una volta aperto gedit andiamo nel menù Cerca > Sostituisci ed inseriamo nella casella Cerca: il valore “BRXX0232″ e nella casella Sostituisci con: il valore delle previsioni per la nostra città, nel mio caso il “ITXX0042″. Non chiudiamo ancora il file .conkyrc e ne approfittiamo per correggere un bug che porta Conky-HTC troppo vicino al nostro pannello superiore: sostituiamo il valore “gap_y 10” con “gap_y 40“, in questo modo l’indircatore sarà centrato nell’angolo in alto a destra del nostro desktop.


Ora possiamo salvare e chiudere.


Lanciare Conky


Non ci resta che lanciare Conky da terminale digitando:


conky


se volete aggiungere Conky alle vostre Applicazioni d’avvio basterà premere Aggiungi, Nome: “Conky-HTC”  e Comando: “/home/nomeutente/.conky_start.sh“.


Un po di fatica, ma per un vero smanettone configurare Conky è sempre divertente, ecco il risultato:



Sembra che ripaghi abbondantemente qualche minuto speso dietro al terminale e gedit.


via




© Alessandro L per Chimera Revo, 2011. |
Permalink |
Nessun commento |
Aggiungi su
del.icio.us


Post tags: , , , , , , ,


Feed enhanced by Better Feed from Ozh

mercoledì 24 agosto 2011

BleachBit 0.9.0 beta rilasciato! Installiamolo su Ubuntu

BleachBit 0.9.0 beta rilasciato! Installiamolo su Ubuntu:


Chi utilizza Windows conoscerà sicuramente Ccleaner, un software per la pulizia del proprio registro e non solo. Per i sistemi Linux esiste un’alternativa valida e che non potete non avere installato sul vostro sistema: BleachBit. BleachBit, lo “spazzino” del nostro sistema, annuncia pubblicamente la versione 0.9.0 beta che include miglioramenti, correzioni di bug e aggiornamenti di traduzione.


(...)
Continua la lettura di: BleachBit 0.9.0 beta rilasciato! Installiamolo su Ubuntu




© renato per Chimera Revo, 2011. |
Permalink |
Nessun commento |
Aggiungi su
del.icio.us


Post tags: , , , , ,


Feed enhanced by Better Feed from Ozh

giovedì 18 agosto 2011

Aggiornare un'immagine .iso con zsync in Windows usando cygwin

Volete aggiornare un'immagine CD con estensione .iso, ma utilizzate Windows e non potete utilizzare il potente programma zsync? Niente paura, adesso vi spiego come fare:

1) Innanzitutto scaricate Cygwin, che è un software che consente a un SO Windows di svolgere alcuni compiti in maniera esteticamente e funzionalmente simile ai sistemi UNIX.

2) Installate Cygwin lanciando il file setup.exe. Durante l'installazione vi chiederà di scegliere una sorgente di download. Scegliete Install from Internet e continuate.
Di default zsync dovrebbe installarsi, (ma a me non è successo sebbene fosse selezionato).


3) Terminata l'installazione, create una nuova cartella Download in C:/cygwin/home/ (se avete lasciato le impostazioni standard).

4) Copiate in questa cartella l'immagine .iso che volete aggiornare. Lanciate Cygwin e spostatevi nella cartella Download con il comando

cd Download

5) Adesso, non ci resta che aggiornare l'immagine con

zsync http://cdimage.ubuntu.com/daily-live/current/**********.zsync

immettendo il link esatto.

6) Se dovesse appunto apparire un comando che dice che zsync non è installato:

una volta scaricato il file di zsync .tar.bz2 da qui estraetelo direttamente per 2 volte fino ad ottenere una normale cartella. Copiate la cartella ottenuta in C:/cygwin/home//Download, lanciate Cygwin, spostatevi nella cartella suddetta e lanciate i seguenti comandi:

./configure
make
make install

dopo di che potete continuare con il punto 5.


giovedì 7 luglio 2011

Modificare un file PDF

Ho a che fare in continuazione con file PDF e loro modifica. Mi trovo benissimo nel compiere queste operazioni via terminale, anche perché mi sbrigo prima. Mi annoto anche qui queste operazioni e le condivido con voi.

Ovviamente esistono alternative che fanno uso di strumenti grafici, come PDF Mod, PDF Chain, PDF Shuffler, PDF Split and Merge (pdfsam).

I pacchetti usati in questo post sono: ghostscript, pdftk, poppler-utils, che vanno installati se non li avete già.

Manipolazione del PDF

Unire più PDF in uno solo

pdftk input_A.pdf input_B.pdf input_C.pdf cat output output.pdf

Unire tutti i PDF di una directory in uno solo

pdftk *.pdf cat output output.pdf

Dividere un unico file PDF in tanti file PDF quante sono le sue pagine

pdftk input.pdf burst

Estrarre da PDF alcune pagine

pdftk input.pdf cat 10-20 output output.pdf

Estrarre da PDF alcune pagine non consecutive

Col seguente comando estraiamo le pagine 3, dalla 10 alla 20, 25, 28, 32, dalla 45 alla fine:

pdftk input.pdf cat 3 10-20 25 28 32 45-end output output.pdf

Ruotare un PDF di 90° a destra (clockwise)

Col seguente comando ruotiamo tutte le pagine (dalla prima alla fine) verso Est:

pdftk input.pdf cat 1-endE output output.pdf

Ruotare un PDF di 90° a sinistra (counter-clockwise)

pdftk input.pdf cat 1-endW output output.pdf

Ruotare un PDF di 180°

pdftk input.pdf cat 1-endS output output.pdf

Estrarre immagini dal PDF

È consigliabile crearsi prima una directory (ad esempio pdf_images) dove far confluire tutte le immagini e poi dare:

pdfimages input.pdf pdf_images/

Convertire un PS in PDF

ps2pdf -dPDFSETTINGS=/screen input.ps output.pdf

dove screen può essere:

screen (72 dpi)
ebook (150 dpi)
printer (300 dpi)
prepress (300 dpi)

Convertire un PDF in PS

pdf2ps input.pdf output.ps

Ridurre le dimensioni di un PDF

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf

Modificare i metadati di un PDF

Estraiamo prima le informazioni esistenti in un file di testo:

pdftk input.pdf dump_data output info.txt

Modifichiamo le informazioni e reimportiamole in un nuovo PDF con:

pdftk input.pdf update_info info.txt output output.pdf

Un esempio di elenco di metadati:

InfoKey: Title InfoValue: Titolo del PDF InfoKey: Subject InfoValue: Soggetto del PDF InfoKey: Keywords InfoValue: Parole, Chiave, Del, PDF InfoKey: Author InfoValue: Autore del PDF

PDF e immagini

Convertire un PDF in PNG

convert -density 300 input.pdf output.png

Tutte le pagine saranno convertite in immagine. I file immagine risultanti avranno questo nome:

output-0.jpg --> Pagina 1 output-1.jpg --> Pagina 2 ecc.

La stessa conversione può essere effettuata con pdftoppm, un componente di poppler-utils.

Convertire un PDF in PNG specificando le dimensioni di uscita

convert -scale 940 input.pdf output.png

Convertire un PDF in PNG specificando la risoluzione di uscita

convert -density 300 input.pdf output.png

Estrarre da PDF una pagina e convertirla in PNG

convert input.pdf[0] output.png
0 sta per pagina 1, 1 per pagina 2 e così via.
Anche in questo comando si possono usare le opzioni -scale e -density.

Estrarre da un PDF più pagine non consecutive e convertirle in PNG

convert -density 300 -scale 940 input.pdf[0,2,6,11,16,21,26,33,38] output.png

Convertire un PDF in un PDF immagine (rasterizzare il PDF)

convert -density 300 input.pdf output.pdf

Convertire più PNG in PDF (A4 verticale)

convert -adjoin -page 210x297 *.png output.pdf

Convertire più PNG in PDF (A4 orizzontale)

convert -adjoin -page 297x210 *.png output.pdf

mercoledì 29 giugno 2011

Join my alliance!!!


Manifesto dell’Alleanza Ribelle

La nostra casa – la Terra – è in pericolo. VW si oppone a due leggi europee fondamentali per la salvaguardia del clima: innalzamento degli obiettivi di riduzione delle emissioni e maggiore efficienza delle automobili. Due leggi vitali se non vogliamo fare la fine del pianeta Alderaan (distrutto dalla Morte Nera…). Ma non tutto è perduto. Percepiamo del Bene in VW.

Tutti noi, membri dell’Alleanza Ribelle, chiediamo a VW di abbandonare il Lato Oscuro della Forza e di dare al nostro pianeta una possibilità di salvezza.

1

Sostenere un forte abbattimento delle emissioni di CO2.

Nonostante la sua immagine “green”, Volkswagen spende ogni anno milioni di Euro per finanziare le lobby che impediscono all’Europa di innalzare gli obiettivi di riduzione delle emissioni di gas serra, dal 20% al 30%, entro il 2020. Aziende virtuose come Google, Ikea, Sony, Unilever, Philips e Barilla sostengono già l’innalzamento degli obiettivi sul clima. Volkswagen non può permettersi di rimanere indietro.

2

Promuovere la produzione di auto più efficienti.

Le auto con consumi di carburante bassi fanno risparmiare ed emettono meno CO2. Da sempre Volkswagen si oppone al miglioramento degli standard di efficienza, ma interrompere la nostra dipendenza dal petrolio è una necessità. Come prima azienda automobilistica in Europa, VW incide moltissimo sulle emissioni e ha una grande responsabilità ambientale. Per questo deve cambiare e sostenere standard ambiziosi, d’ora in avanti.

3

Più fatti, meno parole.

Volkswagen sostiene di voler essere “il produttore d’auto più ‘eco-friendly’ al mondo”, ma i suoi modelli più efficienti, nel 2010, hanno rappresentato soltanto il 6% delle sue vendite. Volkswagen ha la tecnologia per fare molto meglio di così: deve impegnarsi per produrre solo veicoli “oil free” entro il 2040. (Per maggiori informazioni leggi l’intero rapporto)



JOIN MY ALLIANCE!!!

domenica 19 giugno 2011

Linux Bash Scripting for Dummies: Struttura Scripts

Bentornato al nostro consueto appuntamento settimanale sul bash scripting. Quello che oggi ti propongo è una prima infarinatura sugli scripts.

Come già ci siamo detti l’obiettivo di questa serie di guide è imparare a scrivere delle procedure (scripts) in maniera chiara e funzionale; e per farlo dobbiamo iniziare a capire come questi devono essere strutturati.

Introduzione

Qualsiasi sviluppatore, sia che esso programmi in php che in ruby che in qualsiasi altro linguaggio, ti dirà che ci sono sostanzialmente due modi di scrivere il software che si possono descrivere con

  1. Scrittura fatta a cazzo di cane
  2. Scrittura fatta bene

Entrambi i metodi funzionano, dando per scontato che i software sono scritti senza errori, vale a dire che due software uguali ma scritti con i due metodi sopra illustrati funzioneranno entrambi, ma – c’è un ma – solo il software scritto col secondo metodo potrà essere definito un buon software, perchè?

Perchè chi usa il primo metodo tende a scrivere il software nella maniera più veloce, senza inserire i cosiddetti “commenti” all’interno del codice – che sono importantissimi – inserendo le funzioni base e senza pensare se una determinata azione può essere eseguita in altro modo, magari con meno linee di codice.

Il secondo metodo invece è migliore perchè, anche se necessità di più tempo per scrivere lo stesso software (ma non sempre eh), fa scrivere del codice più funzionale, vale a dire che se ad esempio il codice è ben commentato e ben indentato1 sarà più facile rileggerlo magari dopo mesi che è stato scritto, soprattutto se a rileggerlo è una persona diversa da chi l’ha scritto inizialmente; inoltre, se il codice è anche ben ottimizzato ne risulterà un software più snello che richiede meno tempo e meno risorse per essere eseguito. Ne consegue che più lo script è complesso e più è importante, nonchè necessario, un processo di progettazione precedente alla stesura del codice; la progettazione è lo step che in molti casi determina la qualità del software finale, pensa che a volte il processo di progettazione può richiedere parecchio tempo, molto più di quello necessario per la stesura del codice finale.

Ecco perchè è cosi importante saper ottimizare il codice che si scrive.

La struttura degli scripts bash

Dunque uno script bash possiamo dividerlo in tre macro-aree che chiameremo ispirandoci alla terminologia che si usa per l’html delle pagine web: header, corpo e – se necessario – il footer. Se non hai mai scritto in bash sappi che tra poco inizierai a leggere dei temini dei quali, quasi sicuramente, non ne saprai il significato. Però non devi spaventarti perchè ovviamente il tutto ti sarà chiarito mano mano che leggerai l’articolo, e qualora cosi non fosse sei invitato a chiedere tutto quello che vuoi nei commenti.

Header

Nello scripting unix l’header, o apertura, degli scripts include come primissima cosa l’interprete che il sistema deve usare per leggere ed eseguire il codice che seguirà. A seguire troveremo – opzionalmente – le istruzioni che servono ad includere eventuali file di configurazione, librerie, altri script, ecc… e poi tutte le variabili che sono necessarie per l’esecuzione dello script.

L’interprete deve essere inserito come prima riga dello script e nel caso di bash si usa:

#!/bin/bash

Se hai visto qualche volta del codice bash noterai una cosa, questa riga inizia con un cancelletto che viene usato per i commenti, però questo codice viene eseguito perchè altrimenti come farebbe la shell a capire quale interprete usare? In realtà una differenza c’è, perchè i commenti iniziano con un asterisco e basta, noi invece stiamo usando la combinazione di asterisco+punto esclamativo che in bash si chiama shebang.

Come fa la shell a capire che quella è una shebang (chiamata anche hashbang) e non un commento? Perchè per essere una hashbang valida, questa combinazione deve apparire per prima, vale a dire che i primi due caratteri del paragrafo che inizia, devono essere appunto “#!” se invece viene piazzato all’interno di un paragrafo in qualsiasi altra posizione allora la shell sa che quello è un commento.

#!/bin/bash <- questa è una hashbang. echo "#!/bin/bash" <- questo è un messaggio da stampare a schermo. # Using #!/bin/bash as interpreter <- questo invece è un commento.

NB. Se dopo aver scritto uno script e lo lanciamo con “./script.sh” otteniamo un “command not found” significa che molto probabilmente non è stato inserito l’interprete in testa al file.

Dopo l’interprete a volte potremmo trovare una sezione dedicata al cosiddetto sourcing delle dipendenze. Per esempio noi potremmo scrivere uno script che per funzionare ha bisogno di un file di configurazione che a sua volta può contenere delle variabili, altri comandi da eseguire, ecc…

Il sourcing può anche essere fatto al di fuori degli script con l’apposito comando ‘source’, per esempio, potremmo voler definire un alias di comandi all’interno del nostro file .bashrc2 per poter aggiornare tutti i pacchetti installati nella nostra linux box.

Normalmente lanceremmo “sudo pacman -Sy” se stessimo usando Archlinux oppure “sudo apt-get safe-upgrade -y” per debian/ubuntu, ma per fare ancora prima possiamo inserire dentro il nostro .bashrc l’alias

pkgup='pacman -Sy'

oppure

pkgup='apt-get safe-upgrade -y'

di modo da dover solo scrivere “sudo pkgup” per ottenere la stessa azione. Bene, una volta fatta questa modifica per poter usare quell’alias dovremmo lanciare una nuova shell o riloggarci al sistema nel caso stessimo usando un server che non ha quindi un desktop manager come gnome o kde; oppure possiamo renderla definitiva da subitousando il comando source.

:~$ source ~/.bashrc

Nel caso degli script non dobbiamo usare il comando source, basta solo inserire il path al file che ci interessa preceduto da un punto ed uno spazio.

# Includo il file di configurazione . /path/to/configuration/file

NB. Un file che viene incluso in testa allo script non per forza necessita di essere reso eseguibile (chmod +x).

La prossima cosa che incontriamo nell’header degli scripts sono le definizioni delle variabili, queste sono molto importanti in quanto ci consentono di poter definire a monte pezzi di codice che poi verranno riutilizzati dentro il corpo dello script, per farlo si richiamano appunto queste variabili anteponendo il simbolo del dollaro al nome della variabile, la variabile VAR quindi verrà richiamata con $VAR.

E’ molto importante fare l’uso delle variabili perchè cosi evitiamo di dover ripetere gli stessi pezzi di codice più volte all’interno dello script (ottimizzazione, ricordi?), è facile intuire quindi che le variabili vengono concepite per lo più durante la fase di progettazione.

Per capire come si usano le variabili andiamo a vedere un pezzo di script che creai un paio di anni fa, quando dovetti mettere in piedi una procedura di backup dei server basata su rsync.

#!/bin/bash   #Definizione delle variabili   PATH_SCRIPT="/usr/local/scripts"   RSYNC_CMD=`which rsync`   INCLUDE_FILE="$PATH_SCRIPT/path.conf"   SERVER_LIST="$PATH_SCRIPT/servers.inc"   PATH_BCK="/mnt/backups"

Possiamo notare da subito due cose, la prima è che inizio ad usare sin da subito le variabili che definisco, $PATH_SCRIPT infatti l’ho usata anche per definire il path dell’include file3 ed il path della lista dei server da backuppare; la seconda cosa riguarda il comando rsync:

Avrai notato che tutte le variabili sono definite dentro i doppi apici tranne RSYNC_CMD che è definita dentro degli apici inversi, questo perchè apici, doppi apici, ed apici inversi in bash hanno determinate funzioni.

Con i doppi apici diciamo alla bash che quello che delimitano deve essere stampato valorizzando eventuali variabili contenute all’interno, analogamente con il singolo apice diciamo a bash che quello che è contenuto all’interno deve essere stampato cosi com’è senza tenere conto di variabili, per esempio ponendo di avere definito una variabile VAR=”3″:

echo "il valore di VAR è $VAR"

ci darà in output “il valore di VAR è 3″ mentre

echo 'il valore di var è $VAR'

ci darà in output “il valore di VAR è $VAR”.

Mentre il comportamento dell’apice inverso (che in linux otteniamo con la combinazione altgr+’ mentre in windows tenendo premuto ALT e digitando sul tastierino numerico 096) è differente, dichiarando una variabile con questo carattere diciamo a bash che il valore della stessa deve essere uguale all’output del comando inserito tra apici inversi.

Nel caso dello script di cui sopra quindi RSYNC_CMD avrà come valore l’output del comando “which rsync” che nella maggior parte dei casi sarà uguale a “/bin/rsync”.

Ma perchè ho definito il comando di rsync con una variabile al posto di scrivere “/bin/rsync” ogni volta che mi serviva? Per una questione di usabilità, quando si fa uno script infatti si deve pensare che questo può essere lanciato su qualsiasi architettura, e non tutte le distribuzioni hanno il comando rsync sotto /bin, potrebbe essere lanciato ad esempio su un server sul quale rsync è stato installato da sorgenti dentro il path /usr/local/bin, conviene sempre quindi definire i comandi usati nello script con delle variabili passandogli `which nomecomando` come valore, eccezion fatta per i comandi standard ovviamente, come ad esempio “ls” che troveremo sempre dentro “/bin/ls”.

  1. L’indentazione è l’inserimento di una serie di spazi vuoti tramite il tasto TAB ad inizio di ogni paragrafo, serve per aiutare la lettura
  2. .bashrc è il file che viene letto ad ogni nostro login, od ogni qualvolta lanciamo una shell, esso contiene tutte le nostre preferenze per l’uso della shell, come variabili d’ambiente, alias di comandi, personalizzazioni del prompt della shell e tanto altro.
  3. rsync consente di passare un file come parametro all’interno del quale ci sono dei percorsi specifici da includere o da escludere dai backup

da http://www.ilportalinux.it/linux-bash-scripting-for-dummies-struttura-scripts/

Linux Bash Scripting for dummies: Bash vs Shell (parte 2)

Parentesi ed altri metacaratteri


Parentesi tonde

Un altro metacarattere che possiamo usare nella shell sono le parentesi, sia tonde che graffe, entrambe hanno un ruolo diverso vediamo quale:

Questo tipo di parentesi sono usate per richiamare la cosiddetta “subshell”, una subshell è a tutti gli effetti una shell vera e propria che viene creata al momento stesso in cui il comando inserito tra parentesi tonde viene evocato, per poi essere terminata non appena tale comando completa la sua esecuzione.

Lanciare un comando da solo, od una serie di comandi, dentro queste parentesi – di per se – non ha molta utilità, il vero beneficio lo abbiamo quando lanciamo un comando qualsiasi e un comando tra parentesi tonde, questo permette di parallelizzare l’esecuzione dei due comandi attraverso appunto la subshell.

Bisogna fare attenzione quando usiamo le subshells e le variabili, queste infatti rimangono visibili solo all’interno del codice inserito nella subshell; se per esempio lanciassimo

1 
echo $var (export var="questa è la mia variabile")

non otterremmo nulla a video perché la variabile $var è valida solo per gli eventuali comandi lanciati dentro la subshell, di tutto quello che succede dentro le parentesi, la “parent shell” – la shell dalla quale viene richiamata la subshell – non lo vede.

Negli script questo può risultare utile perché come ho appena detto l’uso delle subshell consente di parallelizzare i processi, potremmo quindi progettare lo script in due parti logiche una delle quali (la subshell) prepara eventuali files di configurazione o quanto altro potesse servire durante l’esecuzione dello script, impiegando idealmente metà del tempo.

Pipe

Che si legge “paip” ed è quel metacarattere identificato con “|”. Con esso possiamo lanciare un comando redirigendo l’output come input di un secondo comando, è più difficile a dirsi che a farsi.

Per esempio, abbiamo appena installato postfix su una macchina e vogliamo vedere se è configurato correttamente provando l’invio di una mail; tramite i comandi “echo” e “mail” possiamo fare tutto questo:

1 
echo "Questa è una mail di test"|mail -s "Mail di test" morfeus@ilportalinux.it

con echo stampiamo a video quello che sarà poi il corpo della mail, però inserendo la pipe a fine comando lasciamo che questa stampa venga intercettata dal comando mail (che accetta in input appunto, il corpo della mail da mandare) che confeziona un bel messaggio con subject “Mail di test” e la spedisce al mio account.

Questo è un uso molto semplice della pipe, negli script personalmente faccio un largo uso di pipe per il parsing e l’editing dei file, facendone stampare il contenuto (o anche solo la parte che mi interessa) e mandandola in pipe ad altri programmi come sed od awk per costruire un altro file nella maniera che mi serve.

Parentesi graffe

Questo tipo di parentesi rappresentano un blocco che deve essere espanso ricorsivamente, per esempio, col comando:

1 
:~$ echo p{app,ap,al}a

avremo in output

pappa papa pala

od ancora, normalmente per creare la copia di backup di un file usiamo il comando “cp” in questo modo:

1 
:~$ cp miofile.conf miofile.conf.bck

ecco adesso che sappiamo usare le parentesi graffe la prossima volta daremo:

1 
:~$ cp miofile.conf{,.bck}

ottenendo lo stesso risultato, ed ancora, dopo aver editato il file in più riprese non ci ricordiamo più cos’è che abbiamo cambiato, normalmente useremmo:

1 
vimdiff miofile.conf miofile.conf.bck

ma adesso che siamo pro ci risparmiamo le dita e digitiamo:

1 
vimdiff miofile.conf{,.bck}

et voilà… (avete notato la virgola? fate attenzione a non dimenticarvela quando usate questa sintassi).

Per questa settimana è tutto, ci sono chiaramente una miriade di altri operatori nella bash, elencarli tutti è impossibile, ma io ti ho dato lo spunto; adesso prova a leggerti qualche script semplice e segnati quello che non capisci, se vuoi puoi chiedere nei commenti qui sotto :)


da http://www.ilportalinux.it/linux-bash-scripting-for-dummies-bash-vs-shell/2/