Abbiamo visto rapidamente come elencare file e directory e come conoscerne e modificarne i permessi di accesso. Ma come si fa a creare dei file? E come si può modificarli ed eventualmente rimuoverli? Dato che la rimozione è l'operazione più semplice, partiamo da essa:
$ rm [nomefile]rimuove il corrispondente file. Il comando rm può essere usato anche per rimuovere directory e sottodirectory, usando l'opzione di ricorsività ed eventualmente quella di forzatura. Questo uso di rm viene lasciato come esercizio:
$ man rmpermette di capire come si fa; per inciso, nel mondo Linux si tende a dare aiuto a chi ne ha bisogno, ma non a chi per pigrizia non legge documentazione che sarebbe tranquillamente in grado di capire. In quest'ultimo caso, una risposta classica è ``RTFM'', che, a seconda del contesto, può significare ``Read That Fine Manual'', oppure ``Read The Fuckin' Manual''... Sulla distribuzione RedHat di default viene impostato un ``alias'' tale per cui vi viene chiesta conferma per la rimozione dei file. Però sappiate che questo non è vero per UNIX in generale, oltretutto non la trovo un buona scelta, infatti sul computer che uso ho definitivamente eliminato tale ``alias''. Anche su UNIX si possono trovare dei file manager grafici che sostituiscono la rimozione con lo spostamento in un cestino, ma in generale, a parte queste eccezioni, la rimozione è una vera rimozione e, a parte trucchetti da ``hacker'', un file rimosso non può essere recuperato. Infatti, la rimozione di un file non corrisponde solo all'eliminazione di un ``collegamento'': viene anche fisicamente ``spianata'' la corrispondente area di disco. Provate a cancellare una quantità significativa di spazio su disco e vi accorgerete che la rimozione comporta dei tempi superiori a quelli che servirebbero semplicemente a rimuovere un ``link'' e ha tempi paragonabili a quelli del salvataggio di un file di uguale dimensione. L'unico spiraglio: sulla base della sua strategia, il kernel può organizzare le operazioni da fare sull'hardware in modo tale che la scrittura corrispondente a una rimozione sia differita. In tal caso, se spegnete selvaggiamente in tempo, il file potrebbe ancora in buona parte esistere fisicamente sul disco, se vi mettete anche a smanettare in maniera opportuna sul file system con dei tool molto a basso livello... potreste riuscire a recuperarlo. Comunque, in termini pratici, un file rimosso è perso per sempre. Lavoro da tempo con UNIX e credo che questo offra più vantaggi che svantaggi; inoltre educa a considerare le rimozioni per quello che effettivamente sono e a non lasciare ``sporcizia'' in giro. Del resto, ritengo che una rimozione vera dei file sia anche opportuna in termini di sicurezza e riservatezza su un sistema multiutente.
Come visualizzare un file? Contrariamente a ciò che qualcuno pensa, non è necessario usare un editor per aprire un file. Anzi, se non lo si vuole modificare, è più opportuno fare a meno di usare un editor: non si rischia di modificarlo per errore. Un'altra precisazione: nel seguito si suppone che il file da visualizzare sia di tipo ascii; infatti, a parte casi specifici, non è di molto interesse visualizzare un file binario, specialmente se si usa un terminale in grado di mostrare solo caratteri ascii. Per visualizzare un file sul terminale su cui si sta usando la shell, basta lanciare il comando
$ cat [nomefile]Se il file è troppo lungo per essere interamente visualizzato nel terminale, si ha uno ``scroll'' che rende invisibile la parte iniziale. Si può ``risalire'' con SHIFT+PGUP per vedere un certo numero di righe scrollate; se si è in grafica, si può aumentare la dimensione (numero di righe e colonne) del terminale, ma questa soluzione non è ottimale e presenta dei limiti. Per questo scopo esistono degli ``impaginatori'' (PAGER) come more e less. more è più comune, lo si trova su qualunque UNIX, mentre less è piuttosto raro, anche se di solito su LINUX c'è. less si chiama così solo per fare il paio con more in maniera scherzosa; a parte questa nota di colore, è più comodo di more, dato che ad esempio permette di usare i cursori verso l'alto e verso il basso, mentre more usa combinazioni di tasti che ricordano un po' di più l'editor VI. In entrambi i casi, la visualizzazione viene terminata premendo la lettera ``q''. La sintassi di less è uguale a quella di more, banalmente,
$ more [nomefile]
A questo punto rimane da imparare a fare la cosa più importante: come si crea un file? Esiste un comando molto potente, di cui vi invito a leggere la pagina di manuale e di cui vi mostro l'uso più semplice:
$ touch [nomefile]crea un file di dimensione nulla, con la data attuale. Nel paragrafo successivo vedremo che un file può essere creato in altri modi, per esempio redirigendo su file lo stdout di un comando; inoltre, ad esempio, compilando un programma, si crea un file binario eseguibile; dei file possono essere prodotti indirettamente: ad esempio, l'esecuzione di alcuni comandi può provocare la produzione di file temporanei da parte del Sistema Operativo. Però, ovviamente, uno dei modi più semplici per creare e/o modificare un file consiste nell'uso di un editor con relativo salvataggio. L'editor ``di default'' di UNIX è il famoso/famigerato VI (VIsual editor), che può essere usato direttamente sul terminale di shell:
$ vi [nomefile]permette di aprire ``a pieno schermo'' un file sul terminale che si sta usando, oppure di iniziare la scrittura di un nuovo file. VI fu sviluppato all'Università di Berkeley, da programmatori, per programmatori. Sicuramente, oltre ad essere potentissimo e a permettere di compiere in maniera semplice operazioni complesse, non è un editor immediato, né ``amichevole''. Tuttavia, chiunque usa UNIX ne conosce almeno i comandi fondamentali, dato che è l'unico editor che sicuramente si può trovare su qualunque workstation UNIX. Riguardo all'amichevolezza, bisogna precisare che fu sviluppato quando i terminali non avevano i tasti speciali, non c'erano ancora i mouse, c'era solo la tastiera normale con la chiave CTRL. Se poi lo si confronta con il precedente ``standard'' UNIX, bisogna osservare che VI è un editor ``full screen'', mentre ED era un editor di linea (VI incorpora anche le caratteristiche di ED). Ci si potrebbe chiedere: va be', ma questa è storia... perché oggi dovrei usare VI se magari non sono in grado di apprezzarne la potenza? VI è un po' come la shell di UNIX: non lo si conosce mai del tutto, ma, se si presenta un'esigenza nuova, basta cercare per accorgersi che permette di fare di tutto, in maniera elegante, dimostrando una notevole potenza e il consolidato buon senso di chi lo ha sviluppato. Inoltre, poiché sfrutta solo i tasti di una tastiera ``normale'', funziona praticamente su qualsiasi terminale, anche se vi dovete collegare in remoto con mezzi improbabili, ed essendo anche molto compatto (in termini di dimensione del file eseguibile) risulta adatto ad essere inserito nei dischi di recupero, magari ``in versione ridotta''. Se non fate strane cose quando agite da root, difficilmente vi capiterà di dover riprendere per i capelli una workstation Linux danneggiata e apparentemente ``andata'', ma se smanettate con un po' di leggerezza o se lo fa un vostro amico, vi potrebbe capitare... sappiate che in quel caso, molto probabilmente, l'unico editor a vostra disposizione sarà il VI. In termini pratici, attualmente il supporto del mouse non è un problema. Poi, su Linux è inclusa una versione abbondantemente estesa di VI, il VIM (VI IMproved), che, oltre a comprendere una interfaccia grafica con tanto di menù per chi ne sente il bisogno, offre delle estensioni importanti grazie alle quali VIM non ha nulla da invidiare agli editor più moderni. Ad esempio: UNDO multilivello, possibilità di aprire più viste su più file con lo stesso editor, evidenziazione della sintassi per più di 100 linguaggi diversi, possibilità di usare i cursori anche in modalità inserimento, possibilità enormi di personalizzazione, ecc. ecc. VIM può essere usato in maniera del tutto analoga a VI:
$ vim [nomefile]mentre normalmente sulle distribuzioni di Linux il comando vi corrisponde a una versione ``ristretta'' del VI ``originale''. Le varie distribuzioni fanno scelte diverse riguardo all'organizzazione del o dei pacchetti riguardanti VI, che comunque non mi sembrano organizzati benissimo su nessuna di esse, RedHat compresa: su quest'ultima ho fatto diverse modifiche alla corrispondente configurazione, ora non le ricordo tutte esattamente e credo che vi annoierei. Riguardo alle ``istruzioni per l'uso'' di VI, rimando gli interessati ai testi riportati in bibliografia. Mi scuso per aver decantato così tanto questo editor, ma VI è quasi un simbolo di UNIX: per molti, ma non per tutti; manna per chi ci sa fare, dannazione per molti. Tornando sui nostri passi, un file può essere creato e/o modificato con un qualunque editor. Oltre a VIM, vi consiglio Nedit (un editor grafico basato sulle Motif, che spesso non fa parte delle distribuzioni di Linux) ed Emacs. Su Emacs evito di disquisire troppo, visto che è quasi materia di fede e che chi come me è patito di VI non lo vede molto di buon occhio. Però ritengo giusto precisare che è molto di più di un semplice editor: permette anche di fare compilazioni, debugging, posta elettronica, ecc., il tutto in un ambiente integrato. Spesso si obietta (e mi associo) che contravviene un po' alla logica di UNIX, secondo cui, normalmente, ogni programma serve a far bene una cosa ben precisa e l'utente mostra la sua eleganza e le sue capacità combinando in maniera intelligente i vari strumenti a sua disposizione. Evitando polemiche, ritengo giusto precisare che occupa molto spazio su disco (non meno di 20 Mbyte) e che richiede molte risorse, specialmente se si usa XEmacs, la sua versione pienamente grafica. Inoltre, non è sempre immediato per l'utente neofita. In definitiva, mi sembra che Nedit sia una soluzione migliore e rappresenti un ottimo compromesso.