On Tuesday 19 April 2005 09:41, Gr�goire M�tral wrote:
> Je ne sais pas si l'un est plus s�r que l'autre. Mais l�, en
> l'occurrence, on rend toto propri�taire de tous les documents, y compris
> ceux qu'il n'a pas forc�ment cr��s... Bref, on �crase des infos, alors
> que la solution propos�e par F�lix permet de ne faire que les modifs
> n�cessaires au changement d'uid.
Oui, mais comme j'ai tendance a ne pas avoir de fichiers "etrangers" dans ma
structure 'home'... :-)
A part ca, le veritable danger ne vient pas d'une faute de frappe en tapant
'/' au lieu de '/home/toto', mais plutot de l'utilisation lors de
l'utilisation de variables dans un programme bash. Par exemple :
nrwdir=/home/toto
...
cd ${newdir}
find . -name .. -exec ...
La variable 'newdir' est 'vide' et le cd s'effectuera dans le ${HOME}
directory. En general, on arrive assez bien a se premunir lorsque l'on tape
des commandes dangereuses au clavier. Par contre, ce genre d'erreur ci-dessus
peut-etre beaucoup plus frequent lorsque l'on ecrit des scripts bash. Or, ce
genre d'erreur peut s'averer devastateur car, contrairement a une commande
intercative, elle porte sur des volumes beaucoup plus gros. Et c'est aussi
une erreur de PATH qui est a l'origine de ces mails... c'est donc la que l'on
commet le plus d'erreur; et plus rarement en utilisant une commande plutot
qu'une autre.
Il existe aussi des systemes qui ne disposent pas des commandes GNU en
standard, mais simplement des versions AT&T. Ce qui fait que, sur ces
systemes, la commande s'ecrit :
find /home/toto -user titi -exec chown toto {} \;
:-)
dc
_______________________________________________
gull mailing list
[email protected]
http://lists.alphanet.ch/mailman/listinfo/gull
