Thomas Rasmussen <simpsons@invalid.kom.auc.dk> writes:
>> Der er vist dømt stort "how to shoot oneself in the foot"-
>> potentiale dér
>Well, det er der jo altid når man leder efter scripts til at slette
>filer/dirs, en god vane er at inden man prøver sådan noget at undlade
>-exec rm {}
Snarere bør man tænke på options. Er det kataloger, man vil af
med, er "-type d" en god plan. Personligt ville jeg aldrig vove
mig ud i noget, der involverede "rm -rf". Der er lidt for mange
kedelige fortilfælde.
Personligt ville jeg lave en "find", der endte med at flytte de
ting, der skal slettes, ned i et passende katalog, som så kunne
slettes efterfølgende. Det er væsentligt mere overskueligt og
langt mindre farligt.
Der er masser af herlige ubehageligheder, man kan udsætte sig selv
for med rm. For eksempel "rm -rf $DIR/$TMP" (eller analogt "find
$DIR/$TMP ... -exec rm ..."), hvor man i et øjebliks uopmærksomhed
glemmer at sætte de to variable. Det forekommer mig, at der var en
SunOS 4-patch, der havde tendenser i den retning, men jeg kan ikke
lige finde noget relevant med Google.
Og så den herlige detalje: hard links. Især hvis nogen har været
så ufattelig usmart at gøre det på kataloger (de fleste filsystemer
har efterhånden fundet ud af at nægte den slags). Samme effekt kan
fås med et lettere defekt filsystem, hvor en enkelt inode-refernce
peger et meget forkert sted hen.
Så uanset metode og kriterier: pas nu på. Automagiske ting, der
bruger svært gennemskuelige kriterier til at slette med (det vil
næsten altid inkludere brug af "find"), er altid en risikabel
kombination. Eventuelt kan man blot erstatte "-exec rm" med et
script, der f.eks. har en ide om mængden, der skal slettes. Hvis
man forventer at skulle slette 2-300 filer, men rm en dag bliver
kaldt 200-300.000 gange, er det nok usundt at fortsætte udover de
forventede 300.
Mvh.
Klaus.