Jean-Louis Liagre wrote in message <4250a2e2$0$28521$:
Parce que ça finit par faire croire aux utilisateurs que "rm" demande toujours une confirmation et c'est pas une bonne habitude
Oui mais non, ça c'est une raison pour ne pas le mettre dans une config par défaut commune à plusieurs utilisateurs, pas pour ne pas le mettre en connaissance de cause dans sa propre config.
PS : attention aux lignes kilométriques.
Jean-Louis Liagre wrote in message
<4250a2e2$0$28521$626a14ce@news.free.fr>:
Parce que ça finit par faire croire aux utilisateurs que "rm" demande
toujours une confirmation et c'est pas une bonne habitude
Oui mais non, ça c'est une raison pour ne pas le mettre dans une config par
défaut commune à plusieurs utilisateurs, pas pour ne pas le mettre en
connaissance de cause dans sa propre config.
Jean-Louis Liagre wrote in message <4250a2e2$0$28521$:
Parce que ça finit par faire croire aux utilisateurs que "rm" demande toujours une confirmation et c'est pas une bonne habitude
Oui mais non, ça c'est une raison pour ne pas le mettre dans une config par défaut commune à plusieurs utilisateurs, pas pour ne pas le mettre en connaissance de cause dans sa propre config.
PS : attention aux lignes kilométriques.
Jean-Louis Liagre
Nicolas George wrote:
Jean-Louis Liagre wrote in message <4250a2e2$0$28521$:
Parce que ça finit par faire croire aux utilisateurs que "rm" demande toujours une confirmation et c'est pas une bonne habitude
Oui mais non, ça c'est une raison pour ne pas le mettre dans une config par défaut commune à plusieurs utilisateurs, pas pour ne pas le mettre en connaissance de cause dans sa propre config.
Ca se discute, on finit quand meme par se faire avoir sur une machine que l'on croit avoir configuré, mais non :-(
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix, et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit non chargée ...
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<4250a2e2$0$28521$626a14ce@news.free.fr>:
Parce que ça finit par faire croire aux utilisateurs que "rm" demande
toujours une confirmation et c'est pas une bonne habitude
Oui mais non, ça c'est une raison pour ne pas le mettre dans une config par
défaut commune à plusieurs utilisateurs, pas pour ne pas le mettre en
connaissance de cause dans sa propre config.
Ca se discute, on finit quand meme par se faire avoir sur une machine que
l'on croit avoir configuré, mais non :-(
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix,
et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit
non chargée ...
Jean-Louis Liagre wrote in message <4250a2e2$0$28521$:
Parce que ça finit par faire croire aux utilisateurs que "rm" demande toujours une confirmation et c'est pas une bonne habitude
Oui mais non, ça c'est une raison pour ne pas le mettre dans une config par défaut commune à plusieurs utilisateurs, pas pour ne pas le mettre en connaissance de cause dans sa propre config.
Ca se discute, on finit quand meme par se faire avoir sur une machine que l'on croit avoir configuré, mais non :-(
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix, et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit non chargée ...
Penguin_X
Jean-Louis Liagre wrote:
Nicolas George wrote:
Jean-Louis Liagre wrote in message <42507887$0$13638$:
C'est pas une bonne idée ...
À part la mauvaise idée qui consiste à utiliser bash, j'aimerais savoir quelle raison à ça.
Parce que ça finit par faire croire aux utilisateurs que "rm" demande toujours une confirmation et c'est pas une bonne habitude car un jour, ils se retrouvent sur un système normal (c'est à dire respectant le standard), ils lancent un petit "rm *" pour effacer quelques fichiers seulement, et voilà comment on perd des heures/jours/mois de travail ...
J'ai toujours trouvé cet alias une fausse bonne idée.
Si on veut une commande de ce type, il faut lui donner un autre nom (ex: rmi, del, ...)
-jll 100 % d'accord. J'ai perdu deux mois de travail en frappant sans faire
exprès rm / (mon rm avait l'alias -rf). Alors j'ai mit un alias a bash rdel(real delete).
-- #include <iostream> #include <string>
int main(){ string myFavoriteOS = "Unix"; cout << "My favorite OS is " << myFavoriteOS << end; return 0; }
Jean-Louis Liagre wrote:
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<42507887$0$13638$636a15ce@news.free.fr>:
C'est pas une bonne idée ...
À part la mauvaise idée qui consiste à utiliser bash, j'aimerais savoir
quelle raison à ça.
Parce que ça finit par faire croire aux utilisateurs que "rm" demande
toujours une confirmation et c'est pas une bonne habitude car un jour,
ils se retrouvent sur un système normal (c'est à dire respectant le
standard), ils lancent un petit "rm *" pour effacer quelques fichiers
seulement, et voilà comment on perd des heures/jours/mois de travail ...
J'ai toujours trouvé cet alias une fausse bonne idée.
Si on veut une commande de ce type, il faut lui donner un autre nom (ex:
rmi, del, ...)
-jll
100 % d'accord. J'ai perdu deux mois de travail en frappant sans faire
exprès rm / (mon rm avait l'alias -rf). Alors j'ai mit un alias a bash
rdel(real delete).
--
#include <iostream>
#include <string>
int main(){
string myFavoriteOS = "Unix";
cout << "My favorite OS is "
<< myFavoriteOS << end;
return 0;
}
Jean-Louis Liagre wrote in message <42507887$0$13638$:
C'est pas une bonne idée ...
À part la mauvaise idée qui consiste à utiliser bash, j'aimerais savoir quelle raison à ça.
Parce que ça finit par faire croire aux utilisateurs que "rm" demande toujours une confirmation et c'est pas une bonne habitude car un jour, ils se retrouvent sur un système normal (c'est à dire respectant le standard), ils lancent un petit "rm *" pour effacer quelques fichiers seulement, et voilà comment on perd des heures/jours/mois de travail ...
J'ai toujours trouvé cet alias une fausse bonne idée.
Si on veut une commande de ce type, il faut lui donner un autre nom (ex: rmi, del, ...)
-jll 100 % d'accord. J'ai perdu deux mois de travail en frappant sans faire
exprès rm / (mon rm avait l'alias -rf). Alors j'ai mit un alias a bash rdel(real delete).
-- #include <iostream> #include <string>
int main(){ string myFavoriteOS = "Unix"; cout << "My favorite OS is " << myFavoriteOS << end; return 0; }
Laurent Wacrenier
Jean-Louis Liagre écrit:
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix, et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit non chargée ...
Quand tu veux faire le ménage ou récuperer de la place, tu fais fsck ?
Jean-Louis Liagre <jlliagre@localhost> écrit:
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix,
et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit
non chargée ...
Quand tu veux faire le ménage ou récuperer de la place, tu fais fsck ?
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix, et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit non chargée ...
Quand tu veux faire le ménage ou récuperer de la place, tu fais fsck ?
Jean-Louis Liagre
Laurent Wacrenier wrote:
Jean-Louis Liagre écrit:
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix, et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit non chargée ...
Quand tu veux faire le ménage ou récuperer de la place, tu fais fsck ?
Non, pourquoi ?
D'ailleurs je ne fais plus jamais fsck depuis que j'ai activé le logging ufs.
Laurent Wacrenier wrote:
Jean-Louis Liagre <jlliagre@localhost> écrit:
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix,
et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit
non chargée ...
Quand tu veux faire le ménage ou récuperer de la place, tu fais fsck ?
Non, pourquoi ?
D'ailleurs je ne fais plus jamais fsck depuis que j'ai activé le logging ufs.
rm, c'est quand meme la commande d'usage général la plus dangereuse d'Unix, et il faut éviter de jouer avec, un peu comme une arme a feu que l'on croit non chargée ...
Quand tu veux faire le ménage ou récuperer de la place, tu fais fsck ?
Non, pourquoi ?
D'ailleurs je ne fais plus jamais fsck depuis que j'ai activé le logging ufs.
Etienne de Tocqueville
Laurent Wacrenier <lwa@ teaser . fr> a écrit sur fr.comp.os.unix :
Etienne de Tocqueville <et+ écrit:
Donc s'il n'y a ni "-i" ni "-f", il y aura une confirmation que pour les fichiers sans droit d'écriture
"rm" sans option ne pose pas de question et échoue en cas d'erreur. "rm -i" pose des question sur chaque fichier "rm -f" ne pose pas de question et d'indique pas les échecs.
Alors ça doit dépendre des OS. Sur HPUX, un rm sans option sur un fichier sans droit en écriture provoque un message et une question à l'utilisateur :
# touch xx ; chmod 0 xx; /usr/bin/rm xx xx: 0 mode ? (y/n) y
# touch xx ; chmod 0 xx; /usr/bin/rm -f xx
# touch xx ; chmod 0 xx; /usr/bin/rm -i xx xx: ? (y/n) y
Laurent Wacrenier <lwa@ teaser . fr> a écrit sur fr.comp.os.unix :
Etienne de Tocqueville <et+news@steph.teaser.fr> écrit:
Donc s'il n'y a ni "-i" ni "-f", il y aura une confirmation que pour les
fichiers sans droit d'écriture
"rm" sans option ne pose pas de question et échoue en cas d'erreur.
"rm -i" pose des question sur chaque fichier
"rm -f" ne pose pas de question et d'indique pas les échecs.
Alors ça doit dépendre des OS. Sur HPUX, un rm sans option sur un
fichier sans droit en écriture provoque un message et une question à
l'utilisateur :
# touch xx ; chmod 0 xx; /usr/bin/rm xx
xx: 0 mode ? (y/n) y
# touch xx ; chmod 0 xx; /usr/bin/rm -f xx
# touch xx ; chmod 0 xx; /usr/bin/rm -i xx
xx: ? (y/n) y
Laurent Wacrenier <lwa@ teaser . fr> a écrit sur fr.comp.os.unix :
Etienne de Tocqueville <et+ écrit:
Donc s'il n'y a ni "-i" ni "-f", il y aura une confirmation que pour les fichiers sans droit d'écriture
"rm" sans option ne pose pas de question et échoue en cas d'erreur. "rm -i" pose des question sur chaque fichier "rm -f" ne pose pas de question et d'indique pas les échecs.
Alors ça doit dépendre des OS. Sur HPUX, un rm sans option sur un fichier sans droit en écriture provoque un message et une question à l'utilisateur :
# touch xx ; chmod 0 xx; /usr/bin/rm xx xx: 0 mode ? (y/n) y
# touch xx ; chmod 0 xx; /usr/bin/rm -f xx
# touch xx ; chmod 0 xx; /usr/bin/rm -i xx xx: ? (y/n) y
Laurent Wacrenier
Etienne de Tocqueville <et+ écrit:
Alors ça doit dépendre des OS. Sur HPUX, un rm sans option sur un fichier sans droit en écriture provoque un message et une question à l'utilisateur :
Sur un système POSIX :
If this fails for any reason, rm shall write a diagnostic message to standard error, do nothing more with the current file, and go on to any remaining files.
Etienne de Tocqueville <et+news@steph.teaser.fr> écrit:
Alors ça doit dépendre des OS. Sur HPUX, un rm sans option sur un
fichier sans droit en écriture provoque un message et une question à
l'utilisateur :
Sur un système POSIX :
If this fails for any reason, rm shall write a diagnostic message
to standard error, do nothing more with the current file, and go on
to any remaining files.
Alors ça doit dépendre des OS. Sur HPUX, un rm sans option sur un fichier sans droit en écriture provoque un message et une question à l'utilisateur :
Sur un système POSIX :
If this fails for any reason, rm shall write a diagnostic message to standard error, do nothing more with the current file, and go on to any remaining files.
Nicolas George
Laurent Wacrenier wrote in message :
If this fails for any reason, rm shall write a diagnostic message to standard error, do nothing more with the current file, and go on to any remaining files.
À noter que l'absence de droits en écriture sur un fichier n'est absolument pas un obstacle à sa suppression. rm teste spécifiquement ça et affiche un avertissement parce que l'absence de droits en écriture est souvent signe qu'on souhaite garder le fichier en question tel quel, mais ce n'est qu'une protection pratique au niveau de l'interface.
Laurent Wacrenier wrote in message
<slrnd57bn0.4r7.lwa@victor.teaser.fr>:
If this fails for any reason, rm shall write a diagnostic message
to standard error, do nothing more with the current file, and go on
to any remaining files.
À noter que l'absence de droits en écriture sur un fichier n'est absolument
pas un obstacle à sa suppression. rm teste spécifiquement ça et affiche un
avertissement parce que l'absence de droits en écriture est souvent signe
qu'on souhaite garder le fichier en question tel quel, mais ce n'est qu'une
protection pratique au niveau de l'interface.
If this fails for any reason, rm shall write a diagnostic message to standard error, do nothing more with the current file, and go on to any remaining files.
À noter que l'absence de droits en écriture sur un fichier n'est absolument pas un obstacle à sa suppression. rm teste spécifiquement ça et affiche un avertissement parce que l'absence de droits en écriture est souvent signe qu'on souhaite garder le fichier en question tel quel, mais ce n'est qu'une protection pratique au niveau de l'interface.
Etienne de Tocqueville
Nicolas George <nicolas$ a écrit sur fr.comp.os.unix :
Laurent Wacrenier wrote in message :
If this fails for any reason, rm shall write a diagnostic message to standard error, do nothing more with the current file, and go on to any remaining files.
L'exemple du HPUX était en fait assez mauvais, parce qu'il est assez fréquent d'y rencontrer des problèmes de compatibilité. Mais je viens de remarqué qu'il y a exactement le même comportement sur une Sun Solaris :
# touch xx ; chmod 0 xx; /bin/rm xx rm: xx: override protection 0 (yes/no)? y
J'ai encore le même comportement sous Linux :
# touch xx ; chmod 0 xx; /bin/rm xx /bin/rm: remove write-protected file `xx'? y
Et encore sur FreeBSD :
# touch xx ; chmod 0 xx; /bin/rm xx override --------- edetocquev/cabale for xx? y
Bref, je n'ai pas trouvé d'OS ou rm efface un fichier sans droit en écriture sans en demander confirmation à l'utilisateur...
À noter que l'absence de droits en écriture sur un fichier n'est absolument pas un obstacle à sa suppression.
On est bien d'accord. Le "rm" a tout a fait les droits pour effacer le fichier en question. Ce qui compte, c'est les droits en écriture sur le répertoire.
Nicolas George <nicolas$george@salle-s.org> a écrit sur fr.comp.os.unix :
Laurent Wacrenier wrote in message
<slrnd57bn0.4r7.lwa@victor.teaser.fr>:
If this fails for any reason, rm shall write a diagnostic message
to standard error, do nothing more with the current file, and go on
to any remaining files.
L'exemple du HPUX était en fait assez mauvais, parce qu'il est assez
fréquent d'y rencontrer des problèmes de compatibilité. Mais je viens de
remarqué qu'il y a exactement le même comportement sur une Sun Solaris :
# touch xx ; chmod 0 xx; /bin/rm xx
rm: xx: override protection 0 (yes/no)? y
J'ai encore le même comportement sous Linux :
# touch xx ; chmod 0 xx; /bin/rm xx
/bin/rm: remove write-protected file `xx'? y
Et encore sur FreeBSD :
# touch xx ; chmod 0 xx; /bin/rm xx
override --------- edetocquev/cabale for xx? y
Bref, je n'ai pas trouvé d'OS ou rm efface un fichier sans droit en
écriture sans en demander confirmation à l'utilisateur...
À noter que l'absence de droits en écriture sur un fichier n'est absolument
pas un obstacle à sa suppression.
On est bien d'accord. Le "rm" a tout a fait les droits pour effacer le
fichier en question. Ce qui compte, c'est les droits en écriture sur le
répertoire.
Nicolas George <nicolas$ a écrit sur fr.comp.os.unix :
Laurent Wacrenier wrote in message :
If this fails for any reason, rm shall write a diagnostic message to standard error, do nothing more with the current file, and go on to any remaining files.
L'exemple du HPUX était en fait assez mauvais, parce qu'il est assez fréquent d'y rencontrer des problèmes de compatibilité. Mais je viens de remarqué qu'il y a exactement le même comportement sur une Sun Solaris :
# touch xx ; chmod 0 xx; /bin/rm xx rm: xx: override protection 0 (yes/no)? y
J'ai encore le même comportement sous Linux :
# touch xx ; chmod 0 xx; /bin/rm xx /bin/rm: remove write-protected file `xx'? y
Et encore sur FreeBSD :
# touch xx ; chmod 0 xx; /bin/rm xx override --------- edetocquev/cabale for xx? y
Bref, je n'ai pas trouvé d'OS ou rm efface un fichier sans droit en écriture sans en demander confirmation à l'utilisateur...
À noter que l'absence de droits en écriture sur un fichier n'est absolument pas un obstacle à sa suppression.
On est bien d'accord. Le "rm" a tout a fait les droits pour effacer le fichier en question. Ce qui compte, c'est les droits en écriture sur le répertoire.
Laurent Wacrenier
Etienne de Tocqueville <et+ écrit:
# touch xx ; chmod 0 xx; /bin/rm xx /bin/rm: remove write-protected file `xx'? y
En fait, c'est bien le comportement attendu, je n'avais pas fait attention au début du manuel :
b. If the -f option is not specified, and either the permissions of file do not permit writing and the standard input is a terminal or the -i option is specified, rm shall write a prompt to standard error and read a line from the standard input. If the response is not affirmative, rm shall do nothing more with the current file and go on to any remaining files.
Etienne de Tocqueville <et+news@steph.teaser.fr> écrit:
# touch xx ; chmod 0 xx; /bin/rm xx
/bin/rm: remove write-protected file `xx'? y
En fait, c'est bien le comportement attendu, je n'avais pas fait
attention au début du manuel :
b. If the -f option is not specified, and either the permissions
of file do not permit writing and the standard input is a
terminal or the -i option is specified, rm shall write a
prompt to standard error and read a line from the standard
input. If the response is not affirmative, rm shall do nothing
more with the current file and go on to any remaining files.
# touch xx ; chmod 0 xx; /bin/rm xx /bin/rm: remove write-protected file `xx'? y
En fait, c'est bien le comportement attendu, je n'avais pas fait attention au début du manuel :
b. If the -f option is not specified, and either the permissions of file do not permit writing and the standard input is a terminal or the -i option is specified, rm shall write a prompt to standard error and read a line from the standard input. If the response is not affirmative, rm shall do nothing more with the current file and go on to any remaining files.
