Cygwin User's Guide | NEXT chapters | ||
Cygwin è un ambiente Linux-like per Windows. E' costituito da una DLL ( Guida rapida all'installazione per coloro che hanno dimestichezza con Windows Se siete nuovi al mondo UNIX, potreste trovare qualche difficoltà a comprendere, agli inizi. Questa guida non vuole essere una guida a Unix, così vi raccomandiamo di utilizzare le tante risorse disponibili in Internet per avvicinarvi a UNIX ( cercate "UNIX basics" o "UNIX tutorial" ).
Per una installazione base di Cygwin, lanciate il file setup.exe e cliccate
Gli sviluppatori Windows troveranno una serie di tool per la creazione di eseguibili console o GUI che potranno contare sulle API Microsoft Win32. Per scrivere DLL Windows potete utilizzare l'utility dlltool. Il compilatore windres è anch'esso presente. Guida rapida all'installazione per coloro che hanno dimestichezza con UNIX Se siete un utilizzatore di Unix a cui manca un ambiente potente a linea di comando, sarete contenti di Cygwin. Occore sottolineare che alcuni trucchetti utilizzati hanno come conseguenza che Cygwin si comporti in modo differente dalla maggior parte dei sistemi operativi UNIX-like; queste differenze sono descritte con maggiori dettagli nella sezione chiamata “Using Cygwin effectively with Windows”.
Ogni volta che desiderate aggiornare o installare un pacchetto Cygwin, utilizzate la versione grafica di setup.exe. Questo programma deve essere eseguito manualmente, ogni volta che si desidera verificare l'esistenza di aggiornamenti, poichè Cygwin non include, attualmente, un meccanismo per la verifica automatica. Di default, setup.exe installa solo una lista minima di pacchetti: guardatevi intorno e scegliete le vostre utility preferite dalla schermata di selezione dei pacchetti. Potete anche cercare specifici tool all'interno del sito Cygwin: Setup Package Search. Per maggiori informazioni sulle singole opzioni di setup.exe, andate alla sezione chiamata “Internet Setup”.
Un'altra possibilità è installare tutto cliccando il campo
Gli sviluppatori Unix troveranno una serie di utility che già utilizzano normalmente, inclusa una shell Unix. I tool per il compilatore sono compilatori standard GNU che la maggior parte di voi avrà già utilizzato sotto Unix, semplicemente trasferiti su piattaforma Windows. I programmatori che desiderano portare software Unix su Windows NT o 9x troveranno che le librerie Cygwin forniscono metodi semplici per trasferire molti pacchetti Unix su piattaforma Windows, apportando solo minimi cambiamenti al sorgente. I tool di Cygwin sono software free? Sì. Parte di essi sono software GNU ( gcc, gas, ld, etc. ), parte sono coperti dalla licenza standard X11, parte di essi sono di pubblico dominio, alcuni sono stati scritti da Red Hat e messi sotto la licenza GNU General Public License ( GPL ). Nessuno di essi è shareware. Non avete da pagare nessuno per utilizzarli, ma dovete leggere la sezione copyright delle FAQ per informazioni aggiuntive su come la licenza GNU GPL può influire sull'utilizzo di questi tool. Se intendete portare un'applicazione proprietaria utilizzando le librerie Cygwin, dovrete conoscere la licenza per l'uso proprietario. Per maggiori informazioni andate alla pagina http://www.redhat.com/services/custom/cygwin/. I clienti di Win32 GNUPro nativo sono liberi di sottoporre report sui bug e avere informazioni attraverso i normali canali. Tutte le altre richieste devono essere inviate alla
mailing list del progetto: Breve storia del progetto Cygwin Cygwin fu sviluppata a partire dal 1995 alla Cygnus Solutions ( oggi parte di Red Hat Software ). Per prima cosa furono migliorati i tool di sviluppo ( gcc, gdb, gas, etc. ) così da poter generare e interpretare i file object nativi di Win32. Il successivo passo fu di portare i tool a Win NT/9x. Avremmo potuto fare questo riscrivendo larghe porzioni di codice sorgente per poter lavorare in un contesto API di Win32. Ma questo avrebbe significato spendere molto tempo per ciascun tool. Invece, decidemmo un differente approccio, scrivendo una libreria condivisa ( Cygwin DLL ) che aggiungesse le necessarie funzionalità UNIX-like mancanti alle API Win32 ( fork, spawn, signals, select, sockets, etc. ). Chiamiamo questa nuova interfaccia API Cygwin. Una volta scritta, diventava possibile scrivere tool Win32 utilizzando cross-compiler UNIX, collegandoli a questa libreria. A questo punto, perseguimmo il risultato di produrre tool nativi in grado di ricostruire se stessi sotto Windows 9x e NT ( ciò che spesso viene definito self-hosting ). Dal momento in cui nessuno dei due sistemi operativi venivano rilasciati con i tool standard di Unix ( fileutils, textutils, bash, etc... ) dovemmo creare gli equivalenti GNU lavorando sulle API Cygwin. Molti di questi tool erano stati costruiti solo nativi, così dovemmo modificare la loro configurazione affinchè fossero compatibili con la cross-compilation. Oltre ai cambiamenti di configurazione, a livello di sorgente i cambiamenti da apportare furono davvero pochi. Grazie a bash ed ai tool di sviluppo ed ai tool utente, Windows 9x e NT sembravano, dal punto di vista del meccanismo di configurazione GNU, molto simili a Unix. Il self-hosting fu raggiunto nell'ottobre 1996. L'intera serie di tool Cygwin era ora disponibile come una installazione monolitica. Nell'aprile 2000, il progetto annunciava una nuova Release che offriva il programma nativo Win32 setup.exe, per installare ed aggiornare ciascun pacchetto separatamente. Sino ad allora, la DLL Cygwin e setup.exe avevano visto sviluppi continui. Introduzione Quando un file binario collegato alla libreria viene eseguito, la DLL Cygwin è caricata nel segmento di testo dell'applicazione. Visto che stiamo cercando di emulare il kernel UNIX che deve poter accedere a tutti i processi aperti, la prima DLL Cygwin da eseguire crea un'area di memoria condivisa alla quale tutti gli altri processi, istanze separate della DLL, potranno accedere. Questo per tenere traccia dei descrittori di file aperti e per assistere fork e exec, tra le altre cose. Oltre all'area di memoria condivisa, ogni processo avrà anche una struttura dedicata che conterrà informazioni quali: ID del processo, mask dei segnali, ed altre informazioni proprie dei processi. La DLL è implementata utilizzando API Win32, che le permette di essere eseguita su qualsiasi host Win32. Poichè i processi vengono eseguiti all'interno del sottosistema Win32, possono accedere sia alle chiamate UNIX compatibili fornite da Cygwin, sia a qualsiasi chiamata API Win32. Questo lascia al programmatore una completa flessibilità nel definire la struttura dei suoi programmi in termini di API utilizzate. Per esempio, potrà scrivere una graphical user interface ( GUI ) specifica per Win32 utilizzando le chiamate API Win32 al top di un back-end che utilizza Cygwin. Supporto per Windows NT e 9x Mentre Windows 95 e Windows 98 sono abbastanza simili da permetterci di ignorare le differenze esistenti tra l'uno e l'altro durante l'implementazione di Cygwin, Windows NT è un sistema operativo estremamente diverso. Per questa ragione, quando la DLL viene caricata, la libreria identifica il sistema operativo attivo.
In alcuni casi, API Win32 è differente solo per motivi storici. In questi casi, la stessa funzionalità è disponibile sia sotto Windows 9x, sia sotto Windows NT, ma il metodo utilizzato per accedere alla funzionalità è differente.
Un esempio banale: nella nostra implementazione di uname ( un comando UNIX che stampa informazioni sulla macchina e sul sistema operativo ) la libreria esamina la struttura di Permessi e sicurezza Windows NT include un sofisticato modello di sicurezza basato sulle Access Control Lists (ACLs). Cygwin, di default, mappa proprietà e permessi dei file secondo il vecchio standard UNIX. Cygwin versione 1.1 introduce il supporto per ACL, in accordo alle chiamate di sistema utilizzate nelle più recenti versioni di Solaris. Questa implementazione viene utilizzata quando Con Windows NT, gli utenti Amministratore possono eseguire Sotto Windows 9x, la situazione è considerevolmente diversa. Visto che non viene offerto alcun modello di sicurezza, Cygwin simula la proprietà del file attribuendo la proprietà di tutti i file ad un utente di default e ad un ID di gruppo. Come per NT, i permessi dei file possono ancora essere determinati esaminando il loro Accesso ai file Cygwin supporta sia la sintassi Win32 che la sintassi POSIX-style per il percorso dei file, utilizzando sia i forward slash ( Il layout di questa visione POSIX del file system di Windows è memorizzato nei registri di Windows. La directory slash (
Nota del traduttore: in realtà, questo sembra leggermente cambiato, come riportato dal seguente passo, tratto da "Managing projects with GNU make"
Di Robert Mecklenburg e Andrew Oram: La directory root in un file system POSIX è
La libreria esporta diverse funzioni Cygwin che possono essere utilizzate da programmi esterni per convertire un percorso o una lista di percorsi da Win32 a POSIX o viceversa. Gli script di shell e Makefiles non possono chiamare direttamente queste funzioni, ma possono eseguire la stessa conversione utilizzando l'utility cygpath, fornita con Cygwin. I file system Win32 sono case preserving ma case insensitive. Cygwin non supporta attualmente una distinzione case, perchè, in pratica, solo pochi programmi UNIX la richiedono. Se da una parte potremmo trattare i nomi di file al fine di supportare la distinzione di case, questo aggiungerebbe una non necessaria quantità di lavoro alla libreria e comporterebbe qualche difficoltà alle applicazioni non Cygwin di accedere ai file. I link simbolici vengono emulati da file contenenti un magic cookie seguito dal percorso al quale punta il link. Sono marcati come System, in modo che per determinare se un file è un link simbolico si debbano leggere solo i file di System. Gli hard link sono interamente supportati da NT su NTFS. Sui file system FAT, la chiamata effettua semplicemente la copia del file, una strategia che funziona in molti casi. Il numero inode di un file è calcolato dal suo completo percorso Win32. Il numero inode generato dalla chiamata a stat mostra sempre quello ritornato in d_ino della struttura dirent ( differenti file system possono avere differenti strutture di directory e di file. La struttura dirent definisce una struttura indipendente dal file system
e contiene informazioni comuni condivise da diversi file system ). Serve ricordare che il numero prodotto da questo metodo non è garantito essere unico. Tuttavia, non riteniamo ciò un problema rilevante vista la bassa probabilità di generare un numero di inode duplicato. Chroot è supportato dalla release 1.1.3. Ricordate che Chroot non è supportato nativamente da Windows. Ciò comporta qualche restrizione. Innanzitutto, la chiamata a Chroot non è una chiamata privilegiata. Ogni utente può chiamarla. Secondo, l'ambiente Chroot non è sicuro rispetto ai processi nativi Windows. Se desiderate fornire un ambiente sicuro a Chroot, per esempio permettendo un anonimo ftp con accesso limitato, dovrete preoccuparvi che all'interno dell'ambiente Chroot ( directory ) siano accessibili solo applicazioni native Cygwin. Visto che le applicazioni utilizzano solo API POSIX Cygwin per accedere al file system, l'accesso dovrà essere ristretto come da vostra intenzione. Inclusi non solo i percorsi POSIX ma anche i percorsi Win32 ( contenenti le lettere dei drive e/o backslash ) e CIFS ( Text Mode vs. Binary Mode L'interoperabilità con i programmi Win32 quali gli editor di testo era uno dei punti critici per il successo nella portabilità dei tool di sviluppo. Molti clienti di Red Hat che aggiornavano i meno recenti tool di DOS si aspettavano che i nuovi di Win32 continuassero a funzionare con i loro vecchi sorgenti. Sfortunatamente, UNIX e Win32 utilizzano differenti codici per il fine linea nei file testo. Conseguentemente, la sequenza CRLF deve essere tradotta da Cygwin in un singolo LF nella lettura di file di testo. Questa soluzione soddisfa il requisito della compatibilità a spese della violazione dello standard POSIX che richiede che le modalità testo e binary siano identiche. Di conseguenza, i processi che effettuano un lseek su file di testo, non possono contare sul numero di byte letti come un indicatore accurato della posizione nel file. Per questa ragione, la variabile d'ambiente CYGWIN può essere impostata ad evitare questo comportamento. La libreria ANSI C Abbiamo scelto di includere la libreria già esistente di Red Hat, "newlib", come parte della libreria, anzichè riscrivere tutta le chiamate lib C e math da zero. Newlib è una libreria ANSI C derivata da BSD, una volta utilizzata solo dai cross-compiler per lo sviluppo di sistemi embedded. Il riutilizzo di implementazioni libere di cose quali le librerie glob, regexp, e getopt ci ha risparmiato considerevoli sforzi. Inoltre, Cygwin utilizza l'implementazione libera malloc di Doug Lea, implementazione nella quale velocità e compattezza ritrovano un giusto equilibrio. Gli accessi alle chiamate malloc vengono effettuate dalla libreria grazie ad un puntatore. In questo modo, un processo Cygwin può fornire un suo malloc, se richiesto. Creazione di un processo La chiamata Cygwin a fork è particolarmente interessante vista la poca compatibilità con API Win32, che rende davvero difficoltosa una implementazione corretta. Attualmente, il fork di Cygwin è una implementazione non copy-on-write, simile a quella presente nelle prime versioni di UNIX.
La prima cosa che accade quando un processo padre crea, con fork, un processo figlio, è che il padre inizializza uno spazio nella tabella Cygwin dei processi per il figlio.
Quindi, crea un processo figlio, sospeso, utilizzando la chiamata Win 32 CreateProcess. Subito dopo, il processo padre chiama setjmp e salva il proprio contesto, impostando un puntatore in un'area di memoria condivisa di Cygwin ( condivisa da tutti i processi Cygwin ).
Alla fine, popola le sezioni Segnali Quando un processo Cygwin viene lanciato, la libreria apre un thread secondario, da utilizzare come gestore di segnali. Questo thread resta in attesa di eventuali segnali Windows destinati al processo in esecuzione. Quando il processo intercetta un segnale, verifica la sua sottomaschera per gestirlo in modo appropriato. Il fatto che il gestore di segnali operi nello stesso spazio degli indirizzi del programma in esecuzione comporta una serie di complicazioni. La prima conseguenza risiede nel fatto che, senza una particolare attenzione, le funzioni di sistema possano essere facilmente interrotte. Da parte nostra, stiamo cercando di evitare che la funzione Socket Tutte le chiamate correlate al socket, in Cygwin, chiamano, in sostanza, le funzioni di Winsock, l'implementazione Microsoft dei socket Berkeley, che hanno lo stesso nome, anche se contengono molte differenze. I socket, dietro le quinte, non hanno alcun blocco, così da permettere le chiamate di interrupt inviate dai segnali POSIX. Un ulteriore controllo si rende necessario per implementare una corretta semantica POSIX comune e, in particolare, la chiamata a Select La funzione Unix Per installare Cygwin, andate all'indirizzo:
e cliccate su "Install Cygwin Now!". Installerete così un GUI installer chiamato setup.exe che potrete lanciare per completare l'installazione di Cygwin via internet. Seguite le istruzioni.
setup.exe è disegnato per essere di facile comprensione per i nuovi utenti, pur offrendo una certa flessibilità per i più esperti. Il team di sviluppo, composto da volontari, è sempre al lavoro su setup.exe; prima di richiedere nuove funzioni, verificate la wishlist nel file README CVS ( dovrebbe essere già presente nella versione CVS ).
Dal momento in cui il valore di default per ciascuna opzione è la scelta logica per la gran parte delle installazioni, potrete scaricare un minimo ambiente Cygwin semplicemente cliccando il bottone
setup.exe crea una directory locale in cui salvare i pacchetti prima di installarne il contenuto, mentre l'opzione:
esegue solo la prima parte ( crea una directory locale in cui salvare i pacchetti, senza installarli ); e l'opzione
esegue solo la seconda parte ( installazione dei contenuti dei pacchetti ). L'opzione "Download from Internet" serve principalmente a creare una struttura base del pacchetto Cygwin in un computer per poi installarlo su più macchine con l'opzione "Install from Local Directory", che copia l'intera struttura locale in un'altra macchina lasciando intatta la struttura. Per esempio: create la directory:
in cui salvate setup.exe. Lanciate setup.exe selezionando l'opzione "Install from Internet" oppure "Download from Internet"; quindi copiate l'intero contenuto di
in un'altra macchina: in quest'altra macchina, utilizzate l'opzione "Install from Local Directory". Sfortunatamente, setup.exe non supporta ancora installazioni automatiche. Sebbene tutto ciò offra una sorta di funzionalità mirroring, se state gestendo una installazione estesa di Cygwin, per mantenerla aggiornata raccomandiamo di utilizzare un tool di mirroring quale wget. Un utente della mailing list di Cygwin ha creato un semplice script di dimostrazione a questo scopo; per averne un'idea, cercate nella lista mkcygwget. Selezionare una directory di installazione La directory Root di default per Cygwin:
diventerà la directory root (
dovrebbe essere sempre lasciata sul valore di defualt (
dovrebbe rimanere Local Package Directory E' la cache dove setup.exe memorizza i pacchetti prima di installarli. La cache non deve essere la stessa cartella di root per Cygwin. All'interno della cache viene creata una directory distinta per ciascun mirror Cygwin: ciò permette a setup.exe di utilizzare mirror multipli e pacchetti personalizzati. Una volta completata l'installazione, la cache non è più necessaria, ma potreste desiderare di conservare i pacchetti come backup, per installare Cygwin su un diverso sistema operativo o per reinstallare i pacchetti quando si rendesse necessario. Connection Method Il metodo di download
effettuerà direttamente il download dei pacchetti, mentre il metodo
utilizzerà abilmente la vostra cache IE5 per ottimizzare le prestazioni. Se la vostra organizzazione utilizza proxy server o script di autoconfigurazione, quest'ultimo metodo utilizzerà le loro impostazioni. Se avete un proxy server, potrete inserirlo manualmente nella sezione
Sfortunatamente, setup.exe non supporta l'autorizzazione via password per i server proxy. Scegliere un mirror Dovrete scegliere almeno un mirror dal quale effettuare il download. I mirror Cygwin sono distribuiti in tutto il mondo. Verificate la lista all'indirizzo: http://cygwin.com/mirrors.html, per trovarne uno vicino a voi. Potete selezionare mirror multipli tenendo premuto il tasto CTRL. Se avete un indirizzo non presente nella lista, potete aggiungerlo. Scegliere i pacchetti Per ciascun mirror selezionato, setup.exe effettuerà il download di un piccolo file di testo, chiamato
che contiene una lista di pacchetti disponibili da quel sito con informazioni di base su ciascun pacchetto, utilizzato da setup.exe per creare la finestra di selezione. Per maggiori dettagli sul formato di questo file, vedi la home page di setup.exe.
Il chooser ( selezionatore ) è la parte più complessa di setup.exe. I pacchetti sono raggruppati per categorie, ma un pacchetto può appartenere a più categorie ( assegnate dai gestori - manutentori dei pacchetti ).
Ciascun pacchetto può essere trovato in ognuna di queste categorie nell'ordine gerarchico stabilito dal selezionatore. Di default, setup.exe installerà soltanto i pacchetti della categoria Nota del traduttore: GCC è un acronimo per “GNU Compiler Collection”, una distribuzione integrata di compilatori per diversi linguaggi di programmazione. Questi linguaggi includono: C, C++, Objective-C, Objective-C++, Java, Fortran, e Ada. Se scegliete di effettuare il download per componenti specifici, invece che di tutta la distribuzione, dovete scaricare la distribuzione core GCC, più le specifiche distribuzioni dei linguaggi che desiderate utilizzare. Importante: trattandosi di file sorgenti, questi vi saranno di poca utilità se già non avete un compilatore C installato sulla vostra macchina. Se non avete già un compilatore, avete bisogno dei binari pre-compilati. Per esempio, per Windows: Cygwin e MinGW. Dal momento in cui setup.exe seleziona automaticamente tutte le dipendenze necessarie, abbiate cura di non deselezionare i pacchetti obbligatori. In particolare, tutto, nella categoria
Se siete familiari con Unix, probabilmente vorrete dare almeno un'occhiata alla lista completa dei vostri tool preferiti. Una volta installato Cygwin, il selezionatore di setup.exe può essere utilizzato per gestire la vostra installazione. Informazioni sui pacchetti installati sono contenute nella directory:
della vostra installazione Cygwin; se setup.exe non trova questa directory, si comporterà come se non ci fosse alcun Cygwin installato.
Se setup.exe trova una nuova versione disponibile di un pacchetto installato, automaticamente lo segnerà come da aggiornare. Per Disinstallare, Reinstallare, o effettuare il download di un sorgente per un pacchetto esistente, cliccate il bottone Download and Installation Progress Innanzitutto, setup.exe effettuerà il download di tutti i pacchetti selezionati nella directory locale scelta precedentemente. Prima dell'installazione, setup.exe esegue un checksum su ciascun pacchetto. Se la directory locale scelta è un hardware lento ( come un disco di rete ), questo processo porterà via molto tempo. Durante il download e l'installazione, setup.exe mostrerà le barre di progressione per il processo corrente e il totale di spazio disco ancora libero. Icone Potete scegliere di installare uno shortcut sul desktop e / o nel menu Start per avviare una shell bash. Se preferite utilizzare una shell differente o la versione nativa di Windows di Script eseguiti dopo l'installazione Per ultimo, setup.exe eseguirà tutti gli script post-installazione, per completare correttamente le impostazioni dei pacchetti installati. Visto che ogni script viene eseguito separatamente dagli altri, potreste vedere aprirsi diverse finestre pop up. Se vi interessa sapere cosa sta accadendo, leggete la Guida: Cygwin Package Contributor's Guide. Al completamento di tutti gli script post-installazione, setup.exe mostrerà una finestra di fine lavoro. Pochi pacchetti, quali OpenSSH server, richiedono qualche configurazione manuale specifica. Documentazione utile potete trovarla in una delle due directory:
Troubleshooting Sfortunatamente, il complesso processo di setup può comportare qualche problema. Se riscontrate problemi durante il download dei pacchetti, potrebbe trattarsi di una congestione di rete: provate, in questo caso, un mirror differente e/o un diverso protocollo ( HTTP invece di FTP ). Se notate qualche problema dopo il setup, potete verificare il log di setup.exe:
Fate una copia di backup di questo file prima di lanciare ancora setup.exe e seguite i passi in: Reporting Problems with Cygwin. E' possibile specificare le impostazioni di molte importanti variabili d'ambiente che influiscono sulle operazioni di Cygwin. Alcune di queste variabili devono essere impostate prima di aprire una sessione Cygwin ( prima di lanciare la shell bash ). Le variabili d'ambiente possono essere impostate anche in ambiente Windows, visto che tutte le variabili d'ambiente Windows vengono importate da Cygwin. Le impostazioni possono essere scritte in un file
nella directory root specificata durante il setup. Questo file è raggiungibile dal Menu Start, nell'opzione "Cygwin". E' possibile editare questo file a vostro piacimento, oppure creare i propri file
La variabile d'ambiente CYGWIN La variabile
è utilizzata per configurare diverse impostazioni globali per il runtime Cygwin. Inizialmente, potete lasciare vuota questa variabile o impostarla con il valore:
La variabile d'ambiente CYGWIN può contenere le seguenti opzioni, separate da spazi ( molte opzioni possono essere escluse utilizzando il prefisso
Alcune opzioni della variabile d'ambiente CYGWIN, presenti nelle passate versioni, sono state rimosse, per un motivo o per l'altro, da Cygwin 1.7:
Variabili d'ambiente: supporto locale Il supporto locale viene gestito dalle variabili d'ambiente:
E' da Cygwin 1.7.2 che queste variabili d'ambiente hanno un senso e vengono utilizzate. E' possibile impostarle tutte, ma Cygwin onorerà solo le variabili:
esattamente in questo ordine, in accordo allo standard POSIX. Il contenuto di queste variabili dovrebbe seguire lo standard POSIX per uno specificatore locale. La forma corretta di uno specificatore locale è:
dove:
Se lo specificatore locale non rispetta questa forma, Cygwin verifica se il valore locale è uno degli alias definiti nel file:
Se è così, e se la sostituzione del valore locale è supportata da Windows, il valore locale identificato viene accettato. Quindi, una volta accettato il contenuto del file
Il file
è creato dal package
Il valore di default, in assenza delle variabili d'ambiente summenzionate, è:
Windows utilizza il set di caratteri UTF-16 solo per memorizzare i nomi degli oggetti usati dal sistema operativo. Ciò è particolarmente importante per i nomi di file. Cygwin si serve delle impostazioni delle variabili d'ambiente locali LC_ALL, LC_CTYPE e LANG per determinare la modalità di conversione dei nomi di file Windows dalla loro rappresentazione UTF-16 alla loro rappresentazione a byte singolo o a byte multipli, propria dei set di caratteri usati da Cygwin. L'impostazione delle variabili d'ambiente locali all'inizio di un processo diventa effettiva, per la conversione interna, effettuata da Cygwin, sui nomi degli oggetti Windows, da e verso UTF-16, per l'intero ciclo di vita del processo corrente. Modificare il valore delle variabili d'ambiente, modifica anche la modalità di conversione dei nomi di file, ma solo per i successivi processi figli, e non per lo stesso processo in esecuzione. Tuttavia, anche se una delle variabili d'ambiente locali è impostata su un qualche valore diverso da "C", questo coinvolge esclusivamente il metodo Cygwin di conversione dei nomi di file. Secondo lo standard POSIX, infatti, l'attivazione del valore locale per l'uso di un'applicazione è responsabilità dell'applicazione stessa, e viene eseguita con la chiamata:
da effettuarsi al più presto nel codice sorgente dell'applicazione. Ancora una volta, affinchè non vada perduto: se l'applicazione chiama
Cosa accade con le applicazioni non sensibili al valore locale? Per POSIX, sono impostate su "C" o "POSIX", fatto che implica il set di caratteri ASCII. La DLL di Cygwin, tuttavia, userà sempre e comunque l'impostazione locale che trova nelle variabili d'ambiente ( oppure il valore di default: C.UTF-8 ) per la conversione dei nomi dei file. Quando il valore locale specifica un set di caratteri ASCII ( per esempio: "C" o "en_US.ASCII" ), Cygwin continuerà ad utilizzare UTF-8 dietro le quinte, per la traduzione dei nomi di file. Questo permette una maggiore interoperabilità tra le applicazioni che utilizzano "C.UTF-8". A partire da Cygwin 1.7.2, i valori di "language" e "territory" vengono utilizzati per reperire informazioni dipendenti dalla località in Windows. Se "language" e "territory" sono sconosciuti a Windows, la chiamata a
Se non scegliamo un set di caratteri, quale userà Cygwin? Ebbene, a partire da Cygwin 1.7.2, il set di caratteri di default viene determinato dal codepage ANSI di Windows per quella lingua e per quella regione geografica ( il primo codepage ANSI di Windows, codepage 1252, fu creato come forma modificata della bozza ANSI che, in seguito, sarebbe sfociata nella ISO 8859-1 ). Cygwin utilizza un set di caratteri che è l'equivalente Unix del codepage ANSI di Windows. Per esempio:
Cosa fare se non desideriamo utilizzare il set di caratteri di default? In questo caso, dovremo semplicemente specificare esplicitamente il set di caratteri desiderato. Ipotizziamo, per esempio, di essere Giapponesi e di non voler utilizzare il set di caratteri EUC-JP, ma di preferire a quest'ultimo il set di caratteri previsto da Windows come set di default: SJIS. Quello che possiamo fare, in questo caso, è impostare la variabile d'ambiente, per esempio, LANG nel file:
che è il file batch che viene eseguito ogni volta che si apre una sessione Cygwin dal desktop.
Un altro concetto da ricordare è che i set di caratteri a byte singolo o a byte doppio comportano un grande svantaggio. Mentre i filesystem di Windows utilizzano i set di caratteri codificati in UTF-16, per memorizzare le informazioni relative ai nomi di file, non tutti i caratteri Unicode hanno una corrispondenza con i set di caratteri a uno o due byte. Anche se Cygwin ha una soluzione per accedere ai file contenenti caratteri strani ( o stranieri ), la miglior soluzione resta quella di usare sempre il set di caratteri UTF-8.
UTF-8 è il solo set di caratteri multibyte che possa rappresentare tutti i caratteri Unicode. Il set di caratteri della Console di Windows Per la gran parte del tempo, sarà la console di Windows a lanciare le applicazioni Cygwin. Mentre emulazioni di terminali quali
oppure nell'ambiente Windows, ma anche direttamente nella shell di Cygwin, al volo.
Last but not least, ecco la lista dei set di caratteri attualmente supportati. L'espressione sulla sinistra è il nome del set di caratteri, quello che utilizzerete, per intenderci, nelle variabili d'ambiente di cui abbiamo appena parlato. Da sottolineare che lo specificatore del set di caratteri non è sensibile alle minuscole / maiuscole.
sono tutte espressioni equivalenti. Tuttavia, scrivere il set di caratteri nello stesso modo in cui viene riportato nella lista che segue, rimane una buona convenzione. Nella parte destra, trovate il codepage, un numero, ed il nome Windows equivalenti. Vengono qui riportati solo come supporto. Non utilizzateli come specificatori di set di caratteri, a meno che il nome non sia identico al nome riportato sulla colonna di sinistra. In particolare, nel caso dei set di caratteri composti da "CPxxx", usate sempre il prefisso "CP".
Potete trovare la lista completa dei codepage di Windows nella pagina Microsoft MSDN Code Page Identifiers.
La variabile d'ambiente PATH La variabile d'ambiente PATH viene utilizzata dalle applicazioni Cygwin come lista di directory in cui cercare file eseguibili da lanciare. Questa variabile viene convertita dal formato Windows, per esempio:
al formato Unix:
non appena viene lanciato un processo Cygwin. Se desiderate utilizzare i tool di Cygwin esterni a bash, impostate questa variabile in modo che contenga almeno la directory
dove La variabile d'ambiente HOME La variabile d'ambiente HOME viene utilizzata da diversi programmi per determinare la posizione della vostra directory home e raccomandiamo che sia impostata. Anche questa variabile viene convertita dal formato Windows non appena viene lanciato un processo Cygwin. Normalmente, viene impostata negli script di profilo della shell, contenuti nella directory:
La variabile d'ambiente TERM La variabile d'ambiente TERM specifica il tipo di terminale. Viene automaticamente impostata come cygwin, a meno che non l'abbiate impostata voi su un qualsiasi altro valore. La variabile d'ambiente LD_LIBRARY_PATH La variabile d'ambiente LD_LIBRARY_PATH viene utilizzata dalla funzione Altre tre variabili d'ambiente Esistono altre tre variabili d'ambiente che, se presenti nell'ambiente Windows, vengono convertite al formato UNIX:
Mentre la prima non viene impostata, di default, nell'ambiente Windows, le altre due vengono impostate e puntano alla directory temporanea di Windows. Se impostate, queste variabili verranno utilizzate da alcune applicazioni Cygwin, generando, probabilmente, un risultato inatteso. Sarebbe, quindi, meglio azzerarle, aggiungendo queste due linee al vostro file
In alternativa, è possibile impostare TMP e TEMP affinchè puntino su
Esiste una restrizione nel chiamare le funzioni API Win32 che richiedono l'impostazione di tutte le variabili d'ambiente. Cygwin conserva le sue variabili in stile POSIX. L'ambiente Windows viene, normalmente, ridotto al minimo e non viene sincronizzato con l'ambiente POSIX di Cygwin. Se avete bisogno dell'intero set di variabili di Win32 in un processo Cygwin, eseguite la seguente chiamata:
Questa sincronizzazione viene effettuata una sola volta. Le modifiche successive, attuate con
|
|||
Cygwin User's Guide | Disclaimer: this link points to content provided by other sites. |