[Slackit.org] Traduzione capitolo 8 completata

[Roccatello Eduard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciao a tutti
- -- 
This sign is protected by EUCD.

Eduard Roccatello
Pcmprover.it hi-tech portal webmaster @ http://www.pcimprover.it
RoLUG staff @ http://rovigo.linux.it
PGP key and more in the headers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sqHrjUY2i0dNbbARAnVAAJ9uJrQkI/eqsiV44iCckn/Ei0RafwCfQ47j
3sD3kz/Ai3b9vZz5mOlYECM=
=W4jn
-----END PGP SIGNATURE-----

Capitolo 8. La shell

Tabella dei contenuti
Utenti
La linea di comando
Bourne Again Shell (bash)
Terminali virtuali
Sommario

In un ambiente grafico, l'interfaccia è fornita da un programma
che crea finestre, barre di scorrimento, menu, ecc. In un ambiente a
linea di comando, l'interfaccia utente è fornita da una "shell",
che interpreta comandi e generalmente rende usabili le cose.
Immediatamente dopo la procedura di accesso (login in, trattata in
questo capitolo), gli utenti vengono interfacciati ad una shell, la
quale permette loro di svolgere le più disparate attività.
Questo capitolo ha come scopo l'introduzione alla shell, e alla
più comune shell fra gli utenti linux -- la Bourne Again Shell
(bash). Per maggiori dettagli su qualsiasi cosa segnalata in questo
capitolo, controlla la man page della bash(1).

Utenti

Accedere al sistema

Hai avviato il computer e ti si presenta qualcosa di simile a questo:
	Welcome to Linux 2.2.14
	darkstar login:

Hmm.. Nessuno ti ha mai detto nulla riguardo ad un login. E cos'è darkstar? Non preoccuparti; probabilmente non hai accidentalmente creato un collegamento iperspaziale con la luna artificiale dell'Impero. (Mi dispiace ma il protocollo di collegamento iperspaziale non è ancora supportato dal kernel di Linux). No, darkstar è solo il nome di uno dei tuoi computer, e il suo nome viene mostrato di default. Se hai specificato un nome per il tuo computer durante l'installazione, dovresti vederlo al posto di darkstar.

Per fare il login... Se questa è la tua prima volta, vorrai accedere come root. Ti verrà richiesta una password; se l'hai impostata durante l'installazione, è quella che stiamo cercando. Se no, premi semplicemente invio. Ecco fatto-- Sei dentro!

Root: il superutente

Okay, chi o cosa è "root"? E cosa sta facendo con un account nel
tuo sistema?

Bene, nel mondo di Unix e sistemi operativi simili (come Linux), ci
sono utenti e poi ci sono altri utenti. Vedremo la cosa più in
dettaglio dopo, ma ora la cosa importante da sapere è che quel
"root" è l'utente al di sopra di tutti gli altri utenti; root
è onnipotente e conosce tutto, e nessuno disobbedisce a root. Non
è consentito. Root è ciò che noi chiamiamo
"superutente" e cosa più importante, root sei tu.

Forte, eh?

Se non sei sicuro: si, è molto forte. La cosa importante
è che a root è consentito rompere qualsiasi cosa egli
voglia. Potresti volere saltare avanti al Capitolo 12 e vedere come
aggiungere un utente; poi entrare come quell'utente e lavorare da
là. Il buonsenso tradizionale consiglia di diventare root solo
quanto è assolutamente necessario, in modo da minimizzare la
possibilità di rompere accidentalmente qualcosa.
Comunque, se decidi di essere root mentre sei loggato come
qualcun'altro, non c'è problema. Utilizza il comando su(1). Ti verrà chiesta la
password di root e poi sarai root finchè non fai exit o logout. Puoi diventare un altro
utente usando su, fornendo la
password dell'utente che vuoi diventare: su logan, ad esempio, ti
farebbe diventare me.

La linea di comando

Avviare i programmi

E' difficile diventare esperti senza avviare un programma; dovresti
essere in grado di puntellare qualcosa con il tuo computer o mantenere
aperta una porta, e fare un po' di fastidioso rumore quando è
accesso. E penso che possiamo tutti essere d'accordo che usare un
computer come ferma porta non è la cosa che ha portato al
personal computer la popolarità di cui gode.

Così, ricordi come qualsiasi cosa in Linux sia un file? Bene,
questo vale anche per i programmi. Ogni comando che lanci (che non
è interno alla shell) risiede in un file da qualche parte. Puoi
eseguire un programma semplicemente specificando il percorso completo
per lo stesso.

Ad esempio, ricordi il comando su
di cui abbiamo parlato? Bene, attualmente si trova nella directory /bin: /bin/su farà girare il
programma.

Ma allora perchè scrivendo solo su
funziona? Dopo tutto, non hai detto che si trova in /bin. Potrebbe anche
essere stato in /usr/local/share, giusto? Come posso saperlo? La
risposta a tutte queste bugie è nella variabile d'ambiente PATH; molte shell hanno PATH o qualcosa di molto simile a
PATH. Essa contiene fondalmentalmente una lista di directory dove
cercare il programma che stai cercando di avviare. Per cui quando avvii su, la tua shell controlla la sua
lista di directory, controllando ogni file eseguibile alla ricerca del
comando su che può
avviare; il primo che trova viene eseguito. Questo succede ogni volta
che avvi un programma senza specificare il percorso intero; se ti viene
restituito un errore Command not
found, vuol solo dire che il programma che hai tentato di
eseguire non è nel tuo PATH
(Naturalmente, questo sarebbe vero anche se il programma non
esistesse...). Discuteremo meglio le variabili d'ambiente nella sezione
chiamata Bourne Again Shell (bash).

Ricorda inoltre che "." è una scorciatoia per "la directory in
cui mi trovo", perciò se sei in /bin, ./su ha il significato di un percorso
completo esplicito.

Wildcard matching

Quasi ogni shell riconosce alcuni caratteri come sostituti o
abbreviazioni che significano "qualsiasi cosa va qui". Questi caratteri
vengono chiamati "wildcards"; i più comuni sono * e ?. Per
convenzione, ? solitamente significa qualsiasi carattere singolo. Ad
esempio, supponiamo di essere in una directory con tre file: ex1.txt,
ex2.txt, e ex3.txt. Vogliamo copiare tutti questi file (usando il
comando cp, spiegato nella sezione chiamata cp nel capitolo 10) in un
altra directory, chiamata /tmp. Bene, scrivere cp
ex1.txt ex2.txt ex3.txt /tmp per intero significa troppo lavoro. E'
molto più facile scrivere cp
ex?.txt /tmp; il ? verrà sostituito con i caratteri "1",
"2", e "3", e ovviamente con tutti i caratteri riconosciuti.

Cosa stai dicendo? C'è ancora troppo lavoro da fare? Hai
ragione. E' spaventoso; abbiamo leggi sul lavoro per proteggerci da
qualsiasi cosa. Fortunatamente, abbiamo anche *. Come già
menzionato, * eguaglia "ogni numero di caratteri", incluso lo 0.
Perciò se i tre file erano nella stessa directory, potremmo aver
dato semplicemente cp * /tmp e avremmo ottenuto quello che volevamo.
Supponi che ci siano un file chiamato example.txt
e uno chiamato hejaz.txt.
Vogliamo copiare example.txt
ma non hejaz.txt, cp example* /tmp
lo farà per noi.

cp example?.txt /tmp
vorrà, naturalmente, solo prendere i nostri tre file originali;
non ci sono caratteri in esempio.txt per ?, perciò sarà
lasciato in pace.

Redirezione dell'Input/Output e Piping

(Ecco qualcosa di forte.)
	$ ps > blargh
Sai cos'è? Sono io che eseguo ps
per vedere quali processi sono in esecuzione; ps è trattato nel
Capitolo 11. Quella comunque non è la parte interessante. La
parte interessante è >
blargh, che significa, grezzamente, "prendi l'output di
ps e scrivilo in un file chiamato blargh". Ma aspetta, ora diventa
ancora più forte.
	$ ps | less
Questo prende l'output di ps e
lo "incanala" (pipe) attraverso less, in modo da poterlo visualizzare a
mio piacimento
	$ ps > > blargh

Questo è il terzo redirector più usato; esso fa le stesse cose di ">", eccetto che "> >" aggiungerà l'output di ps al file blargh, se il file esiste. Se non esiste, come con ">", esso verrà creato. (">" sovrascrive il contenuto corrente di blargh.)

C'è anche un operatore "<", che significa "prendi il tuo input dal seguente", ma non è usato così spesso.

	$ fromdos < dosfile.txt > unixfile.txt
La redirezione diventa veramente divertente quando cominci a combinare
le cose:
	$ ps | tac > > blargh

Questo eseguirà ps, rovesciando le linee del suo output, e le aggiungerà al file blargh. Puoi aggiungere quante redirezioni che vuoi; basta fare attenzione ad interpretarle da sinistra a destra.

Vedi la man page di bash(1) per informazioni più dettagliate sulla redirezione.

Bourne Again Shell (bash)

Variabili d'ambiente

Un sistema Linux è una bestia complessa, e ci sono molte cose da seguire, una moltitudine di piccoli dettagli che entrano in ruolo durante le tue normali interazioni con i vari programmi (per alcuni dei quali potresti non aver bisogno di esserne consapevole). Nessuno vuole passare un mucchio di opzioni ad ogni programma da avviare, dicendo il tipo di terminale da usare, l'hostname del computer, come dovrebbe apparire il prompt...

Così come un meccanismo di copertina, gli utenti hanno quello che che viene comunemente chiamato ambiente (enviroment). L'ambiente definisce le condizioni nelle quali viene eseguito il programma, ed alcune di queste definizioni sono variabili; l'utente più alterarle e giocare con esse, come è di diritto in un sistema Linux. Molte shell hanno le variabili d'ambiente (altrimenti non sarebbero molto usabili). Diamo uno sguardo ai comandi che che bash fornisce per manipolare le sue variabili d'ambiente.

$ set
set da solo vi mostrerà tutte le variabili
d'ambiente attualmente definite, con i loro rispettivi valori. Come
molti comandi bash integrati,
esso può fare molte altre cose (con i parametri); lasceremo alla
man page della bash(1) il
compito di trattare questi altri argomenti. L'output tipico di set potrebbe essere il seguente:
	PATH=/usr/local/lib/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:
	/usr/openwin/bin:/usr/games:.:/usr/local/ssh2/bin:/usr/local/ssh1/bin:
	/usr/share/texmf/bin:/usr/local/sbin:/usr/sbin:/home/logan/bin
	PIPESTATUS=([0]="0")
	PPID=4978
	PS1='\h:\w\$ '
	PS2='> '
	PS4='+ '
	PWD=/home/logan
	QTDIR=/usr/local/lib/qt
	REMOTEHOST=ninja.tdn
	SHELL=/bin/bash
Prestate attenzione alla variabile PATH della quale abbiamo discusso
prima; posso far girare qualsiasi cosa in quelle directory richiamando
semplicemente il nome del file.
	$ unset VARIABLE
unset rimuoverà ogni variabile che gli
passate, annullando sia la variabile che il suo valore; bash si
dimenticherà che la variabile sia mai esistita (Non
preoccupatevi. A meno che non sia una cosa definita per ogni sessione
nei file di configurazione, essa riapparirà immediatamente
avviando un altra sessione).
	$ export VARIABLE=some_value
Ora, export è veramente
utile. Usandolo, darete alla variabile d'ambiente VARIABLE il valore
"some_value"; se la variabile non esiste, verrà creata. Se la
variabile ha già un valore verrà sostituito con il nostro
valore. Questo non va bene se stai aggiugiungende una directory al tuo
PATH. In questo caso vorrai usare una cosa simile a questa:
	$ export PATH=$PATH:/some/new/directory
Da notare l'utilizzo di $PATH qui: quando vuoi che bash interpreti una
variabile (scambiarla con il suo valore), metti un $ prima del nome
della variabile. Ad esempio, echo $PATH
mostrerà il contenuto di $PATH:
	$ echo $PATH
	/usr/local/lib/qt/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:
	/usr/openwin/bin:/usr/games:.:/usr/local/ssh2/bin:/usr/local/ssh1/bin:
	/usr/share/texmf/bin:/usr/local/sbin:/usr/sbin:/home/logan/bin

Completamento con il tasto TAB

(Qui arriva qualcosa di molto interessante.)

1. Una interfaccia a linea di comando significa un mucchio da scrivere.
2. Scrivere vuol dire lavorare.
3. A nessuno piace lavorare.

Da 3 e 2, possiamo determinare 4) A nessuno piace scrivere. Fortunatamente, bash ci salva da 5 (a nessuno piace un'interfaccia a linea di comando).

Come fa bash a fornire questa splendida caratteristica? In aggiunta alle espansioni dovute alle wildcard discusse prima, bash è caratterizzata dal "Tab completition", ovvero il completamente tramite il tasto Tab.

Tab completition lavora in questa maniera: Stai scrivendo il nome di un file. Forse è nel tuo PATH, forse lo stai scrivendo esplicitamente. Tutto quello che devi fare è scrivere abbastanza nome del file per identificarlo unicamente. Poi premi il tasto tab. bash si immaginerà cosa vuoi scrivere e finirà di farlo per te!

E' tempo per un esempio. /usr/src contiene 2 sottidirectory: usr/src/linux e /usr/src/sendmail. Voglio vedere cosa c'è in /usr/src/linux. Per fare ciò scrivo ls /usr/src/l, premo il tasto TAB, e bash mi restituisce ls /usr/src/linux.

Ora, supponiamo che ci siano due directory /usr/src/linux e /usr/src/linux-old; Se scrivo /usr/src/l e premo TAB, bash riempirà finche può e mi ritornerà /usr/src/linux. Posso fermarmi qui o posso premere ancora TAB, e bash mi mostrerà una lista di directory che assomigliano a quello che ho appena scritto.

D'ora in poi, meno battitura (e da ora, le persone possono apprezzare le CLI). Te l'avevo detto che era interessante.

Terminali Virtuali

Sei nel mezzo di un lavoro e decidi che di avere bisogno di fare qualcos'altro. Puoi tranquillamente smettere di fare quello che stavi facendo e scambiare i task ma questo è un sistema multiutente, giusto? E puoi entrare simultaneamente quante volte vuoi, giusto? Allora perchè dovremmo fare le cose una alla volta?

Non devi. Non possiamo avere tastiere multiple, mouse, e monitor per una sola macchina. Non vogliamo andare per tentativi e chiaramente l'hardware non è la soluzione. Lasciamo che software e Linux ci forniscano "terminali virtuali", chiamati anche "VTs".“VTs”.

Premendo Alt ed un tasto funzione, puoi scegliere i terminali virtuali; ad ogni tasto funzione corrisponde un terminale virtuale. Slackware prevede login su 6 terminali virtuali di default. Alt+F2 ti porterà sul secondo terminale virtuale, Alt+F3 al terzo, ecc.

Il resto dei tasti funzione sono riservati per le sessioni di X. Ogni sessione di X usa il suo terminale virtuale cominciando dal settimo (Alt+F7) e successivi. Quando sei in X, la combinazione di tasti Alt+tasto Funzione è sostituita da Ctrl+Alt+Funzione; perciò se sei in X e vuoi tornare alla console testuale senza uscire dalla tua sessione di X, puoi usare la combinazione Ctrl+Alt+(F1-F6). (con Alt+F7, tornerai ad X, supponendo di utilizzare la prima sessione di X).

Sommario

Questo capitolo ha discusso sugli utenti, sulla shell, sulla linea di
comando, e sui terminali virtuali. Dovresti sentirti a tuo agio
lavorando sulla linea di comando, avviando programmi, e usando pipes e
operatori di redirezione per combinare i comandi. Infine, dovresti
avere un idea sul potere dell'utente root e perchè usare sempre
root è una brutta cosa.

This chapter has been translated by Eduard <Master^Shadow> Roccatello
This is the italian translation of Slackware Book @ http://www.slackware.com/book/
Thanks to all Slackware Developers