Informazioni per l'A.A. 2008-2009


Esempio di collegamento mediante OpenSSH dal terminale di una macchina Linux o MacOS X o Cygwin al server del corso basidati - A.A. 2008-9

Prego dare la precedenza al sito del corso e al docente, in particolare per le domande che non riguardano l'attuale configurazione del server.
  1. Connettersi ad una macchina raggiungibile da casa contemporaneamente impostando i tunnel necessari (aggiungendo anche l'opzione -f ssh va in backgroud dopo aver chiesto la password così da avere solo i tunnel ma nessun prompt dei comandi su ssh.studenti); ad esempio:
    ssh -L20443:basidati:443 -L20080:basidati:80 -L20022:basidati:22 nomeutente@ssh.studenti.math.unipd.it
    ancora ad esempio (qui va usato il FQDN in quanto la Torre e il Paolotti hanno sottodomini differenti):
    ssh -L20443:basidati.studenti.math.unipd.it:443 -L20080:basidati.studenti.math.unipd.it:80 -L20022:basidati.studenti.math.unipd.it:22 nomeutente@sshtorre.math.unipd.it
    NB: queste shell, anche se in foreground, danno al più la possibilità di collegarsi ai server interni come se si fosse in aula (vedi nota).
    Attenzione: i comandi ssh vanno dati dal proprio pc (ad esempio, di casa), non da una shell già aperta dentro l'aula; insomma se i tunnel sono impostati dal prompt di dipXXX, sarà l'indirizzo 'http://dipXXX:20080' quello da digitare per sfruttare i tunnel: non è affatto detto che tale indirizzo sia raggiungibile da casa.
  2. se si vuole fare direttamente l'upload sul server basidati.studenti.math.unipd.it dei file di una cartella locale (-r serve appunto per un copia ricorsiva), ad esempio xTecWeb, va lanciato un ulteriore processo scp (-P MAIUSCOLA):
    scp -P 20022 -r xTecWeb nomeutente@localhost:public_html (-p minuscola preserva i permessi come lettura, scrittura, esecuzione)
  3. se si vogliono dare comandi dentro il server basidati è necessario aprire un'altra shell lanciando verso il server del corso un secondo comando ssh (-p minuscola):
    ssh -p 20022 nomeutente@localhost
    NB: in effetti quella sopra è la riga di comando che si deve dare dal terminale di casa, dalla shell ssh già aperta nel server ssh dell'aula basta un collegamento diretto (di nuovo vedi nota)
  4. trasferendo i file da casa, può capitare che i file non abbiano i permessi giusti: in caso di errore e in mancanza del tempo per seguire le istruzioni sulla configurazione del server, provare il comando (invero un po' sciatto, le normali pagine html non hanno affatto bisogno di essere eseguibili):
    chmod -R 750 ~/public_html
    In caso di problemi con i permessi speciali si può invece dare il comando:
    chmod -R 0750 ~/public_html/
    (le directory invero potrebbero tenere il bit S che così viene tolto, per limitarsi a togliere i permessi alle sole directory, vedi altrove).
    NB: se usato dopo il trasferimento dei file, il comando va dato in una shell del server web (non nel server ssh usato per i tunnel o nel computer di casa dove avrebbe senso solo prima del trasferimento e a patto di preservare i permessi).
  5. Si possono controllare le modifiche dal browser (anche da Firefox):
    lynx http://localhost:20080/~nomeutente/
  6. phpMyAdmin è raggiungibile solo attraverso il protocollo HTTPS (anche da Firefox):
    lynx https://localhost:20443/phpmyadmin/
Attenzione: anche collegandosi dall'aula a https://basidati.studenti.math.unipd.it/phpmyadmin/ potreste avere problemi col certificato del sito: seguire le istruzioni sui certificati (per l'uso di ssh le istruzioni sulle chiavi).

To top


Esempio di collegamento mediante OpenSSH dal terminale di una macchina Linux o MacOS X o Cygwin al server del corso tecnologie-web - A.A. 2008-9

Prego dare la precedenza al sito del corso e al docente, in particolare per le domande che non riguardano l'attuale configurazione del server.
  1. Aprire una prima shell su una macchina raggiungibile da casa e che per le impostazioni del firewall possa raggiungere il server del corso: anche se in foreground, la prima shell ssh da al più la possibilità di collegarsi ai server interni come se si fosse in aula (vedi nota). Aggiungendo l'opzione -f ssh va addirittura in backgroud dopo aver chiesto la password, così da avere solo i tunnel ma nessun prompt dei comandi. Partire dalla shell del proprio pc (ad esempio, di casa):
    • Visto che il server sta al Paolotti, connettersi a ssh.studenti.math.unipd.it e contemporaneamente impostare i due tunnel necessari (uno per ogni opzione -L):
      ssh -L30080:tecnologie-web:80 -L30022:tecnologie-web:22 nomeutente@ssh.studenti.math.unipd.it
    • Altrimenti collegarsi a sshtorre.math.unipd.it; per i tunnel da impostare contemporaneamete al collegamento va allora usato il FQDN in quanto la Torre e il Paolotti hanno sottodomini differenti:
      ssh -L30080:tecnologie-web.studenti.math.unipd.it:80 -L30022:tecnologie-web.studenti.math.unipd.it:22 nomeutente@sshtorre.math.unipd.it
    Il tunnel viene sfruttato a pieno nei passi successivi a questo.
  2. se si vuole fare direttamente l'upload sul server tecnologie-web dei file di una cartella locale (-r serve appunto per un copia ricorsiva), ad esempio xTecWeb, nel proprio computer (ad esempio quello di casa) va lanciato un ulteriore processo scp (-P MAIUSCOLA):
    scp -P 30022 -r xTecWeb nomeutente@localhost:public_html
  3. se si vogliono dare comandi direttamente dentro tecnologie-web è necessario aprire un'altra shell lanciando verso il server del corso un secondo comando ssh (-p minuscola):
    ssh -p 30022 nomeutente@localhost
  4. Si possono controllare le modifiche dal browser (anche da Firefox):
    lynx http://localhost:30080/~nomeutente/

Note all'uso del tunnel per collegarsi al server del corso tecnologie-web

  • Da un computer dell'aula (incluso ssh.studenti.math.unipd.it) o della Torre Archimede (incluso sshtorre.math.unipd.it) o della rete Wi-Fi degli studenti non é necessario stabilire alcun tunnel: a seconda di quello che si vuole ottenere é sufficiente usare il nome del server e la porta di default cioé:
    • per trasferire i file:
      scp -r xTecWeb nomeutente@tecnologie-web.studenti.math.unipd.it:public_html
      NB: in questo caso la cartella xTecWeb si trova nella propria home dell'aula e non sul computer di casa; dalla una shell dentro tecnologie-web si lancia viceversa:
      scp -r nomeutente@ssh.studenti.math.unipd.it:xTecWeb ~nomeutente/public_html
      scp -r nomeutente_casa@server_casa.tld:xTecWeb ~nomeutente_casa/public_html/ 
    • per avere una shell:
      ssh nomeutente@tecnologie-web.studenti.math.unipd.it
    • collegarsi con un browser a http://tecnologie-web.studenti.math.unipd.it/~nomeutente/.
  • Viceversa quando collegati in ssh da casa con un tunnel:
    • per trasferire file o per dare comandi da shell é necessario rispettivamente un ulteriore comando scp e/o un secondo comando ssh (quelli dei punti 2 e 3 che vannno dati nel computer di casa). Se si é abituati ad usare un programma con interfaccia grafica per il trasferimento dei file è solo da qui che si procede come al solito (pur di scegliere come server host localhost e le porte reindirizzate, ad esempio 30022)
    • l'indirizzo da controllare é proprio http://localhost:30080/~nomeutente/

Note alla configurazione del server del corso tecnologie-web

Configurazione delle pagine statiche
  • Tutte le pagine devono essere leggibili all'utente www-data cioè nella configurazione attuale almeno dal gruppo iniziale dell'utente; nel caso si siano fatte modifiche al layout del file system come preparato per il corso si può lanciare:
    find ~/public_html/ -type f -exec chmod u=rwX, g=r,o= '{}' \;
    find ~/public_html/ -type d -exec chmod u=rwx,g=x,o= '{}' \;
    dove il comando -exec di find chiede proprio di essere terminato dal punto e virgola che è preservato dalla shell mediante quoting come pure '{}' è il parametro che prende il nome dei file/cartelle trovate e ed è preservato dalla shell con le virgolette singole. Una versione più compatta che nella maggior parte dei casi da lo stesso risultato è: chmod -R u=rwX,g=rX ~/public_html (attenzione: lettera X maiuscola, altrimenti si rendono eseguibili anche i regular file, cosa inutile o dannosa). Per la precisione i comandi del primo esempio danno tutti i permessi all'utente proprietario (quello di esecuzione solo se il file è eseguibile) e per il resto la sola lettura dei file in qualunque directory siano, solo al suo gruppo iniziale: nessun permesso agli altri. Nel secondo esempio invece una eventuale cartella in cui il proprietario non potesse entrare, rimarrebbe inaccessibile a tutti: lui incluso.
Configurazione degli script
  1. All'inizio del corso 2008-9 gli script cgi giravano come utente www-data: una volta aperta una shell dentro tecnologie-web poteva essere il caso di creare una cartella in cui tale utente (ora membro del gruppo iniziale di ogni utente) potesse scrivere:
    (export random=$RANDOM ; mkdir -p ~/data/$random ; chmod g+rw ~/data/$random)
    Ora l'utente www-data è membro del gruppo iniziale di ogni utente; rimane una buona prassi tenere i file di appoggio esterni al percorso accessibile agli utenti Internet ma visto che con mod_suexec gli script girano come l'utente stesso è meglio non dare permessi di scrittura non necessari al proprio gruppo iniziale:
    (export random=$RANDOM ; mkdir -p ~/data/$random ; chmod go= ~/data/$random)
  2. Tutti i cgi (con l'eventuale eccezione dei php inline, al momento disabilitati) devono risiedere in ~/public_html/cgi-bin o in eventuali sue sottodirectory: non a caso è impedito all'interno degli eventuali file .htaccess l'uso di Options +ExecCGI.
    Altrettanto una funzionalità voluta che non si possa controllare da web il contenuto della cartella ~/public_html/cgi-bin e delle sue sotocartelle; se proprio si desidera mostrare il sorgente dei proprio script ai navigatori provare con
    ln -s ~/public_html/cgi-bin ~/public_html/src
    ed assumersi la responsabilità della minor sicurezza conseguente all'esposizione dei bachi (soprattutto in assenza di una partecipazione della comunità alla correzione degli stessi).
  3. Al momento le uniche estensioni ammesse per essere eseguite come cgi sono .pl e .cgi (ragionevole anche per eventuali eseguibili compilati). File di altra estensione (come i .html) potrebbero venire mostrati agli eventuali utenti Internet pur se lasciati in ~/public_html/cgi-bin/. Altrettanto link (a livello di file sytem) con diversa estensione agli script cgi-bin.
  4. Tutti i cgi (con l'eventuale eccezione dei php inline, al momento disabilitati) devono essere eseguibili dall'utente proprietario e almeno leggibili dall'utente www-data cioè nella configurazione attuale dal gruppo iniziale dell'utente; nel caso si siano fatte modifiche al layout del file system come preparato per il corso si può lanciare:
    find ~/public_html/ -type d -exec chmod u+x,g+X,o= '{}' \;
    find ~/public_html/cgi-bin/ -name '*.pl' -or -name '*.cgi' -exec chmod u+x,g=r,o= '{}' \;
    dove il comando -exec di find chiede proprio di essere terminato dal punto e virgola che è preservato dalla shell mediante quoting come pure '{}' è il parametro che prende il nome dei file/cartelle trovate e ed è preservato dalla shell con le virgolette singole.
  5. I cgi del punto precedente e la cartelle che li contengono a partire da cgi-bin stessa, soprattutto se lanciati da mod_suexec come al momento avviene, debbono essere modificabili solo dal proprietario, quindi né dal gruppo iniziale dell'utente né da other; i permessi di scrittura possono essere tolti coi comandi precedenti o anche solo con:
    chmod -R g-w,o-w ~/public_html/cgi-bin/
    Nel caso mod_suexec non fosse abilitato e gli script girassero tutti come www-data, comunque non sarebbe necessario o desiderabile che altri utenti li potessero modificare: normalmente basterebbe fossero modificabili i file di appoggio come mostrato all'inizio del punto 1.
    Altrettanto non è normalmente desiderabile che i propri script siano setuid o segid (altri utenti potrebbero sfruttare i bachi dell'eseguibile): di conseguenza mod_suexec si rifiuta di eseguire script con permessi speciali superiori a 1000 (sticky bit) e potrebbe servire il secondo comando di questo punto per togliere i permessi 4000 (u=s) e 2000 (g=s):
    find ~/public_html/cgi-bin/ -type f -exec chmod u-s,g-s,-t '{}' \;
  6. Ci sono altri controlli fatti da mod_suexec prima di eseguire lo script: ad esempio che il file venga lanciato dalla cartella definita (nella attuale configurazione ~/public_html/cgi-bin/) e che il cgi appartenga all'utente e al relativo gruppo iniziale sotto il quale è richiesta l'esecuzione (attualmente non dovrebbe esserci modo per gli utenti di eseguire chown da parte di utenti non privilegiati visto che il programma non è setuid root).
  7. Attenzione alla differenza fra perl ./index.pl e ./index.pl: lo script deve essere eseguibile in sè e non solo come parametro del suo interprete. Tutti gli script cgi-bin sono eseguiti da una shell di linux, quindi se iniziano con il tradizionale commento per indicare un interprete, il path deve essere corretto e le opzioni quelle volute. Capita che scrivendo il file di script su un altro sistema operativo al nome dell'interprete, apparentemente corretto, rimanga “attaccato” un carattere di fine riga scorretto (quindi l'interprete non viene trovato e apparare un messaggio come “perl^M: bad interpreter: No such file or directory&rdquo da shell, il solito “Internal Server Error&rdquo da browser): nel caso il file di testo dello script può essere pulito, ad esempio con un comando fra quelli sotto:
    for file in *.pl *.cgi ; do tr -d '\r' $file > $file.exdos ; mv $file.exdos $file ; done
    for file in *.pl *.cgi ; do fromdos $file ; done
    for file in *.pl *.cgi ; do tr '\r' '\n' $file > $file.exmac ; mv $file.exmac $file ; done
    A titolo esemplificativo come non deve e come deve apparire uno script:
    cat bad-interpreter.pl | hexdump -C 
    00000000 23 21 2f 75 73 72 2f 62 69 6e 2f 70 65 72 6c 0d |#!/usr/bin/perl.| 
    00000010 0a 0d 0a 0d 0a 23 70 72 6f 62 61 6c 6d 65 6e 74 |.....#probalment| 
    
    cat bad-interpreter.pl | fromdos | hexdump -C 
    00000000 23 21 2f 75 73 72 2f 62 69 6e 2f 70 65 72 6c 0a |#!/usr/bin/perl.| 
    00000010 0a 0a 23 70 72 6f 62 61 6c 6d 65 6e 74 65 20 66 |..#probalmente f| 
    
    Ovviamente col meccanismo della shebang line può essere chiamato un qualsiasi interprete, non solo bash o perl: ad esempio, a patto di avere uno vero script e non del codice embedded, /usr/bin/php. La riga dello shebang deve comunque essere la prima: non basta sia la prima non vuota.
  8. Con le attenzioni precedenti i file dovrebbero riuscire eseguibili anche da una shell interattiva; si consiglia di fare questa prova almeno per avere informazioni dai vari interpreti su eventuali errori di sintassi. In presenza di errori di sintassi lo script potrebbe non essere eseguito e il server restituire la pagina “Internal server error”. Si badi che un test con esito positivo da shell interattiva non assicura di avere uno script eseguibile correttamente dal server web: la pagina “Internal server error” può ad esempio essere restituita dal server anche quando gli script non sono leggibili a www-data o mancano gli header http. Un ulteriore problema di header http mancanti o fuori ordine può essere dovuto al buffering dello standard output, come spiegato nel paragrafo “Other Perils of Buffering”.
  9. Infatti lo script deve comportarsi come un script cgi ovvero produrre l'output previsto: non solo il testo in sé ma anche il corrretto header HTTP. Ciò può avvenire direttamente con un print o attraverso le funzioni dei vari package usati.
  10. Nel caso di uno script Perl l'eventuale debug degli errori può essere agevoltato esportando nel codice perl l'opzione di CGI::CARP (il resto del modulo è già attivo) che stampa a browser gli errori fatali:
    use CGI::Carp qw(fatalsToBrowser);
    Attenzione: per la mancata generazione da parte dello script Perl degli header http, può capitare che finché ci sono errori di sintassi il codice in CGI::Carp generi un output corretto o almeno utile (completo di header http) e che invece lo script privo di errori di sintassi e quindi pur funzionante da riga di comando, obblighi il server a restituire la pagina “Internal server error”.
  11. Quello sotto è un esempio che mostra alcuni dei moduli installati; altri possono venire aggiunti su richiesta (ed approvazione del docente):
    #!/usr/bin/perl -w
    #se metto un'opzione, l'eventuale Carriage Return rimane "attaccato" solo ad essa e non rischio messaggi di bad interpreter
    #probalmente fanno gia`parte della configurazione di mod_perl
    #use CGI::Carp; use CGI::Carp qw(carpout);
    #in fase di consegna potrebbe bastare questo
    #use CGI::Carp qw(fatalsToBrowser);
    use CGI::Carp qw(warningsToBrowser fatalsToBrowser);
    #da http://search.cpan.org/~gaas/libwww-perl-5.825/lib/LWP/Simple.pm
    #Note that if you are using both LWP::Simple and the very popular\ CGI.pm module, you may be importing a head function from each module, producing a warning like "Prototype mismatch: sub main::head ($\ ) vs none". Get around this problem by just not importing LWP::Simple's head function, like so:
    use LWP::Simple qw(!head);
    use CGI qw(:standard);
    use CGI::Session;
    use Apache::Session;
    use XML::Simple;
    use XML::LibXML;
    use XML::Writer;
    #use XML::Handler::YAWriter;
    #usato?
    #use XML::Handler::Composer;
    #usato? use XML::XSLT;
    #incompleta, meglio LibXSLT
    use XML::LibXSLT;
    use Image::Size;
    use Net::SMTP;
    my $redirect=0;
    $smtp = Net::SMTP->new('smtp.studenti.math.unipd.it', Hello => 'studenti.math.unipd.it', Timeout => 30, Debug => 1,);
    $smtp->mail($ENV{USER} . "\@studenti.math.unipd.it");
    $smtp->to ($ENV{USER} . "\@studenti.math.unipd.it");
    $smtp->data();
    $smtp->datasend("To: ". ($ENV{USER}) . "\n");
    $smtp->datasend("Subject: prova dello script " . $0 . " " . $$ . "\n");
    $smtp->datasend("\n");
    if ( $redirect ) {
    print "Status: 302 Moved\r\nLocation: perltestCARP.pl\r\n\r\n";
    $smtp->datasend("Lo script ha solo ridiretto il browser...\n");
    } else {
    print "Content-type: text/html\r\n\r\n";
    print "Hello world!<br />\r\nThis is not really html.<br />\r\n";
    for ($i=0; $i<10; $i++) {
    print $i."<br />";
    }
    $smtp->datasend("Lo script ha stampato l'output di un ciclo...\n");
    }
    $smtp->dataend();
    $smtp->quit;
  12. Durante la fase di test degli script è inoltre opportuno tenere aperta una shell dentro il server del corso così da killare per tempo gli script che, ad esempio facendo un ciclo infinito, altrimenti appesantirebbero il server. Comandi utili risultano ps ux; killall nomeprogramma; o anche htop (ncurses-based process viewer).

To top


www.Studenti.Math.UniPD.it: Programmazione

Programmazione - CL in Informatica - A.A. 2008-2009

Istruzioni per poter lavorare sul proprio PC agli argomenti del corso

(Queste istruzioni riguardano i possessori di PC Windows)

Durante le attività relative al corso sarà richiesto di sviluppare una serie di programmi. Questa attività si esegue utilizzando una serie di programmi nota come 'Ambiente di Sviluppo'. Ogni tipo di accoppiata Sistema Operativo/Linguaggio di Programmazione (di cui Windows/C++ e` un esempio) può avere a disposizione diversi ambienti di sviluppo.

Nell'aula informatica utilizzata dal corso e` installata una distribuzione del sistema operativo Linux, precisamente la Ubuntu 8.0.4 (i386) liberamente scaricabile dal sito http://www.ubuntu.com. L'ambiente di sviluppo C/C++ installato e` quello della GNU (http://www.gnu.org) ed e` quello che sarà utilizzato per il corso.

Linux/Ubuntu – di norma – non e` installabile come programma in un ambiente Windows. In un normale PC che utilizzi Windows l'installazione di Ubuntu prevede la divisione del disco fisso in due aree (partizioni) dedicate rispettivamente a Windows e a Ubuntu che saranno attive solo in alternativa, cioè non sarà possibile utilizzare programmi Linux mentre Windows e` attivo e viceversa.

Chi avesse intenzione di lavorare sul proprio PC ha a disposizione quattro possibili opzioni:

  1. Installare Linux sul proprio PC come sistema alternativo a Windows;

  2. Installare un emulatore sulla propria partizione Windows e installarvi una copia di Linux/Ubuntu;

  3. Installare Cygwin (http://www.cygwin.com), un sistema che mette a disposizione l'ambiente di sviluppo GNU tipico di Linux/Ubuntu. Il software e` liberamente scaricabile e utilizzabile;

  4. Installare altri tipi di ambienti di sviluppo. Tra quelli che mettono a disposizione una versione dell'ambiente GNU per il sistema operativo Windows citiamo:

    a) MinGW (http://www.mingw.org)

    b) Dev-C++ (http://www.bloodshed.net/devcpp.html)


Vediamo delle brevi istruzioni per ogni opzione:

1. Installare Linux sul proprio PC

Questa e` l'opzione piu` radicale e quella che permette performances migliori per il software che viene creato. In piu` permette di creare una installazione molto vicina a quella dell'aula informatica cosa che potra` risultare utile nel prosieguo degli studi.

Le istruzioni di base per realizzare l'operazione sono:

  1. Scaricare (download) dal sito http://www.ubuntu.com l'immagine ISO del disco di installazione e masterizzarla.

  2. Avviare il PC con inserito nel CD il disco appena masterizzato

  3. Seguire le istruzioni sullo schermo per dividere il disco nelle due aree (Windows e Linux) e installare Linux

Una versione in italiano delle istruzioni di installazione completa e` disponibile sul sito: http://wiki.ubuntu-it.org/Installazione/Grafica

2. Installare Linux in emulazione sul proprio PC Windows

Una opzione possibile ma che richiede un PC discretamente potente e` quella di installare un programma di emulazione che crei una macchina virtuale nella quale installare Linux. Per provare questa opzione e` meglio avere a disposizione almeno 512 MB di RAM (meglio 1GB) e un processore discretamente potente.

I programmi di emulazione sono diversi citiamo tra gli altri:

  1. VMWare (http://www.vmware.com)

  2. VirtualBox (http://www.virtualbox.org)

  3. Qemu (http://bellard.org/qemu)

In questo testo prenderemo in considerazione VirtualBox. Questa e` la sequenza di operazioni necessarie per installare Linux in una macchina virtuale.

  1. Scaricare VirtualBox dal sito;

  2. Scaricare l'immagine ISO del disco di installazione di Ubuntu da http://www.ubuntu.com;

  3. Installare il programma;

  4. Avviare il programma e cliccare sull'icona 'New' per creare una nuova macchina virtuale viene lanciata una procedura cui fornire i seguenti parametri:

    1. Name: sceglierne uno a piacere

    2. Operating System: Linux

    3. Version: Ubuntu

    4. Memory size: a piacere, sarebbe meglio non scendere sotto i 512MB

    5. Virtual Hard Disk: creare un nuovo hard disk virtuale cliccano 'New' , 'Dinamically Espanding Storage' e una dimensione di almeno 8GB (che verranno occupati man mano che verranno richiesti e non tutti subito)

  5. La macchina e` creata e ne compare la finestra delle impostazione, selezionare l'immagine ISO di Ubuntu scaricata come CD/DVD ROM

  6. Avviare la macchina virtuale, comapre una nuova finestra con le istruzioni di installazione di Linux. Fare riferimento al sito http://wiki.ubuntu-it.org/Installazione/Grafica per una versione in italiano delle istruzioni di installazione di Linux.


Una volta installato Linux ricordarsi di disabilitare l'uso dell'immagine ISO di Ubuntu al posto del CD/DVD ROM per evitare che riparta usando quella invece dell'installazione nuova.

3. Installare Cygwin

Per seguire questa strada:

  1. Scaricare il file 'setup.exe' dal sito madre 'http://www.cygwin.com cliccando sull'icona 'Install or update now'.

  2. Lanciare il programma e scegliere 'Install from Internet' se si dispone di una buona connessione ADSL altrimenti fare affidamento alla documentazione sul sito per le istruzioni su come scaricare sul proprio hard disk i pacchetti da installare successivamente.

  3. Proseguire con l'installazione, a un certo punto compare la finestra di titolo 'Cygwin Setup - Select Packages', nella sotto finestra occorre espandere cliccandoci sopra la categoria 'Devel' e all'interno dei pacchetti attivare l'installazione del gcc4 che e` la versione di C/C++ installata in aula.

  4. Terminare l'installazione e lanciare l'ambiente cliccando sull'icona. Compare una piccola finestra di terminale dalla quale e` possibile dare i comandi di compilazione che verranno illustrato nel corso.

4. Altri ambienti di sviluppo

Non viene fornito supporto per questa opzione

To top