Newsgroup: it.comp.os.linux.iniziare
Titolo: Re: Script per spostamento automatico files?


fai un file tipo:
vi /root/plutomove.sh
mv /casadipippoepluto/* /portineria/
gli dai chmod +x plutomove.sh
e poi apri in cron la entry:
vi /etc/crontab
* * * * * /root/plutomove.sh
dai un
crontab /etc/crontab
e ogni minuto ti fa il move. oppure, se puoi è meglio, fai così:
10,20,30,40,50,00 * * * * /root/plutomove.sh
e ti fa ogni 10 minuti il controllo.
ciao.

 fai un file tipo:
Non vedo l'articolo dell'OP, quindi rispondo agganciandomi al tuo.
Per un monitoraggio *istantaneo* del fs, la parolina magica è: inotify.
La bacchetta magica è incrond.
Leggere, studiare, imparare, vivere: ;)
http://www.linux-magazine.it/La-vita-dei-file-in-un-sistema-GNU-Linux-pag_1.htm
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 crontab /etc/crontab
I file crontab non dovrebbere essere mai manipolati direttamente; il modo 
giusto per fare questo è:
crontab -e
man 1 crontab

 crontab -e
Attento, così facendo modifichi il crontab *utente*, che non è quello di
sistema in /etc/crontab. Se sei root, crei un crontab di *root*, che
funzionalmente può anche fare lo stesso lavoro del crontab di sistema,
ma non è la stessa cosa.
Quanto a /etc/crontab, io l'ho sempre fatto rileggere con un:
killall -HUP cron
(o crond, dipende dalle distribuzioni) :-)
-- 
Massimo Bacilieri AKA Crononauta

 sistema in /etc/crontab.
  Dipende, certe implementazioni di cron non ne prevedono l'esistenza.
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 (o crond, dipende dalle distribuzioni) :-)
Se non sbaglio, cron rilegge automaticamente i file senza bisogno di 
mandargli segnali (per lo meno Vixie cron).
-- 
Cio' che si vede, e'.

 giusto per fare questo è:
sono anni che manipolo crontab senza alcun problema. non ci vedo grandi 
controindicazioni...

 controindicazioni...
Infatti.
/etc/crontab si è da sempre manipolato a mano con vi, vim, pico, nano o
chi per essi.
Quello che non va fatto è andare a pasticciare i file di cron *utente*
che si trovano in /var/spool/cron/crontabs, e che vanno tassativamente
modificati con crontab -e.
Un'alternativa, che fa la stessa cosa in modo appena più complicato, è fare:
crontab -l > crontab.txt
modificarsi a piacere il file crontab.txt e poi ricaricarselo con:
crontab crontab.txt
Non che ci si guadagni molto, ma è un'alternativa.


 modificati con crontab -e.
mai toccato i cron utente, non ne ho mai avuto bisogno. difatti 
consigliavo uno script "di sistema" inserito in /etc/crontab
;)
ciao.

 (o crond, dipende dalle distribuzioni) :-)
Ecco, questo è la cosa giusta da fare.
Ti faccio presente che per le versioni in cui c'è /etc/crontab
il comando:
# cron /etc/crontab
non fa altro che verificare /etc/crontab ed installarlo come
/var/spool/cron/root (o come cavolo si chiama nella distribuzione)

 mandargli segnali (per lo meno Vixie cron).
Anche in questo caso è meglio usare crontab perché o killall -HGUP cron
poiché così si effettua un   controllo sintattico sulla crontab.

 consigliavo uno script "di sistema" inserito in /etc/crontab
Anche se Crononauta ha ragione però tu usavi implicitamente la 
crontab personale dell'utente root dando il comando
crontab /etc/crontab
Nota bene questo dipende dalla versione di cron che stai usando
per cui meglio controllare i manuali.

 cartella un istante prima vuota, muova gli stessi in un'altra di mia
]zac[
A occhio le soluzione sono due, uno script in crontab che ogni tot tempo 
faccia l'operazione, o programmi/script che usino inotify.