[script] dannati nomi con spazi

[RaouL_BennetH]

Originariamente inviato da adarkar
stiamo perdendo la retta via
il compilatore non sta lì a filosofeggiare su di chi è l'asterisco, lui lo vede e fa un puntatore, stoppete

okiz ora è chiaro, thx

[/dev/null]

Originariamente inviato da RaouL_BennetH
:master: spe, il problema non è come lo intendo io, ma il compilatore, come lo intende quando l'operatore si trova al centro?

cioè, se io scrivo char* è diverso che se scrivo *char (correggimi se sbaglio), quindi, se scrivo char * argv, il compilatore a chi "attribuisce" il puntatore?

Uhm...
L'asterisco non e' rifgerito a char o a argv...
E' riferito a tutto l'insieme... Fa capire al compilatore che quella e' un puntatore ad una variabile di tipo char chiamata argv...
Scrivere soltanto char* non avrebbe senso come non lo avrebbe neppure *argv (quest'ultima cosa ha senso, ma fa un altra cosa, non definisce una var..)

[RaouL_BennetH]

a ri-grazie e scusate se vi ho prtato un pò OT. Per sdebitarmi preparo un pò di caffè per tutti voi che, come me, il sabato sera, anzichè essere in discoteca a rimorchiare giovani pulzelle stiamo davanti al piccì a litigare con puntatori, variabili, bash e kernel!!

[adarkar]

Originariamente inviato da /dev/null
Uhm...
L'asterisco non e' rifgerito a char o a argv...
E' riferito a tutto l'insieme... Fa capire al compilatore che quella e' un puntatore ad una variabile di tipo char chiamata argv...
Scrivere soltanto char* non avrebbe senso come non lo avrebbe neppure *argv (quest'ultima cosa ha senso, ma fa un altra cosa, non definisce una var..)

guarda ke in realtà se voglioamo provprio vedere non è tutto l'insieme, ma sono proprio due pezzi
il fatto che noi possiamo giocarlo come vogliamo dipende solo dal fatto che in C ogni blank (spazio tab lf....) vale un nisba

infatti:
in una dichiarazione
char *p1, *p2;
l'asterisco possiamo dire che si riferisce al nome della var in quanto se lo togliamo p2 non è più un puntatore

in un cast
(char*)p1
possiamo dire che l'asterisco si riferisce a char.. anzi è proprio lì, indica che io voglio un puntatore a char

[Sym81]

Originariamente inviato da /dev/null
Cosa c'entra il numero di righe con la migliorezze () del programma?

Prova ad eseguire un programma scritto in python o in qualunque altro linguaggio interpetato su un miliardo di files, e poi fa' lo stesso con uno scritto in C

Ma che discorso è. La chiave, semmai, è la velocità con cui scrivi e la difficoltà del linguaggio. Per fare uno script così in bash ci metti 5 minuti con poche righe di codice...in C...beh si è visto, senza contare il tempo perso per debuggare (magari gestisci male un puntatore e perdi mezz'ora).

[Sym81]

Se il mio script ci mette il triplo del tempo, che mi frega, alt+f2 e passo a fare altro.

[KornShell]

Originariamente inviato da adarkar

[shi@pygo ~/tmp] $ python script.py 
  File "script.py", line 6
    if ' ' in file_name:
    ^
SyntaxError: invalid syntax

devi averlo copiato male, l'ho riprovato e funziona.
controlla l'identazione.

[Ilmalcom]

Originariamente inviato da Sym81
Ma che discorso è. La chiave, semmai, è la velocità con cui scrivi e la difficoltà del linguaggio. Per fare uno script così in bash ci metti 5 minuti con poche righe di codice...in C...beh si è visto, senza contare il tempo perso per debuggare (magari gestisci male un puntatore e perdi mezz'ora).

Quoto in toto. Per questi "giochetti" è molto meglio usare bash scripting o python

[Ikitt]

Originariamente inviato da /dev/null
Cosa c'entra il numero di righe con la migliorezze () del programma?

meno righe -> meno bug

Prova ad eseguire un programma scritto in python o in qualunque altro linguaggio interpetato su un miliardo di files, e poi fa' lo stesso con uno scritto in C

BEEEP, cattivo esempio, e` un compito (quasi sempre) I/O bound, le differenze possono essere "sorprendenti".
Inoltre, nella creazione di script/oneliner e altri strumenti usa-e-getta per l'amministrazione di sistema, la variabile "tempo necessario per la creazione" non e` certo trascurabile

[/dev/null]

Originariamente inviato da Sym81
Ma che discorso è. La chiave, semmai, è la velocità con cui scrivi e la difficoltà del linguaggio. Per fare uno script così in bash ci metti 5 minuti con poche righe di codice...in C...beh si è visto, senza contare il tempo perso per debuggare (magari gestisci male un puntatore e perdi mezz'ora).

Io continuo a non vedere la migliorezza di un programma con la velocita' che ci vuole a scriverlo
Per quanto riguarda il tempo perso per il debugging, secondo me conta piu' l'esperienza che altro... E piu' programmini simili realizzo, meno problemi ottengo di volta in volta...

Originariamente inviato da Sym81
Se il mio script ci mette il triplo del tempo, che mi frega, alt+f2 e passo a fare altro.

Si', ma nel frattempo se giochi i giochi scattano, se compili qualche prog ci mette il doppio etc e facendolo inoltre rallenteresti il programma.
Inoltre se tutti i "programmetti" da shell fossero scritti in linguaggi interpretati credo (ma forse sbaglio ) che si inizierebbero a notare leggeri rallentamenti...

Originariamente inviato da Ikitt
meno righe -> meno bug

D'accordissimo su questo!

BEEEP, cattivo esempio, e` un compito (quasi sempre) I/O bound, le differenze possono essere "sorprendenti".
Inoltre, nella creazione di script/oneliner e altri strumenti usa-e-getta per l'amministrazione di sistema, la variabile "tempo necessario per la creazione" non e` certo trascurabile

Gia', se ogni ciclata impiega 10 nanosecondi ad essere eseguita 8 se li mangiano le system calls...
Io un programma cosi' non lo considero proprio usa e getta... Il programma mio e quello di KornShell credo possano tornare utili a piu' persone... Certo, se devo fare un programmino che apre e chiude il lettore cd ( ) va benissimo uno shellscript, ma per un programma (seppur molto semplice) abbastanza utile e che deve ciclare milioni di volte io preferisco scomodare il mio adorato C










Devo pero' appettere che il python mi ha sorpreso
Oltre ad essere OpenSource ( ) e' il primo linguaggio interpetato che vede che offre la possibilita' di richiamare funzione di basso livello (penso che l'interprete traduca "os.walk" in "chdir", "os.path.join" in "readdir" e "os.rename" in "rename"), lo fanno anche altri?
E per questo temo che sara' mooolto veloce... (anche se un po' meno del corrispettivo in C)

Se quel programma fosse stato fatto con uno shellscript che usa /bin/ls e /bin/mv (etc) per listare e rinominare i files allora si' che ci potrebbe stare delle ore