Newsgroup: it.comp.os.linux.iniziare
Titolo: Compilare hello world

Ciao a tutti,
ho qualche problema con gcc: non riesco a compilare neanche "hello world"!
Uso una debian  3.0 e sembra che tutto funzioni alla perfezione: se ci sono
errori nel codice il compilatore li individua correttamente. Se non ci sono
errori si comporta come se tutto fosse andato a buon fine, viene creato il
file "a.out" o altri nomi se li imposto con l'opzione -o ma poi quei
programmi non partono ("bash: a.out: command not found")!
Ho pensato che potesse essere un problema di diritti cosě ho provato un
chmod 777 a.out, ma niente:
# ls -l
- r w x r w x r w x    1    root    root    4798 Jun    2 16:09 a.out
Qualcuno ha qualche idea?
Grazie
Luca

 Qualcuno ha qualche idea?
Ma come provi ad avviare l'eseguibile che hai appena creato?
Con ./a.out ?
Saluti
-- 
Il reggiseno e' uno strumento democratico perche' separa la destra dalla
sinistra, solleva le masse e attira i popoli.
www.debianizzati.org
  | Founder Member
Mario "Ldonesty" Di Nitto --- [Linux Registered User #334335]

 Saluti
Grazie mille!



Perchè nonostante sia un binario e abbia i permessi per essere eseguito,
non fa parte degli eseguibili riconosciuti dal sistema (intendo i vari
tar, zip etc) 
La cosa si può ovviare aggiungendo la directory corrente, (ovvero .), al
path, ma questa modifica (se non ricordo male) ha qualche problemino
di sicurezza).
Perciò si usa la sintassi ./NOME per eseguire uno script o un binario.


 corrente.
Esatto! come ho provato a spiegare io...  ma forse era poco chiaro :)


minix.

Posso permettermi di chiederti perché devono essere lanciati in questo modo?
Perche su Linux (a differenza di Windows) di default la directory
corrente non è parte di PATH, ovvero dei percorsi in cui vengono
lanciati gli eseguibili.
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

Tutto chiaro, grazie!

 di linguaggio, ci vuole :)
Hehhe... in realtà avevo intenzione di spiegarlo in modo semplice,
o per lo meno ci ho provato.. che poi non ci sia riuscito.. beh è un
altro discorso... :P
/me prima o poi deve tornare a sQuola ... :D


 di sicurezza).
In particolare, come potrebbe esser sfruttata una cosa del genere?
Sempre che la spiegazione non sia troppo complicata :-)
ByeZ
Simone 

 In particolare, come potrebbe esser sfruttata una cosa del genere?
Io ti mando un file "antani.zip" al cui interno c'e' un file di nome rm.
Ovviamente questo rm e' una roba orrenda, che e' meglio non dire cosa fa
che siamo in fascia protetta.
Ora, tu apri lo zip, vedi "rm" e dici "bella schifezza, io volevo il
pr0n", quindi decidi di dare un bel
$ rm rm
e rischi quindi di eseguire il file malizioso.
Esempio brutto, ma immagino che renda.


Ahahaha simpatico esempio, mi è piaciuto :-)
Grazie della delucidazione, Jack :)
Simone

 Esempio brutto, ma immagino che renda.


 e rischi quindi di eseguire il file malizioso.
mmm
se e' solo questo il problema (cioe' creare eseguibili malevoli con lo
stesso nome di altri piu' comuni) non basterebbe mettere "." in fondo alla
variabile PATH?
A quanto ricordo la shell cerca i programmi in modo ordinato, quindi se
PATH="/bin:/usr/bin/:/usr/local/bin/:."
(l'ho un po' semplificato, ma dovrebbe andar bene cosi')
prima provera' /bin/rm, poi /usr/bin/rm .... poi, infine, se proprio non
esiste 'sto eseguibile, ./rm
Quindi, nell' esempio tuo, il cattivissimo rm verrebbe cancellato, no?
O c' e' qualcosa che non torna?
-- 
28/2/2005 | -1 all' alba!

 Quindi, nell' esempio tuo, il cattivissimo rm verrebbe cancellato, no?
Esatto. Era un esempio "brutto" proprio per questo.
Pero' mai sottovalutare la potenza di un niubbo :D
(windows usa la directory corrente come primo o ultimo posto dove
guardare? Boh)


guardare? Boh)
Directory corrente come primo.
