montrer des lignes de commandes : combien cela coute a peu pres, et comment opérer ?
40 réponses
Rakotomandimby Mihamina
Bonjour,
Dans le cadre d'une activité d'introduction à Linux, je souhaiterai
avoir un intervenant bien qualifié sous UNIX (plus presisément sous un
shell) pour faire une petite conférence d'environ 1 heure , 1,5 heure
pour montrer l'interet des CLI (command line interface) par rapport aux
cliquodromes.
L'auditoire sera une promotion d'etudiants en Informatique (premier
cycle universitaire).
L'essentiel de la préparation sera de trouver un maximum d'exemples
concrets (et interessants) ou l'on peut comparer l'efficacité de la CLI
par rapport au cliquodrome. Le clicodrome exemple sera bien sur le plus
celebre d'entre eux : MSWin. Et bien sur avoir reponse a toutes les
question des detracteurs des CLI qui seront eventuellement présents.
Ce genre d'intervention est-il courant (je ne pense pas), a combien
aurons-nous (Association) a payer ce type d'intervention ? a quels genre
de prestataires s'adresser ( S.A.P. ? :-P ) ?
Je ne peux pas assurer moi-meme ce genre d'intervention car je suis
moi-meme de bien faible niveau en adminnistration (je ne me sens pas a
la hauteur, quoi)
--
RKTMB - http://www.rktmb.org/Members/mihamina
Tél: + 33 2 38 76 43 65 (France)
Membre d'un L.U.G. à Orléans (Université)
Tout à fait d'accord sur les arguments d'aministration et de télétravail j'ai du intervenir sur une machine distante plus d'une fois... (problème de droits de répertoire, de base de données, de configuration)
Je ne suis pas sûr de mon coup sur la commande imbriquée.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir, vérifier les permissions etc. Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Autre commande sympa à montrer avec les notions de flots c'est sed... Perso je m'en sers pour filter et coloriser certains logs en temps réels sur ma sation de travail.
FAb
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Stephane Chazelas wrote:
Tout à fait d'accord sur les arguments d'aministration et de télétravail j'ai du
intervenir sur une machine distante plus d'une fois... (problème de droits de
répertoire, de base de données, de configuration)
Je ne suis pas sûr de mon coup sur la commande imbriquée.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir,
vérifier les permissions etc.
Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de
windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Autre commande sympa à montrer avec les notions de flots c'est sed... Perso je
m'en sers pour filter et coloriser certains logs en temps réels sur ma sation
de travail.
Tout à fait d'accord sur les arguments d'aministration et de télétravail j'ai du intervenir sur une machine distante plus d'une fois... (problème de droits de répertoire, de base de données, de configuration)
Je ne suis pas sûr de mon coup sur la commande imbriquée.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir, vérifier les permissions etc. Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Autre commande sympa à montrer avec les notions de flots c'est sed... Perso je m'en sers pour filter et coloriser certains logs en temps réels sur ma sation de travail.
Pas de pot. Ca ne marchera pas, et ca prendra du temps a expliquer pourquoi a un debutant (";" et "|" sont des operateurs du shell, pas de find) (sans parler des problemes de echo et de portabilité).
Equivalent zsh:
for f (./***/*.(mp3|avi)(DN-.)) { print -r $f | mail root; xmms -e $f}
find / -follow -type f ( -name "*.mp3 -o -name "*.avi" ) -exec sh -c 'printf "%sn" "$1" | mail root xmms -e "$1"' '{}' '{}' ;
Je ne suis pas sûr de mon coup sur la commande imbriquée.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir, vérifier les permissions etc.
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup sur un trou de securité.
Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Et pourtant "find" est une des commandes Unix les plus mal concues (et les moins portables et plus buggues). Voir le tw de AT&T et le globbing de zsh pour des alternatives.
Autre commande sympa à montrer avec les notions de flots c'est sed... Perso je m'en sers pour filter et coloriser certains logs en temps réels sur ma sation de travail.
sed, c'est rigolo, c'est sur, mais pas beaucoup plus portable que find et une des commandes sur lesquels les debutants butent le plus.
awk est basé sur le meme principe et a une syntaxe deja un peu moins absconse. C'est sur, c'est moins evident de frimer avec parce que c'est en general beaucoup plus lisible meme pour un neophite.
Pas de pot. Ca ne marchera pas, et ca prendra du temps a
expliquer pourquoi a un debutant (";" et "|" sont des operateurs
du shell, pas de find) (sans parler des problemes de echo et de
portabilité).
Equivalent zsh:
for f (./***/*.(mp3|avi)(DN-.)) {
print -r $f | mail root; xmms -e $f}
find / -follow -type f ( -name "*.mp3 -o -name "*.avi" )
-exec sh -c 'printf "%sn" "$1" | mail root
xmms -e "$1"' '{}' '{}' ;
Je ne suis pas sûr de mon coup sur la commande imbriquée.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir,
vérifier les permissions etc.
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup
sur un trou de securité.
Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de
windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Et pourtant "find" est une des commandes Unix les plus mal
concues (et les moins portables et plus buggues). Voir le tw de
AT&T et le globbing de zsh pour des alternatives.
Autre commande sympa à montrer avec les notions de flots c'est sed... Perso je
m'en sers pour filter et coloriser certains logs en temps réels sur ma sation
de travail.
sed, c'est rigolo, c'est sur, mais pas beaucoup plus portable
que find et une des commandes sur lesquels les debutants butent
le plus.
awk est basé sur le meme principe et a une syntaxe deja un peu
moins absconse. C'est sur, c'est moins evident de frimer avec
parce que c'est en general beaucoup plus lisible meme pour un
neophite.
Pas de pot. Ca ne marchera pas, et ca prendra du temps a expliquer pourquoi a un debutant (";" et "|" sont des operateurs du shell, pas de find) (sans parler des problemes de echo et de portabilité).
Equivalent zsh:
for f (./***/*.(mp3|avi)(DN-.)) { print -r $f | mail root; xmms -e $f}
find / -follow -type f ( -name "*.mp3 -o -name "*.avi" ) -exec sh -c 'printf "%sn" "$1" | mail root xmms -e "$1"' '{}' '{}' ;
Je ne suis pas sûr de mon coup sur la commande imbriquée.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir, vérifier les permissions etc.
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup sur un trou de securité.
Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Et pourtant "find" est une des commandes Unix les plus mal concues (et les moins portables et plus buggues). Voir le tw de AT&T et le globbing de zsh pour des alternatives.
Autre commande sympa à montrer avec les notions de flots c'est sed... Perso je m'en sers pour filter et coloriser certains logs en temps réels sur ma sation de travail.
sed, c'est rigolo, c'est sur, mais pas beaucoup plus portable que find et une des commandes sur lesquels les debutants butent le plus.
awk est basé sur le meme principe et a une syntaxe deja un peu moins absconse. C'est sur, c'est moins evident de frimer avec parce que c'est en general beaucoup plus lisible meme pour un neophite.
-- Stephane
FAb
Stephane Chazelas writes:
2004-08-31, 10:46(+00), FAb: [...]
Sinon ce qui pourrait les amuser un peu : [...]
Pas de pot. Ca ne marchera pas, et ca prendra du temps a [...]
vlam 1.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir, vérifier les permissions etc.
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup sur un trou de securité.
Bin oui sinon automatise la suppression, déplacement mais find doit plutôt servir à localiser des cibles. C'est à chacun de choisir c'est évident !
Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Et pourtant "find" est une des commandes Unix les plus mal concues (et les moins portables et plus buggues). Voir le tw de AT&T et le globbing de zsh pour des alternatives.
vlam 2.
sed, c'est rigolo, c'est sur, mais pas beaucoup plus portable que find et une des commandes sur lesquels les debutants butent le plus.
valm 3.
awk est basé sur le meme principe et a une syntaxe deja un peu moins absconse. C'est sur, c'est moins evident de frimer avec parce que c'est en general beaucoup plus lisible meme pour un neophite.
vlam 4. Bouh bouh je me suis fait tailler un costard !
J'ai gardé un souvenir mitigé de awk, sur un petit traitement simple du flot... les perfs étaient pathétiques...
Bon bin y a quand même quelque chose à monter avec find nom ? Recherche un pipe dont le proprio est untel avec certains droits... Chais pas je propose...
Pas de pot. Ca ne marchera pas, et ca prendra du temps a
[...]
vlam 1.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir,
vérifier les permissions etc.
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup
sur un trou de securité.
Bin oui sinon automatise la suppression, déplacement mais find doit plutôt
servir à localiser des cibles. C'est à chacun de choisir c'est évident !
Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de
windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Et pourtant "find" est une des commandes Unix les plus mal
concues (et les moins portables et plus buggues). Voir le tw de
AT&T et le globbing de zsh pour des alternatives.
vlam 2.
sed, c'est rigolo, c'est sur, mais pas beaucoup plus portable
que find et une des commandes sur lesquels les debutants butent
le plus.
valm 3.
awk est basé sur le meme principe et a une syntaxe deja un peu
moins absconse. C'est sur, c'est moins evident de frimer avec
parce que c'est en general beaucoup plus lisible meme pour un
neophite.
vlam 4.
Bouh bouh je me suis fait tailler un costard !
J'ai gardé un souvenir mitigé de awk, sur un petit traitement simple du
flot... les perfs étaient pathétiques...
Bon bin y a quand même quelque chose à monter avec find nom ?
Recherche un pipe dont le proprio est untel avec certains droits...
Chais pas je propose...
Pas de pot. Ca ne marchera pas, et ca prendra du temps a [...]
vlam 1.
Dans les classiques de find on trouve les scripts pout nettoyer les homedir, vérifier les permissions etc.
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup sur un trou de securité.
Bin oui sinon automatise la suppression, déplacement mais find doit plutôt servir à localiser des cibles. C'est à chacun de choisir c'est évident !
Depuis que je connais find, je ne comprends pas qu'on utilise la recherche de windows elle est trop frustrante... Mais bon si j'étias ordonné aussi...
Et pourtant "find" est une des commandes Unix les plus mal concues (et les moins portables et plus buggues). Voir le tw de AT&T et le globbing de zsh pour des alternatives.
vlam 2.
sed, c'est rigolo, c'est sur, mais pas beaucoup plus portable que find et une des commandes sur lesquels les debutants butent le plus.
valm 3.
awk est basé sur le meme principe et a une syntaxe deja un peu moins absconse. C'est sur, c'est moins evident de frimer avec parce que c'est en general beaucoup plus lisible meme pour un neophite.
vlam 4. Bouh bouh je me suis fait tailler un costard !
J'ai gardé un souvenir mitigé de awk, sur un petit traitement simple du flot... les perfs étaient pathétiques...
Bon bin y a quand même quelque chose à monter avec find nom ? Recherche un pipe dont le proprio est untel avec certains droits... Chais pas je propose...
FAb
Marc Boyer
Rakotomandimby Mihamina wrote:
Marc Boyer wrote:
Sur quelle région cherches-tu ?
Région centre specialement Orléans. Mais nous prendront en charge les frais et moyens de déplacement.
Orléan, c'est la nouvelle banlieu de Paris non ? Devrait pas trop être difficile de trouver quelqu'un.
Eventuellement, une association de promotion de Linux.
Oui mais ça justement c'est moi :-)
Ah... OK...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Rakotomandimby Mihamina wrote:
Marc Boyer wrote:
Sur quelle région cherches-tu ?
Région centre specialement Orléans.
Mais nous prendront en charge les frais et moyens de déplacement.
Orléan, c'est la nouvelle banlieu de Paris non ?
Devrait pas trop être difficile de trouver quelqu'un.
Eventuellement, une association de promotion de Linux.
Oui mais ça justement c'est moi :-)
Ah... OK...
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Région centre specialement Orléans. Mais nous prendront en charge les frais et moyens de déplacement.
Orléan, c'est la nouvelle banlieu de Paris non ? Devrait pas trop être difficile de trouver quelqu'un.
Eventuellement, une association de promotion de Linux.
Oui mais ça justement c'est moi :-)
Ah... OK...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Rakotomandimby Mihamina
Marc Boyer wrote:
Sur quelle région cherches-tu ?
Région centre specialement Orléans. Mais nous prendront en charge les frais et moyens de déplacement.
L'admin système est un puis sans fond: je me garderais bien de juger tes admins sans avoir une vision précise de ce qu'ils font.
Je ne les juges pas. Je constate seulement qu'ils ont beaucoup de choses a faire.
Essaye peut-être les admins systèmes de labo de recherche sur la campus: généralement, ils voient moins d'étudiants et peuvent être plus partant pour ce genre de chose.
Eventuellement, une association de promotion de Linux.
Oui mais ça justement c'est moi :-) -- RKTMB - http://www.rktmb.org/Members/mihamina Tél: + 33 2 38 76 43 65 (France) Membre d'un L.U.G. à Orléans (Université)
Marc Boyer wrote:
Sur quelle région cherches-tu ?
Région centre specialement Orléans.
Mais nous prendront en charge les frais et moyens de déplacement.
L'admin système est un puis sans fond: je me garderais bien de juger
tes admins sans avoir une vision précise de ce qu'ils font.
Je ne les juges pas. Je constate seulement qu'ils ont beaucoup de choses
a faire.
Essaye peut-être les admins systèmes de labo de recherche sur la
campus: généralement, ils voient moins d'étudiants et peuvent être
plus partant pour ce genre de chose.
Eventuellement, une association de promotion de Linux.
Oui mais ça justement c'est moi :-)
--
RKTMB - http://www.rktmb.org/Members/mihamina
Tél: + 33 2 38 76 43 65 (France)
Membre d'un L.U.G. à Orléans (Université)
Région centre specialement Orléans. Mais nous prendront en charge les frais et moyens de déplacement.
L'admin système est un puis sans fond: je me garderais bien de juger tes admins sans avoir une vision précise de ce qu'ils font.
Je ne les juges pas. Je constate seulement qu'ils ont beaucoup de choses a faire.
Essaye peut-être les admins systèmes de labo de recherche sur la campus: généralement, ils voient moins d'étudiants et peuvent être plus partant pour ce genre de chose.
Eventuellement, une association de promotion de Linux.
Oui mais ça justement c'est moi :-) -- RKTMB - http://www.rktmb.org/Members/mihamina Tél: + 33 2 38 76 43 65 (France) Membre d'un L.U.G. à Orléans (Université)
Stephane Chazelas
2004-08-31, 11:53(+00), FAb: [...]
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup sur un trou de securité.
Bin oui sinon automatise la suppression, déplacement mais find doit plutôt servir à localiser des cibles. C'est à chacun de choisir c'est évident !
C'est possible de maniere un peu fiable avec certaines versions de find comme celle des BSD avec leur -execdir.
[...]
J'ai gardé un souvenir mitigé de awk, sur un petit traitement simple du flot... les perfs étaient pathétiques...
Ca depend des versions de awk. Certaines version de gawk sont en effet particulierement lentes (surtout dans les locales multibyte). Cela dit, le awk original est en general reconnu plus rapide que awk (mais a aussi des limitations que perl n'a pas).
vlam [1-4]
Je n'avais pas l'intention de paraitre rude. Je tenais juste a temperer l'enthousiasme pour la "ligne de commande".
Sur la plupart des Unix, on se retrouve avec des outils vieux de plus de 20 ans, plus ou moins bien pensés qui portent en eux les sequelles de plusieurs decennies d'evolution souvent non compatibles d'un Unix a l'autre et ou le soucis de compatibilité ascendante a completement ruiné le design et l'utilisabilité. Comparer par exemple ksh93 avec le Bourne shell original ou rc (rares shells concus from scratch dont la syntaxe est limpide et ou les concepts transparaissent assez immediatement).
-- Stephane
2004-08-31, 11:53(+00), FAb:
[...]
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup
sur un trou de securité.
Bin oui sinon automatise la suppression, déplacement mais find doit plutôt
servir à localiser des cibles. C'est à chacun de choisir c'est évident !
C'est possible de maniere un peu fiable avec certaines versions
de find comme celle des BSD avec leur -execdir.
[...]
J'ai gardé un souvenir mitigé de awk, sur un petit traitement simple du
flot... les perfs étaient pathétiques...
Ca depend des versions de awk. Certaines version de gawk sont en
effet particulierement lentes (surtout dans les locales
multibyte). Cela dit, le awk original est en general reconnu
plus rapide que awk (mais a aussi des limitations que perl n'a
pas).
vlam [1-4]
Je n'avais pas l'intention de paraitre rude. Je tenais juste a
temperer l'enthousiasme pour la "ligne de commande".
Sur la plupart des Unix, on se retrouve avec des outils vieux de
plus de 20 ans, plus ou moins bien pensés qui portent en eux les
sequelles de plusieurs decennies d'evolution souvent non
compatibles d'un Unix a l'autre et ou le soucis de compatibilité
ascendante a completement ruiné le design et l'utilisabilité.
Comparer par exemple ksh93 avec le Bourne shell original ou rc
(rares shells concus from scratch dont la syntaxe est limpide et
ou les concepts transparaissent assez immediatement).
Tres dangereux, ca, de nettoyer des home dirs avec find. A coup sur un trou de securité.
Bin oui sinon automatise la suppression, déplacement mais find doit plutôt servir à localiser des cibles. C'est à chacun de choisir c'est évident !
C'est possible de maniere un peu fiable avec certaines versions de find comme celle des BSD avec leur -execdir.
[...]
J'ai gardé un souvenir mitigé de awk, sur un petit traitement simple du flot... les perfs étaient pathétiques...
Ca depend des versions de awk. Certaines version de gawk sont en effet particulierement lentes (surtout dans les locales multibyte). Cela dit, le awk original est en general reconnu plus rapide que awk (mais a aussi des limitations que perl n'a pas).
vlam [1-4]
Je n'avais pas l'intention de paraitre rude. Je tenais juste a temperer l'enthousiasme pour la "ligne de commande".
Sur la plupart des Unix, on se retrouve avec des outils vieux de plus de 20 ans, plus ou moins bien pensés qui portent en eux les sequelles de plusieurs decennies d'evolution souvent non compatibles d'un Unix a l'autre et ou le soucis de compatibilité ascendante a completement ruiné le design et l'utilisabilité. Comparer par exemple ksh93 avec le Bourne shell original ou rc (rares shells concus from scratch dont la syntaxe est limpide et ou les concepts transparaissent assez immediatement).
-- Stephane
FAb
Stephane Chazelas writes:
C'est possible de maniere un peu fiable avec certaines versions de find comme celle des BSD avec leur -execdir.
ça empêche d'effet un fichier important dont le nom n'est pas très judicieux et dont l'utilisateur sait ce qu'il est ?
[...]
Ca depend des versions de awk. Certaines version de gawk sont en effet particulierement lentes (surtout dans les locales multibyte). Cela dit, le awk original est en general reconnu plus rapide que awk (mais a aussi des limitations que perl n'a pas).
Ce devait être celui de GNU. Je re-essaierais un de ces 4.
vlam [1-4]
Je n'avais pas l'intention de paraitre rude. Je tenais juste a temperer l'enthousiasme pour la "ligne de commande".
Y a pas de mal !! Je voulais juste communiquer un peu d'enthousiasme ;-) mais je ne suis pas non plus un intégriste ou un neuneu qui ne jure que par la CLI (quoi que ... :-D ) mais je me dis qu'il y a bien des manières ludiques d'introduction...
Tiens dans le style clambourd CLI (après le passage sur les erreurs de commandes de l'autre jour (à la «finger god : no such user god») je me souviens d'un prof pas très réputé pour son humour qui nous avait sorti parmi les exemples % date > timer % more timer C'est moyen mais il est devenu pivoine... et nous avons bien ri ! Ah nostalgie.
C'est possible de maniere un peu fiable avec certaines versions
de find comme celle des BSD avec leur -execdir.
ça empêche d'effet un fichier important dont le nom n'est pas très judicieux
et dont l'utilisateur sait ce qu'il est ?
[...]
Ca depend des versions de awk. Certaines version de gawk sont en
effet particulierement lentes (surtout dans les locales
multibyte). Cela dit, le awk original est en general reconnu
plus rapide que awk (mais a aussi des limitations que perl n'a
pas).
Ce devait être celui de GNU.
Je re-essaierais un de ces 4.
vlam [1-4]
Je n'avais pas l'intention de paraitre rude. Je tenais juste a
temperer l'enthousiasme pour la "ligne de commande".
Y a pas de mal !! Je voulais juste communiquer un peu d'enthousiasme ;-) mais je
ne suis pas non plus un intégriste ou un neuneu qui ne jure que par la CLI (quoi
que ... :-D ) mais je me dis qu'il y a bien des manières ludiques
d'introduction...
Tiens dans le style clambourd CLI (après le passage sur les erreurs de commandes
de l'autre jour (à la «finger god : no such user god») je me souviens d'un prof
pas très réputé pour son humour qui nous avait sorti parmi les exemples
% date > timer
% more timer
C'est moyen mais il est devenu pivoine... et nous avons bien ri !
Ah nostalgie.
C'est possible de maniere un peu fiable avec certaines versions de find comme celle des BSD avec leur -execdir.
ça empêche d'effet un fichier important dont le nom n'est pas très judicieux et dont l'utilisateur sait ce qu'il est ?
[...]
Ca depend des versions de awk. Certaines version de gawk sont en effet particulierement lentes (surtout dans les locales multibyte). Cela dit, le awk original est en general reconnu plus rapide que awk (mais a aussi des limitations que perl n'a pas).
Ce devait être celui de GNU. Je re-essaierais un de ces 4.
vlam [1-4]
Je n'avais pas l'intention de paraitre rude. Je tenais juste a temperer l'enthousiasme pour la "ligne de commande".
Y a pas de mal !! Je voulais juste communiquer un peu d'enthousiasme ;-) mais je ne suis pas non plus un intégriste ou un neuneu qui ne jure que par la CLI (quoi que ... :-D ) mais je me dis qu'il y a bien des manières ludiques d'introduction...
Tiens dans le style clambourd CLI (après le passage sur les erreurs de commandes de l'autre jour (à la «finger god : no such user god») je me souviens d'un prof pas très réputé pour son humour qui nous avait sorti parmi les exemples % date > timer % more timer C'est moyen mais il est devenu pivoine... et nous avons bien ri ! Ah nostalgie.
[...]
Merci pour toutes ces précisions.
FAb
Stephane Chazelas
2004-08-31, 12:46(+00), FAb:
Stephane Chazelas writes:
C'est possible de maniere un peu fiable avec certaines versions de find comme celle des BSD avec leur -execdir.
ça empêche d'effet un fichier important dont le nom n'est pas très judicieux et dont l'utilisateur sait ce qu'il est ?
Non. Le probleme le plus evident est si on utilise xargs ou un "while read" (comme sur certains scripts systems fournis pour HPUX...).
find / -name '*~' | xargs rm
Et si je cree un fichier qui s'appelle:
'/home/chazelas/ /etc/passwd ~'
Ce que contourne -execdir est plus subtil et plus difficile a mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ; Je peux faire en sorte que, au moment ou rm se charge, /home/chazelas/test devienne subreptissement un lien symbolique vers /etc.
C'est possible de maniere un peu fiable avec certaines versions
de find comme celle des BSD avec leur -execdir.
ça empêche d'effet un fichier important dont le nom n'est pas très judicieux
et dont l'utilisateur sait ce qu'il est ?
Non. Le probleme le plus evident est si on utilise xargs ou un
"while read" (comme sur certains scripts systems fournis pour
HPUX...).
find / -name '*~' | xargs rm
Et si je cree un fichier qui s'appelle:
'/home/chazelas/
/etc/passwd
~'
Ce que contourne -execdir est plus subtil et plus difficile a
mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ;
Je peux faire en sorte que, au moment ou rm se charge,
/home/chazelas/test devienne subreptissement un lien symbolique
vers /etc.
C'est possible de maniere un peu fiable avec certaines versions de find comme celle des BSD avec leur -execdir.
ça empêche d'effet un fichier important dont le nom n'est pas très judicieux et dont l'utilisateur sait ce qu'il est ?
Non. Le probleme le plus evident est si on utilise xargs ou un "while read" (comme sur certains scripts systems fournis pour HPUX...).
find / -name '*~' | xargs rm
Et si je cree un fichier qui s'appelle:
'/home/chazelas/ /etc/passwd ~'
Ce que contourne -execdir est plus subtil et plus difficile a mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ; Je peux faire en sorte que, au moment ou rm se charge, /home/chazelas/test devienne subreptissement un lien symbolique vers /etc.
-- Stephane
Laurent Wacrenier
Stephane Chazelas écrit:
Ce que contourne -execdir est plus subtil et plus difficile a mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ; Je peux faire en sorte que, au moment ou rm se charge, /home/chazelas/test devienne subreptissement un lien symbolique vers /etc.
Je ne suis pas sur que toutes les implémentations fassent un lstat() avant et après le chdir() pour vérifier que le répertoire n'a pas changé au vol.
Ce que contourne -execdir est plus subtil et plus difficile a
mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ;
Je peux faire en sorte que, au moment ou rm se charge,
/home/chazelas/test devienne subreptissement un lien symbolique
vers /etc.
Je ne suis pas sur que toutes les implémentations fassent un lstat()
avant et après le chdir() pour vérifier que le répertoire
n'a pas changé au vol.
Ce que contourne -execdir est plus subtil et plus difficile a mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ; Je peux faire en sorte que, au moment ou rm se charge, /home/chazelas/test devienne subreptissement un lien symbolique vers /etc.
Je ne suis pas sur que toutes les implémentations fassent un lstat() avant et après le chdir() pour vérifier que le répertoire n'a pas changé au vol.
Stephane Chazelas
2004-08-31, 13:24(+00), Laurent Wacrenier:
Stephane Chazelas écrit:
Ce que contourne -execdir est plus subtil et plus difficile a mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ; Je peux faire en sorte que, au moment ou rm se charge, /home/chazelas/test devienne subreptissement un lien symbolique vers /etc.
Je ne suis pas sur que toutes les implémentations fassent un lstat() avant et après le chdir() pour vérifier que le répertoire n'a pas changé au vol.
Avec "-exec", rm est lancé avec le chemin complet: rm /home/chazelas/test/shadow~ Donc, quelque soit l'implementation de find, ce n'est pas fiable (find n'a pas le controle sur l'execution de "rm").
Avec "-execdir" (specifique BSD), find parcourt l'arbre en faisant des chdir et en lancant rm avec le chemin relatif (d'ou la necessité d'utiliser rm -f --). Dans ce dernier cas, il peut s'averer que la recherche commence dans /home/toto et que find trouve un fichier dans /home/titi (si un repertoire dans /home/toto a ete renomme en /home/titi/quelquechose) (a moins que le find de BSD fasse des verifications supplementaires, ce qui n'est pas exclu).
Ce que contourne -execdir est plus subtil et plus difficile a
mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ;
Je peux faire en sorte que, au moment ou rm se charge,
/home/chazelas/test devienne subreptissement un lien symbolique
vers /etc.
Je ne suis pas sur que toutes les implémentations fassent un lstat()
avant et après le chdir() pour vérifier que le répertoire
n'a pas changé au vol.
Avec "-exec", rm est lancé avec le chemin complet:
rm /home/chazelas/test/shadow~
Donc, quelque soit l'implementation de find, ce n'est pas fiable
(find n'a pas le controle sur l'execution de "rm").
Avec "-execdir" (specifique BSD), find parcourt l'arbre en
faisant des chdir et en lancant rm avec le chemin relatif (d'ou
la necessité d'utiliser rm -f --). Dans ce dernier cas, il peut
s'averer que la recherche commence dans /home/toto et que find
trouve un fichier dans /home/titi (si un repertoire dans
/home/toto a ete renomme en /home/titi/quelquechose) (a moins
que le find de BSD fasse des verifications supplementaires, ce
qui n'est pas exclu).
Ce que contourne -execdir est plus subtil et plus difficile a mettre en place:
si je cree un fichier:
/home/chazelas/test/shadow~
Avec le find -name '*~' -exec rm {} ; Je peux faire en sorte que, au moment ou rm se charge, /home/chazelas/test devienne subreptissement un lien symbolique vers /etc.
Je ne suis pas sur que toutes les implémentations fassent un lstat() avant et après le chdir() pour vérifier que le répertoire n'a pas changé au vol.
Avec "-exec", rm est lancé avec le chemin complet: rm /home/chazelas/test/shadow~ Donc, quelque soit l'implementation de find, ce n'est pas fiable (find n'a pas le controle sur l'execution de "rm").
Avec "-execdir" (specifique BSD), find parcourt l'arbre en faisant des chdir et en lancant rm avec le chemin relatif (d'ou la necessité d'utiliser rm -f --). Dans ce dernier cas, il peut s'averer que la recherche commence dans /home/toto et que find trouve un fichier dans /home/titi (si un repertoire dans /home/toto a ete renomme en /home/titi/quelquechose) (a moins que le find de BSD fasse des verifications supplementaires, ce qui n'est pas exclu).
