DidaWiki

Questa pagina è in sola lettura. Puoi visualizzare il sorgente, ma non puoi modificarlo. Contatta l'amministratore se pensi che ci sia un errore.
 ====== FAQ ======
Ossia //Frequently Asked Questions//.







                                                                    
                                             
===== Come posso collegarmi in modo sicuro ad una macchina remota? =====

Su sistemi basati su Unix è disponibile il client SSH che permette di collegarsi in modo sicuro ad una macchina remota su cui abbiamo un account. (Se si utilizza Windows è possible utilizzare il programma Putty, il cui eseguibile e la cui documentazione è disponibile [[http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html|qui]]).
 
Una volta aperta la shell è sufficiente digitare il seguente comando:
<code>
bash(utente_locale):$ ssh utente@nome_simbolico_o_ip_macchina_remota
</code>
e vi verrà richiesta la vostra password per l'utente sulla macchina remota a cui state cercando di collegarvi. 

===== Come posso collegarmi al centro di calcolo da casa? =====

Potete collegarvi al server olivia.cli.di.unipi.it (o a qualsiasi altra macchina del CDC didattica). Usando le vostre credenziali presso il centro di calcolo avrete accesso alla vostra home directory. Ecco come deve fare l'utente rossi a collegarsi al cdc, su olivia:
<code>
bash(utente_locale):$ ssh rossi@olivia.cli.di.unipi.it
Password:la password di rossi
</code>
Una volta loggati con successo potete lavorare nella vostra home come fareste se foste loggati ad una macchina dei laboratori, e quindi avendo a disposizione tutti i programmi che vi necessitano: compilatore, debugger, e gli altri tool visti a lezione.
Per utilizzare la bash vedere questa [[informatica:sol:laboratorio13:faq#come_faccio_ad_utilizzare_la_bash_se_la_mia_shell_di_default_e_la_cshtcsh|Faq]].
Quando ci si vuole scollegare dalla macchina remota, digitare il comando (sempre nella shell remota):
<code>
bash(rossi):$  logout
</code>

===== Posso utilizzare i programmi remoti dotati di interfaccia grafica? =====

Sì, ad esempio potreste aver bisogno di utilizzare ddd, o un editor di testo grafico per scrivere i vostri programmi. Per visualizzare l'interfaccia sul vostro display, occorre che vi colleghiate alla macchina usando il comando ssh con opzione -X
<code>
bash(utente_locale):$ ssh -X rossi@olivia.cli.di.unipi.it
Password:la password di rossi
</code>
Dopodichè potete lanciare i vostri programmi da shell nel modo usuale.

===== Posso collegarmi alle macchine dei laboratori del centro di calcolo? =====

Sì, come alla macchina olivia potete collegarvi a qualsiasi macchina del centro di calcolo. Ma è necessario che la macchina sia accesa e vi sia in esecuzione linux, ed in particolare il server ssh. Ricordatevi di impostare i permessi della vostra home directory nel modo opportuno come descritto nella [[informatica:sol:laboratorio13:faq#come_posso_proteggere_i_miei_file_in_modo_che_non_siano_leggibili_dagli_altri_gruppi|Faq]].

===== Come posso trasferire files da e verso una macchina remota? =====

Spesso potreste aver bisogno di trasferire file che avete, ad esempio, sulle vostre macchine a casa o sul portatile, verso la vostra home del cdc. A questo scopo potete utilizzare il programa scp:
<code>
bash(utente_locale):$ scp file_locale1....file_localeN rossi@olivia.cli.di.unipi.it:./DIRECTORY_REMOTA
</code>
Per copiare un intera directory (e tutte le sue sottodirectory) usare l'opzione -r
<code>
bash(utente_locale):$ scp -r DIRECTORY rossi@olivia.cli.di.unipi.it:./DIRECTORY_REMOTA
</code>

Allo stesso modo è possibile trasferire i file che avete nella vostra home directory remota verso la vostra macchina locale, basta invertire i parametri:
<code>
bash(utente_locale):$ scp rossi@olivia.cli.di.unipi.it:./DIRECTORY_REMOTA/file_remoto1 ... rossi@olivia.cli.di.unipi.it:./DIRECTORY_REMOTA/file_remotoN DIRECTORY_LOCALE
</code>







===== E' possibile accedere al numero di linea in C ? =====
Si, e' possibile utilizzando la macro 
<code>
__LINE__
</code>
===== FRAM3: e' possibile modificare i file .h del primo frammento ? =====
Si, e' possibile aggiungere campi alle strutture e prototipi nei file .h del primo frammento estendendo la libreria a patto che continuino a funzionare i test del primo frammento.

===== FRAM2: e' possibile creare file temporanei ? =====
Si, a patto che i file vengano creati in una directory adeguata (esempio ''/tmp''), senza sovrascrivere file esistenti e rimossi a fine script (suggerimento: provate ''man mktemp'')




===== FRAM1: Devo invocare perror() dentro le funzioni di libreria ? =====
No, seguendo la convenzione delle funzioni di libreria C gli errori devono essere riportati con un opportuno codice di ritorno ed eventualmente settando ''errno''. Sara' chi invoca la funzione che invochera` anche ''perror()'' se lo ritiene opportuno.

===== FRAM1: Quali valori possono essere assegnati a ''errno'' ? =====
''errno'' puo' contenere solo 0 oppure valori definiti dallo standard, vedi
<code>
man errno
</code>
altrimenti l'output di ''perror()'' e' non significativo.

===== Problemi con bashdb =====
Usando una distribuzione Linux recente (ad esempio Ubuntu 8.04, 8.10, o comunque distribuzioni che forniscaono bash in versione 3.2 o superiore) lo script di debugging //bashdb// non funziona. Fortunatamente le stesse distribuzioni forniscono lo script gia` pacchettizzato in una versione aggiornata. Ad esempio, per installarlo sotto Ubuntu o Debian basta dare il comando
<code>
sudo aptitude install bashdb
</code>
quindi lanciarlo normalmente con
<code>
bashdb nome_script
</code>
(vedete anche man bashdb e l'help che ottenete digitando "h" al suo prompt).

===== Debuggare programmi con piu` processi/thread =====
E` possibile usare GDB per debuggare programmi multiprocesso / multithread come indicato nella documentazione [[http://sourceware.org/gdb/current/onlinedocs/gdb/Threads.html#Threads|qui]] e [[http://sourceware.org/gdb/current/onlinedocs/gdb/Attach.html#Attach|qui]].
 E` possibile usare i comandi indicati anche in DDD, scrivendoli manualmente nel prompt del GDB in basso nella schermata.

===== Uso di GDB da emacs =====

E' possibile usare il debugger GDB da emacs. Questo permette di seguire interattivamente il flusso di esecuzione in due sottofinestre dell'editor.
Per attivarlo:
  * aprire emacs
  * invocare GDB con ''ESC-X gdb'' e fornendo il nome dell'eseguibile da debuggare (a questo punto si attiva una finestra GDB in cui e' possibile fornire gli usuali comandi)
  * settare opputuni breakpoint e richiedere run (a questo punto emacs si divide in due sottofinestre: nella finestra superiore si interegisce con GDB e nella inferiore viene mostrato il codice attualemente in esecuzione)
 

===== Perche` mtrace mostra una stringa esadecimale al posto del nome del file? =====
R: Questa situazione si puo` verificare per tre ragioni differenti:
  - il file al quale mtrace vorrebbe fare riferimento e` stato compilato senza opzione di debug (''-g'');
  - il file al quale mtrace vorrebbe fare riferimento e` stato compilato con il compilatore c++ (''g++'');
  - il file al quale mtrace vorrebbe fare riferimento e` una libreria presente sul sistema (''libc'', ''libm''...).

Quest'ultima situazione si verifica nel caso in cui siano state usate funzioni di libreria all'interno delle quali viene allocata della memoria (come la ''strdup()''). La memoria, anche se allocata da funzioni di libreria, deve essere **sempre** liberata usando una ''free()''.
<code c>
char *p;
char s[6] = "pippo";

p = strdup(s);
/* ... */
free(p);
</code>

===== Ho la quota disco piena e non riesco a salvare i miei files =====
R: Molto probabilmente la causa di buona parte dei problemi di quota e` dovuta all'utilizzo di eclipse come ambiente di sviluppo.
la prima cosa da fare e` vedere quanto spazio e` utilizzato inutilmente da eclipse.
(si assume che l'utente lavori nella directory workspace)
<code>
(susanna):==>du -sh ~/workspace/.metadata
12.4M   /home/susanna/workspace/.metadata
</code>
a questo punto si puo` procedere con l'eliminazione.
**ATTENZIONE**: state attenti ad inserire questo comando //esattamente// cosi`,
altrimenti rischiate di cancellare tutti i vostri files
<code>
(susanna):==>rm -fr ~/workspace/.metadata
</code>

**Oppure**

Si puo' cancellare la cache di Mozilla mediante l' utilizzo dello script [[http://www.cli.di.unipi.it/~bartolin/rimuovicache.sh|rimuovicache.sh]] fornito dai docenti:
<code>
(susanna):==> wget http://www.cli.di.unipi.it/~bartolin/rimuovicache.sh
(susanna):==> chmod +x rimuovicache.sh
(susanna):==> ./rimuovicache.sh
</code>
Oppure:
<code>
(susanna):==> ./rimuovicache.sh --help 
</code>
Per un mostrare le opzioni dello script.

===== Perche' non fa loggare piu' tramite interfaccia grafica? =====

R: Molto probabilmente e' stata raggiunta la quota disco. 
Per risolvere il problema e' sufficiente digitare [CTL+ALT+F1], effettuare il login in modo testuale e seguire i passi della FAQ **"ho la quota disco piena e non riesco a salvare i miei files"**.

===== Come faccio ad utilizzare la bash se la mia shell di default e' la csh/tcsh? =====
R: Per ragioni "storiche" il CDC usa la csh/tcsh come shell default di login e non permette di cambiarla. Nel prossimo futuro verra' effettuato un adeguamento allo standard di fatto attuale fornendo la bash come shell di login e permettendo a chi non ce l'ha di sceglierla.
Per sperimentare con la shell bash basta digitare
<code>
(susanna):==> bash
bash-2.05b$
</code>
oppure
<code>
(susanna):==> exec bash
bash-2.05b$
</code>
in entrambi i casi la vostra shell mandera' in esecuzione una bash con cui potrete interagire. Alla fine potete uscire con
<code>
bash-2.05b$ exit
exit
(susanna):==>
</code>
oppure EOF (CTRL-D).

Per non avere un ambiente "nudo" si consiglia di salvare i seguanti script di configurazione (esattamente con questi nomi) nella vostra home directory (ad esempio, ~susanna/ per l'utente susanna):

[[http://www.di.unipi.it/~susanna/LCS/.bashrc|.bashrc]]
[[http://www.di.unipi.it/~susanna/LCS/.bash_profile|.bash_profile]]
[[http://www.di.unipi.it/~susanna/LCS/.bash_aliases|.bash_aliases]]

In questo modo otterrete un prompt piu' significativo e un ambiente piu` gradevole:
<code>
(susanna):==> bash
susanna@aulaa:~$
</code>
In particolare aggiungendo ulteriori comandi di alias al terzo script potete personalizzare la shell creandovi i vostri alias usuali per i vari comandi (es, "rm -i" per "rm", o "h" per "history").

//NOTA BENE: I sistemisti **sconsigliano vivamente** di mettere il comando ''exec bash'' direttamente nei file .login o .cshrc perche' questo potrebbe interferire negativamente con altri settaggi standard dei vostri ambienti, in particolare quello grafico.//

===== Ho provato ad eseguire il programma digitando a.out =====
**nella directory che lo contiene ma il risultato e' stato**
<code>
bash: a.out command not found
</code>
R: La variabile di ambiente ambiente PATH non contiene la directory corrente ("."): per eseguire il programma basta fornire il parth name completo dell'eseguibile, ad esempio quello relativo:
<code>
$ ./a.out
</code>
Per risolvere il problema si deve aggiungere la directory corrente alla variabile PATH della shell, nella bash basta dare il comando:
<code>
$ export PATH=$PATH:. 
</code>
o nella csh/tcsh
<code>
% setenv PATH ${PATH}:.
</code>
Per vedere il valore del PATH
<code>
$ echo $PATH
</code>
per capire che shell stiamo utilizzando
<code>
$ echo $SHELL
</code>
Per non dover ripetere il comando export/setenv ogni volta che aprite una finestra dovrebbe essere sufficiente aggiungere il comando come una riga dello script ~/.bashrc (bash) o ~/.cshrc (csh/tcsh).

===== Come posso ottenere informazioni in linea sulle funzioni di libreria C? =====
R: Usando le sezioni 2 e 3 dei manuali, rispettivamente per system calls e funzioni di libreria, ad esempio
<code>
$ man 2 read
$ man 3 printf
</code>

===== Come posso proteggere i miei file in modo che non siano leggibili dagli altri gruppi? =====
R:  Basta fissare un nome di directory noto solo agli utenti del gruppo (es //56yu897j//) e proteggere in lettura la directory che la contiene in modo che solo chi ne conosce il nome possa accedervi. Ad esempio
<code>
$ chmod 711 ~                    (*tolgo i diritti di lettura della mia home a tutti eccetto me*)
$ ls -ld ~
drwx--x--x    8 susanna     user          672 2005-04-12 16:48 /home/susanna/
$ mkdir ~/56yu897j               (*creo la directory segreta*)
</code>
Adesso per gli altri utenti e' impossibile fare ls sulla mia home directory es:
<code>
$ echo $USER           (* sono l'utente garibaldi*)
garibaldi
$ ls ~susanna
ls: /home/susanna/: Permission denied
</code>
Pero' posso ancora accedere alla directory 56yu897j se ne conosco il nome
<code>
$ echo $USER           (* sono l'utente garibaldi*)
garibaldi
$ ls ~susanna/56yu897j
prorub/
</code>

===== Ho dei Segmentation Fault quando invoco funzioni di libreria tipo free(), getenv(), etc...  =====
R: Questo e' un tipico sintomo di errori nell'allocazione delle stringhe (spazio insufficiente), buffer overrun (come effetto spesso di strcpy() o di altre funzioni che assumono di lavorare su stringhe terminate correttamente se invocate su stringhe senza terminatore), oppure di errata gestione e copia dei puntatori. 

Quindi la manifestazione spesso non ha niente a che vedere con il punto in cui si e' verificato l'errore vero e proprio.

In questo caso la cosa da fare e' ricontrollare incrementalmente tutto il codice (magari con l'aiuto di un debugger) alla ricerca di possibili malfunzionamenti su stringhe e puntatori.

===== Come indento il mio codice con un buon stile? =====
R: E' possibile usare il comando //indent// (vedi la sua pagina di manuale per tutte le opzioni) per indentare automaticamente il codice: una buona linea di comando e'
<code>
indent -kr -br -brs file.c
</code>


Su Vim l'indentazione puo' essere fatta tramite il comando =

===== Come si effettua il testing del codice? =====
R: Molto brevemente: il testing del codice non va confuso con il debugging (ovvero la ricerca dell'errore in un programma che si ritiene sbagliato). Infatti nel testing si cerca di mettere sotto pressione un codice in principio corretto in modo da evidenziare tempestivamente possibili malfunzionamenti.

E' buona norma testare sistematicamente i vari aspetti delle funzioni man mano che queste vengono sviluppate. In particolare e' una buona idea sviluppare, parallelamente al codice, un programma di test che stressa i punti importanti e controlla automaticamente che i risultati siano corretti.

In particolare, e' una PESSIMA idea iniziare a testare il codice dopo averne scritta gran parte. Il testing deve essere fatto incrementalmente su ogni funzione sviluppata. Questo permette di trovare piu' semplicemente gli errori perche' e' possibile concentrarsi su porzioni piu' piccole e ben definite del programma.

E' anche una buona norma raccogliere tutti i test che verificano le varie funzioni in modo da ripeterli automaticamente (con opportuni script) ogni volta che il codice viene modificato per fissare un nuovo bug o aggiungere nuove funzionalita' su una funzione gia' testata.

In rete esistono librerie che aiutano ad organizzare i test (vedi ad esempio [[http://cunit.sourceforge.net/|C unit]] e [[http://www.cs.ucr.edu/~phf/tut/gcov-tutorial.pdf|gcov]] o //man gcov// per controllare quale parte del codice e' stata testata e quale no). Per una trattazione piu' dettagliata ma introduttiva vedi ad esempio Kerninghan & Pike capitolo 6.

===== Quali sono le informazioni che devono essere incluse nella relazione? Come possiamo strutturarle? =====
R: Una possibile struttura della relazione e' la seguente:
  - Introduzione: deve essere una descrizione ad alto livello del progetto, rivolta ad un lettore che non sappia di cosa si tratti. Deve tracciare a grandi linee il quadro complessivo, delineando le parti giocate da quanto descritto nelle sezioni successive
    * struttura complessiva dell'implementazione
    * principali idee guida
  - Strutture Dati: le principali strutture dati utilizzate per realizzare il progetto, si puo' fare anche un elenco puntato indicando come sono strutturate, le motivazioni della scelta, il file di header in cui sono dichiarate e quanto altro sembra opportuno
  - Struttura del server: descrizione dettagliata della struttura del server con la descrizione delle fasi principali di elaborazione, facendo riferimento alle SD gia' descritte senza introdurle di nuovo. Ovviamente va dato piu' spazio ai punti critici rispetto a parti ovvie
  - Struttura del client: come server
  - Appendice
    * Guida per l'utente
      * Compilazione
      * Installazione
      * Esecuzione/terminazione del server
      * Esecuzione/Terminazione del client
      * Eventuali vincoli
  - Problemi/bug noti (se ce ne sono :-))



===== Come mai la accept non funziona ? =====
R: Su alcune architetture la accept() va invocata con 
<code c>
struct sockaddr_un addr;
int ret;
socklen_t x2 = sizeof (addr);
ret = accept(s, (struct sockaddr *)&addr, &x2);
</code>
invece che passando il secondo argomento NULL.