Newsgroup: it.comp.os.linux.sys
Titolo: aiuto su script per "megaoperazione"

ciao tutti.
chiedo aiuto al cervello collettivo ICOL per svolegere il seguente 
compito :P
premessa: partendo da una query LDAP ottengo una lista di circa 50.000 
(cinquantamila) UID (mi riferisco alla parte numerica che 
contraddistingue l'utente. Ci siamo capiti, va :P)
Questa lista di numeri conterra' dei buchi (perche' un utente e' stato 
cancellato dal sistema o per 1000 altre ragioni).
Io voglio trovare il piu' basso numero libero, da utilizzare quando creo 
un nuovo utente.
Visto l'elevato numero di dati da elaborare voi come fareste?
-- 
il capitano dei carabinieri chiede a un appuntato: "quanto fa 1+1"
l'appuntato: "3"
I colleghi in coro "gli dia un'altra chance. Gli dia un'altra chance!"
Il capitano ci riprova. Quanto fa "2+1".
l'appuntato: "3"
I colleghi in coro "gli dia un'altra chance, gli dia un'altra chance!"

 non ci vuole un genio..
certamente non ci vuole un genio (infatti la soluzione da te suggerita 
era proprio a portata di mano) e se vuoi te la posso anche correggere su 
un punto :)
ti eri dimenticato il "do" ma questo e' un errore di battitura.
Ci vuole un "break" altrimenti il ciclo 'for' si passa tutti gli "id" 
fino alla fine anche se ne ha gia' incontrato uno mancante, in questo 
modo va un po' meglio per il mio scopo:
#!/bin/bash
expectedid=1
for uid in `cat elencouid`; do
         if [ $uid -gt $expectedid ]
                 then echo "$expectedid mancante"
                 break
         fi ; expectedid=$((expectedid+1))
done
ma e' questa secondo te la soluzione piu' veloce immaginabile, visto che 
devo processare 50mila utenti? (forse si... ma ora quando trovo tempo ci 
penso su un attimo)


 se vuoi che si fermi al primo "buco" che trova.
sono piu' o meno le idee che che ho anche io in mente. D'altra parte i 
colli di bottiglia potrebbero essere anche altri. Ad esempio non so 
quanto sara' veloce ldapsearch.
Grazie!


 penso su un attimo)
un'alternativa è avere un file pregenerato N.TXT con tutti i numeri da 0 
a 50000, ed un file UID.TXT che crei con ldapsearch che contiene la 
lista degli uid utilizzati.
a questo punto se fai un diff fra i 2 file trovi gli uid liberi.
non so quanto possa essere veloce, sarebbe da provare.
ciao
-- 
Ranger!
ranger chiocciol@ 
racine.ra.it

Approccio euristico!! (come se io sapessi cos'e').
Prendi un sottoinsieme dei tuoi numeri (tipo 100) e cerchi l'id
mancante la' dentro.
Se non c'e', prendi un altro sottoinsieme a caso.
Ti puo' sembrare una schifezza (lo e') ma in bioinformatica ci sono
programmi che funzionano cosi' .
In fondo, quante probabilita' ci sono che il sole tramonti questa sera?

Scusa non avevo notato che ti interessava sapere il UID piu' basso.
Puoi comunque tentare un approccio simile, dividi i tuoi ID in gruppi,
indicizzi questi sottoinsiemi e ti salvi il n. di user liberi. Cosi' ad
esempio puoi sapere che nei primi 1000 ID ci sono tot. posti liberi, e
cosi' via....
Ogni volta che aggiungi o rimuovi un user, aggiorni solo l'indice di
quel determinato sottoinsieme.
zvale?

 quel determinato sottoinsieme.
Questo non so ancora se posso farlo (forse si, forse no.
Qualche imbacille potrebbe usare la console java per creare gli utenti e 
bypassare quindi il imo script. In questo caseo gli indici andrebbero 
riaggiornati.



a occhio, questo approccio e' probabilmente piu' veloce dell'altro, 
specialmente nel caso in cui l'ID sia in fondo alla lista.


 Ho capito. L'idea non e' insana :-)
Oppure potresti usare un metodo "scemo" (ti fai tutto il db e trovi quali
sono i posti liberi) ma lo fai una volta sola, salvi gli indici liberi da
qualche parte e d'ora innanzi usi solo questo dato (che verra' aggiornato
di conseguenza) invece di scansire tutte le volte il db.
Ovviamente il gioco vale la candela se
1) Hai tempo per fare una scansione di tutti i possibili posti almeno una
volta (non so quanto ci possa volere, se 2 ore o 2 anni...)
2) I posti liberi sono "relativamente" pochi, sicche' il dato su cui
dovrai lavorare in seguito sia facilmente manipolabile.
-- 
quando un'anima nasconde 
immaginare forse? 
in un fiume di luce 
credere d'inverno

Pero' per me l'approccio migliore rimane sempre quello euristico.
Anche se forse è piu' pratico per calcolare il punto di minimo di una
funzione di 1324o grado in 321 variabili, piuttosto che per gestire un
database.... ;)
p.s. ok sono pazzo.

Mandi! Massimiliano Adamo
  In chel dí si favelave...
MA> Visto l'elevato numero di dati da elaborare voi come fareste?
..io darei una occhiata agli smbldap-tools, che in perl fanno anche
questo. ;)
-- 
  Mentre il cuore d'Italia, da Palermo ad Aosta
  si gonfiava in un coro di vibrante protesta		(F. De Andre`)