Newsgroup: it.comp.os.linux.iniziare
Titolo: Programmare in C++ (seconda puntata)

Ci risiamo,
elimino una magagna e ne spunta un'altra...
Allora... dopo aver scoperto che tra main e {} ci volevano le
parentesi tonde ().... dopo aver scoperto che l'installazione completa
(un giga e mezzo) della Mandrake non mi aveva installato le librerie
standard del C++ (in compenso mi aveva installato ben 6 shell
alternative a bash... un vero colpo di genio...)
Ho riprovato a compilare il primo programmino base:
// prova.cpp
#include <iostream.h>
void main() {
   cout << "hello world!\n";
}
usando il comando:
g++ prova.cpp -o prova
che ha funzionato senza problemi, poi ho provato ad eseguirlo
lanciando "prova" dal prompt e mi dice una cosa tipo:
bash: comando sconosciuto
Dove sbaglio ?
Tra le altre cose se faccio "ls -l" vedo il file "prova.cpp" e il file
"prova", guardando i permessi quest'ultimo risulta eseguibile ed e
rappresentato di colore verde e con un asterisco al seguito (prova*).
Cosa significa ?
Datemi una mano raga' .... per favore... ;)
Ciao e Buon Natale a tutti !
--
Midget

 Dove sbaglio ?
./prova
Al

./prova
perche' ?
se sono gia' nella directory dove si trova il file, perche' "prova" da
solo non fa riferimento al file ? perche' ci vuole l'indicazione della
directory ?
Ciao e grazie !
 
--
Midget

 non fa riferimento al file ? perche' ci vuole l'indicazione della directory ?
Perche' la directory . (ovvero la dir corrente) non e' di norma inserita nel
path degli eseguibili (/usr/bin;/usr/local/bin/;...
Al

path degli eseguibili (/usr/bin;/usr/local/bin/;...
Fico.... questa mi e' proprio giunta nuova....
ma c'e' un motivo specifico per cui si comporta cosi' ?
nel dos quando si inserisce un nome, 
command.com
 lo cerca prima tra i
suoi comandi interni, poi nella directory corrente e poi nella path.
Non poteva essere lo stesso ? cosa cambiava ?
Ciao !
--
Midget

Non poteva essere lo stesso ? cosa cambiava ?
Questioni di sicurezza.
Ovviamente DOS by Microcazz cerca la semplicità a scapito della sicurezza,
in linux l'opposto.
Ipotizziamo che tu abbia un file malignamente messo nella dir corrente,
di un utente bastardo, che si chiama "ls", e che sia uno script che
contiene: 
rm -rf /
...
Se fosse come in dos, tu (root curiosone ed irresponsabile) cerchi di
listare quella directory, e fai:
# ls
e sei fottuto perché cancelli tutto il filesystem...
In linux, invece, per default parte 'ls' collocato nel path di bash,
quindi carica quello "giusto".
Se vuoi eseguire quello della directory corrente, devi farlo
volontariamente, richiamandolo come ./ls
ma questo presuppone che almeno tu sappia che è un "ls" anomalo e ci abbia
almeno guardato...
Piccole cose, ma qualche volta ti può salvare da brutte situazioni.
-- 
Crononauta               
==========               | togli 'sse' da ulissebarra | 
ICQ UIN: 4005815         | per rispondermi in  e-mail | 
IDAnet: 
http://adcserver1.biodip.unimi.it/ida/index.htm
GP Legends: 
http://www.multiplayer.it/driving/

Piccole cose, ma qualche volta ti puň salvare da brutte situazioni.
Ok, ho capito la motivazione e hai perfettamente ragione...
Ma se la shell cercasse i comandi nell'ordine:
1 - comandi interni
2 - path
3 - dir corrente
non sarebbe lo stesso ?
Troverebbe prima il comando legale e non ci sarebbero problemi, no ?
Ciao !
--
Midget

directory ?
i soliti motivi di sicurezza.
puoi mettere . nel path (ed in quel caso lanciando direttamente un
programma questo parte) ma tradizionalmente viene considerata cosa
molto molto pericolosa.
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
    I bimbi buoni vanno in paradiso.
    I bimbi cattivi vanno dove gli pare!

Non poteva essere lo stesso ? cosa cambiava ?
La sicurezza.
Nessuno ti puo' sostituire il comando ls con uno scherzone dannoso,
senza che tu te ne accorga.
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

Troverebbe prima il comando legale e non ci sarebbero problemi, no ?
Mhh, allora, a me è parso di notare che quando passo a root dopo aver
loggato come utente, anche da root mi mantiene il path dell'utente...
Così p.e. se loggo come root, tutto ciò che sta in /sbin lo posso
richiamare direttamente.
Da utente, o root da utente, devo specificare /sbin/<nome>.
Per evitare di fare casino... con ./<file> sono sicuro di avviare quello
nella dir corrente.
Viceversa, magari, sono convinto che con 
# ls
parta /bin/ls, ma ho fatto casino coi path, non trova /bin/ls perché non
è sul mio path, e invece faccio partire
./ls
che contiene il famoso rm -rf /
...
Mica bello!
Dovendo specificare ./file ti accerti che la volontà sia proprio quella di
far partire l'eseguibile della directory corrente.


loggato come utente, anche da root mi mantiene il path dell'utente...
e questo che senso ha ?
se sei 'utente' dovrebbe avere la path da 'utente', mentre se sei
'root' dovrebbe avere la path da 'root'.... che gli frega a lui se ti
sei loggato root con 'su' o direttamente ??? se hai una certa
identita' dovresti averne tutti i limiti e i privilegi, no ?
cosi' se 'utente' non ha i permessi per /bin/ls e' inutile che cerchi
di guardare il contenuto della directory con 'ls' perche' non
funzionerebbe e al massimo lancerebbe il famoso 'ls' maligno (e allora
e' bischero l'utente...)
invece dopo aver fatto 'su' dovrebbe essere considerato root a tutti
gli effetti e trovare prima /bin/ls.... 
Ciao Ciao !!
--
Midget

e questo che senso ha ?
Adesso mi chiedi troppo =:-O
Allora dovremmo pure chiederci perché wincaz s'impalla e fa cagare,
insomma stiamo entrando nei perché dell'universo!!!
;-)


Troverebbe prima il comando legale e non ci sarebbero problemi, no ?
Infatti puoi farlo se vuoi. Aggiungi "./" **alla fine** del tuo path.
I comandi interni vanno sempre per primi, e l'altra roba segue l'ordine
del path. Se per *ultimo* nel path c'e` "./" , la dir corrente, i
comandi che si trovano li` avranno la priorita` piu` bassa.
-- 
    Pardo 
 
www.pardo.cjb.net

identita' dovresti averne tutti i limiti e i privilegi, no ?
dipende, per far agire su esattamente come da login devi passargli -l,
altrimenti si limita a cambiare i privilegi e non ricarica i vari
.bashrc in /root ecc...


;-)
Si fa per fare due chiacchere..... ;-)
Ciao e Buon Natale !
--
Midget

Cosa significa ?
Che e' eseguibile, per l'appunto :-)
-- 
Renato "Lay-up" Salzano - 
http://members.xoom.it/hitman_work/
 
e-posta: sonicblast (at) 
inwind.it
 / Xena:TWP fan
Band musicale consigliata della settimana: Queen Adreena
-- Webdesigner & sysadmin di 
http://www.italservicesnc.it
 --

Troverebbe prima il comando legale e non ci sarebbero problemi, no ?
Si, tranne il caso che evidenzio sopra.


 'root' dovrebbe avere la path da 'root'.... che gli frega a lui se ti
Ha senso. Invece di "su" basta scrivere "su -" .
-- 
* Jotaro Kujo *
 Can't you see the end
 Twentieth Century Man ? 

 dipende, per far agire su esattamente come da login devi passargli -l,
Dipende... nella slack cosi'  non va. Vuole solo "-" , senza "l".


Dipende... nella slack cosi'  non va. Vuole solo "-" , senza "l".
per su "-"  "-l" e "--login" dovrebbero essere sinonimi afaik, almeno
nella mia versione delle binutils.
ok che "-" e' piu' compatto... ^____^
