Les commandes bash: cherche-t-on a nous rendre fous?
13 réponses
GP
Voici comment il faut faire un grep:
grep [options] PATTERN [FILE...]
Ex.:
grep -ir IPv6 .
Voici comment il faut faire un find:
find [path...] [expression]
Ex.:
find -iname . "*IPv6*"
Oups! Ça ne fonctionne pas. Les directives ne parlent pas des options. Il
aurait fallu écrire:
find [path...] [options] [expression]
find . -iname "*IPv6*"
De find à grep, on constate que tout est chamboulé.
[expression], qui correspond à PATTERN est à la fin plutôt qu'au milieu.
[options] est au mileu plutôt qu'au début.
[path...], qui correspond à FILE est au début plutôt qu'à la fin.
Y a-t-il quelque raison obscure qui fait que les commandes ne peuvent être
standardisées ou, et c'est bien ce que je pense, est-ce qu'on tente de nous
rendre fous à force de «chacun à sa manière et vive l'anarchie»?
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais
permis que les choses se passent ainsi. Je l'ai déjà dit et ej le répète, je
pense que Linux manque de suits.
Enfin, n'étant pas expert, je me trompe peut-être. J'attends vos commentaires.
De find à grep, on constate que tout est chamboulé. oui t'as raison ... mais les man sont comme ca que depuis 20 ans, à quelque
broutilles pret :
sun solaris /usr/bin/grep [ -bchilnsvw ] limited-regular-expression [ filename... ] linux grep [options] PATTERN [FILE...]
ma SGI et mon alpha sont eteintes donc je ne pourrait pas plus argumenter.
[expression], qui correspond à PATTERN est à la fin plutôt qu'au milieu.
[options] est au mileu plutôt qu'au début.
[path...], qui correspond à FILE est au début plutôt qu'à la fin. ah non PATH c'est le PATH, pas le FILE ...
Y a-t-il quelque raison obscure qui fait que les commandes ne peuvent être standardisées ou, difficile a le faire on ne recouvre pas les memes activites
et c'est bien ce que je pense, est-ce qu'on tente de nous rendre fous à force de «chacun à sa manière et vive l'anarchie»? bah des generations d'utilisateurs unix ont tenus et tiennent depuis plus de
20 ans ... donc ça va ... Et puis l'anarchie, ca rend alerte et ouvert ...
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais permis que les choses se passent ainsi help grep
help find help tar help kill help sed help awk help lex help yacc help ps ... ne donne rien ... Et j'ai rien trouve d'aussi puissant chez M$ c
Je l'ai déjà dit et ej le répète, je pense que Linux manque de suits. perso je m'en tape completement ... Chaque commande est documentée, cela me
suffit ... Et puis dans ce cas la c'est pas linux, mais les outils GNU que tu incrimines. Linux ce 'est que le kernel, kernel sur lequel on a compilé ces outils gnu ... Personne n'empeche personne de les reimplementer ... mais personne n'y tient vraiment.
Enfin, n'étant pas expert, je me trompe peut-être. J'attends vos commentaires. que voila ...
GP wrote:
Voici comment il faut faire un grep:
grep [options] PATTERN [FILE...]
Ex.:
grep -ir IPv6 .
Non !
-ir option
IPv6 pattern
. n'est pas un file mais un path : ça ne peut pas marcher
grep -ir IPv6 *
serait la bonne option ...
Voici comment il faut faire un find:
find [path...] [expression]
Ex.:
find -iname . "*IPv6*"
non, c'est expression est fausse ... D'ailleurs elle ne respecte pas le
man :
path c'est .
expression sera -iname "*IPv6*" -print
find . -iname ."*IPv6*" -print
euuuu le man, c'est pas trop fait pour etre interprete ... à sa guise.
Oups! Ça ne fonctionne pas. Les directives ne parlent pas des options. Il
aurait fallu écrire:
De find à grep, on constate que tout est chamboulé.
oui t'as raison ... mais les man sont comme ca que depuis 20 ans, à quelque
broutilles pret :
sun solaris
/usr/bin/grep [ -bchilnsvw ] limited-regular-expression
[ filename... ]
linux
grep [options] PATTERN [FILE...]
ma SGI et mon alpha sont eteintes donc je ne pourrait pas plus argumenter.
[expression], qui correspond à PATTERN est à la fin plutôt qu'au milieu.
[options] est au mileu plutôt qu'au début.
[path...], qui correspond à FILE est au début plutôt qu'à la fin.
ah non PATH c'est le PATH, pas le FILE ...
Y a-t-il quelque raison obscure qui fait que les commandes ne peuvent être
standardisées ou,
difficile a le faire on ne recouvre pas les memes activites
et c'est bien ce que je pense, est-ce qu'on tente de
nous rendre fous à force de «chacun à sa manière et vive l'anarchie»?
bah des generations d'utilisateurs unix ont tenus et tiennent depuis plus de
20 ans ... donc ça va ... Et puis l'anarchie, ca rend alerte et ouvert ...
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais
permis que les choses se passent ainsi
help grep
help find
help tar
help kill
help sed
help awk
help lex
help yacc
help ps
...
ne donne rien ... Et j'ai rien trouve d'aussi puissant chez M$ c
Je l'ai déjà dit et ej le répète,
je pense que Linux manque de suits.
perso je m'en tape completement ... Chaque commande est documentée, cela me
suffit ... Et puis dans ce cas la c'est pas linux, mais les outils GNU que
tu incrimines. Linux ce 'est que le kernel, kernel sur lequel on a compilé
ces outils gnu ... Personne n'empeche personne de les reimplementer ...
mais personne n'y tient vraiment.
Enfin, n'étant pas expert, je me trompe peut-être. J'attends vos
commentaires.
que voila ...
De find à grep, on constate que tout est chamboulé. oui t'as raison ... mais les man sont comme ca que depuis 20 ans, à quelque
broutilles pret :
sun solaris /usr/bin/grep [ -bchilnsvw ] limited-regular-expression [ filename... ] linux grep [options] PATTERN [FILE...]
ma SGI et mon alpha sont eteintes donc je ne pourrait pas plus argumenter.
[expression], qui correspond à PATTERN est à la fin plutôt qu'au milieu.
[options] est au mileu plutôt qu'au début.
[path...], qui correspond à FILE est au début plutôt qu'à la fin. ah non PATH c'est le PATH, pas le FILE ...
Y a-t-il quelque raison obscure qui fait que les commandes ne peuvent être standardisées ou, difficile a le faire on ne recouvre pas les memes activites
et c'est bien ce que je pense, est-ce qu'on tente de nous rendre fous à force de «chacun à sa manière et vive l'anarchie»? bah des generations d'utilisateurs unix ont tenus et tiennent depuis plus de
20 ans ... donc ça va ... Et puis l'anarchie, ca rend alerte et ouvert ...
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais permis que les choses se passent ainsi help grep
help find help tar help kill help sed help awk help lex help yacc help ps ... ne donne rien ... Et j'ai rien trouve d'aussi puissant chez M$ c
Je l'ai déjà dit et ej le répète, je pense que Linux manque de suits. perso je m'en tape completement ... Chaque commande est documentée, cela me
suffit ... Et puis dans ce cas la c'est pas linux, mais les outils GNU que tu incrimines. Linux ce 'est que le kernel, kernel sur lequel on a compilé ces outils gnu ... Personne n'empeche personne de les reimplementer ... mais personne n'y tient vraiment.
Enfin, n'étant pas expert, je me trompe peut-être. J'attends vos commentaires. que voila ...
Nicolas George
"X.B" wrote in message <40e31089$0$6603$:
-ir option
Non, option*s*.
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage.
Pour la postérité : l'option -r indique à grep de descendre dans les répertoires ; ainsi, voyant . comme fichier à examiner, il va constater que c'est un répertoire et examiner récursivement tous les fichiers qu'il contient.
"X.B" wrote in message <40e31089$0$6603$636a15ce@news.free.fr>:
-ir option
Non, option*s*.
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage.
Pour la postérité : l'option -r indique à grep de descendre dans les
répertoires ; ainsi, voyant . comme fichier à examiner, il va constater
que c'est un répertoire et examiner récursivement tous les fichiers
qu'il contient.
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage.
Pour la postérité : l'option -r indique à grep de descendre dans les répertoires ; ainsi, voyant . comme fichier à examiner, il va constater que c'est un répertoire et examiner récursivement tous les fichiers qu'il contient.
TiChou
Dans le message <news:, *GP* tapota sur f.c.o.l.configuration :
Voici comment il faut faire un grep:
grep [options] PATTERN [FILE...]
Ex.: grep -ir IPv6 .
Voici comment il faut faire un find:
find [path...] [expression]
Ex.: find -iname . "*IPv6*"
Oups! Ça ne fonctionne pas.
Normal, vous ne suivez pas la syntaxe. Le chemin (path) est à placer comme premier argument, c'est pourtant simple.
Les directives ne parlent pas des options.
man find, à moins que vous ne sachiez pas lire comme il faut un man.
Il aurait fallu écrire:
find [path...] [options] [expression]
Non. Dans les expressions il y a les options. Vous confondez expressions (une suite d'opérande et d'opérateurs), un motif (pattern), les expressions rationnelles (regular expression/regexp) qui forment un motif et les expansions ou développements de fichier et de chemin qui forment aussi un motif.
find [path...] [expression] est la bonne syntaxe.
find . -iname "*IPv6*"
find = commande
. = path
-iname "*IPv6*" = expression
De find à grep, on constate que tout est chamboulé.
C'est votre interprétation de la syntaxe qui est chamboulée.
[expression], qui correspond à PATTERN est à la fin plutôt qu'au milieu.
Non, ça ne correspond pas du tout. expression != PATTERN
[options] est au mileu plutôt qu'au début.
[path...], qui correspond à FILE est au début plutôt qu'à la fin.
Non, vous faites encore une confusion. On n'agit pas sur des fichiers ou des répertoires. On place l'endroit où doit débuter une recherche. C'est deux choses totalement différentes.
Y a-t-il quelque raison obscure qui fait que les commandes ne peuvent être standardisées
Les commandes shells répondent dans 99% des cas à un standard de syntaxe. Quand on connait la syntaxe d'une commande, on connait déjà la syntaxe des commandes qu'on ne connait pas. Ce n'est pas le cas des autres OS où il n'y a même pas une logique dans le choix des noms ou des raccourcis des commandes et des options.
ou, et c'est bien ce que je pense, est-ce qu'on tente de nous rendre fous à force de «chacun à sa manière et vive l'anarchie»?
C'est vous qui mélangez tout et qui faites des confusions. Et vous tentez de semer la zizanie.
Au passage, ces commandes n'ont rien à voir avec bash et sont indépendantes. Là aussi confusion.
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais permis que les choses se passent ainsi.
Ah d'accord, c'était donc un troll. Tout s'explique. Bref, vraiment n'importe quoi.
Je l'ai déjà dit et ej le répète, je pense que Linux manque de suits.
Vous pensez très mal. C'est vous qui manquez de logique dans votre raisonement et dans votre analyse.
Enfin, n'étant pas expert, je me trompe peut-être.
Oui et ça se voit.
J'attends vos commentaires.
C'est fait.
Un dernier quand même pour la forme : le rapport dans tout ça avec Linux et la charte du groupe ? La prochaine fois abstenez vous.
-- TiChou
Dans le message <news:10e61fv6veb554d@corp.supernews.com>,
*GP* tapota sur f.c.o.l.configuration :
Voici comment il faut faire un grep:
grep [options] PATTERN [FILE...]
Ex.:
grep -ir IPv6 .
Voici comment il faut faire un find:
find [path...] [expression]
Ex.:
find -iname . "*IPv6*"
Oups! Ça ne fonctionne pas.
Normal, vous ne suivez pas la syntaxe. Le chemin (path) est à placer comme
premier argument, c'est pourtant simple.
Les directives ne parlent pas des options.
man find, à moins que vous ne sachiez pas lire comme il faut un man.
Il aurait fallu écrire:
find [path...] [options] [expression]
Non. Dans les expressions il y a les options.
Vous confondez expressions (une suite d'opérande et d'opérateurs), un motif
(pattern), les expressions rationnelles (regular expression/regexp) qui
forment un motif et les expansions ou développements de fichier et de chemin
qui forment aussi un motif.
find [path...] [expression] est la bonne syntaxe.
find . -iname "*IPv6*"
find = commande
. = path
-iname "*IPv6*" = expression
De find à grep, on constate que tout est chamboulé.
C'est votre interprétation de la syntaxe qui est chamboulée.
[expression], qui correspond à PATTERN est à la fin plutôt qu'au milieu.
Non, ça ne correspond pas du tout. expression != PATTERN
[options] est au mileu plutôt qu'au début.
[path...], qui correspond à FILE est au début plutôt qu'à la fin.
Non, vous faites encore une confusion. On n'agit pas sur des fichiers ou des
répertoires. On place l'endroit où doit débuter une recherche. C'est deux
choses totalement différentes.
Y a-t-il quelque raison obscure qui fait que les commandes ne peuvent
être standardisées
Les commandes shells répondent dans 99% des cas à un standard de syntaxe.
Quand on connait la syntaxe d'une commande, on connait déjà la syntaxe des
commandes qu'on ne connait pas. Ce n'est pas le cas des autres OS où il n'y
a même pas une logique dans le choix des noms ou des raccourcis des
commandes et des options.
ou, et c'est bien ce que je pense, est-ce qu'on tente de nous rendre fous
à force de «chacun à sa manière et vive l'anarchie»?
C'est vous qui mélangez tout et qui faites des confusions. Et vous tentez de
semer la zizanie.
Au passage, ces commandes n'ont rien à voir avec bash et sont indépendantes.
Là aussi confusion.
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais
permis que les choses se passent ainsi.
Ah d'accord, c'était donc un troll. Tout s'explique. Bref, vraiment
n'importe quoi.
Je l'ai déjà dit et ej le répète, je pense que Linux manque de suits.
Vous pensez très mal. C'est vous qui manquez de logique dans votre
raisonement et dans votre analyse.
Enfin, n'étant pas expert, je me trompe peut-être.
Oui et ça se voit.
J'attends vos commentaires.
C'est fait.
Un dernier quand même pour la forme : le rapport dans tout ça avec Linux et
la charte du groupe ? La prochaine fois abstenez vous.
Dans le message <news:, *GP* tapota sur f.c.o.l.configuration :
Voici comment il faut faire un grep:
grep [options] PATTERN [FILE...]
Ex.: grep -ir IPv6 .
Voici comment il faut faire un find:
find [path...] [expression]
Ex.: find -iname . "*IPv6*"
Oups! Ça ne fonctionne pas.
Normal, vous ne suivez pas la syntaxe. Le chemin (path) est à placer comme premier argument, c'est pourtant simple.
Les directives ne parlent pas des options.
man find, à moins que vous ne sachiez pas lire comme il faut un man.
Il aurait fallu écrire:
find [path...] [options] [expression]
Non. Dans les expressions il y a les options. Vous confondez expressions (une suite d'opérande et d'opérateurs), un motif (pattern), les expressions rationnelles (regular expression/regexp) qui forment un motif et les expansions ou développements de fichier et de chemin qui forment aussi un motif.
find [path...] [expression] est la bonne syntaxe.
find . -iname "*IPv6*"
find = commande
. = path
-iname "*IPv6*" = expression
De find à grep, on constate que tout est chamboulé.
C'est votre interprétation de la syntaxe qui est chamboulée.
[expression], qui correspond à PATTERN est à la fin plutôt qu'au milieu.
Non, ça ne correspond pas du tout. expression != PATTERN
[options] est au mileu plutôt qu'au début.
[path...], qui correspond à FILE est au début plutôt qu'à la fin.
Non, vous faites encore une confusion. On n'agit pas sur des fichiers ou des répertoires. On place l'endroit où doit débuter une recherche. C'est deux choses totalement différentes.
Y a-t-il quelque raison obscure qui fait que les commandes ne peuvent être standardisées
Les commandes shells répondent dans 99% des cas à un standard de syntaxe. Quand on connait la syntaxe d'une commande, on connait déjà la syntaxe des commandes qu'on ne connait pas. Ce n'est pas le cas des autres OS où il n'y a même pas une logique dans le choix des noms ou des raccourcis des commandes et des options.
ou, et c'est bien ce que je pense, est-ce qu'on tente de nous rendre fous à force de «chacun à sa manière et vive l'anarchie»?
C'est vous qui mélangez tout et qui faites des confusions. Et vous tentez de semer la zizanie.
Au passage, ces commandes n'ont rien à voir avec bash et sont indépendantes. Là aussi confusion.
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais permis que les choses se passent ainsi.
Ah d'accord, c'était donc un troll. Tout s'explique. Bref, vraiment n'importe quoi.
Je l'ai déjà dit et ej le répète, je pense que Linux manque de suits.
Vous pensez très mal. C'est vous qui manquez de logique dans votre raisonement et dans votre analyse.
Enfin, n'étant pas expert, je me trompe peut-être.
Oui et ça se voit.
J'attends vos commentaires.
C'est fait.
Un dernier quand même pour la forme : le rapport dans tout ça avec Linux et la charte du groupe ? La prochaine fois abstenez vous.
-- TiChou
X.B
-ir option
Non, option*s*. grumphhhhh
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage. Oupsssss il est tard ...
Pour la postérité : l'option -r indique à grep de descendre dans les c'est nouveau ça ? c'est dans le grep de BSD ?
répertoires ; ainsi, voyant . comme fichier à examiner, il va constater que c'est un répertoire et examiner récursivement tous les fichiers qu'il contient. Ahhh oui, ça marche sur ma linux-box ... zarbi! quoi que :
Mais J'ai des excuses j'ai appris les commandes shell sur sunos ... or leur grep n'a meme pas l'option -r (/usr/bin/grep [ -bchilnsvw ]) qui je le reconnais, m'a bien manquée, maintenant que je l'aperçois ... J'aime bien les GNUseries !
-ir option
Non, option*s*.
grumphhhhh
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage.
Oupsssss il est tard ...
Pour la postérité : l'option -r indique à grep de descendre dans les
c'est nouveau ça ? c'est dans le grep de BSD ?
répertoires ; ainsi, voyant . comme fichier à examiner, il va constater
que c'est un répertoire et examiner récursivement tous les fichiers
qu'il contient.
Ahhh oui, ça marche sur ma linux-box ... zarbi! quoi que :
Mais J'ai des excuses j'ai appris les commandes shell sur sunos ... or leur
grep n'a meme pas l'option -r (/usr/bin/grep [ -bchilnsvw ]) qui je le
reconnais, m'a bien manquée, maintenant que je l'aperçois ... J'aime bien
les GNUseries !
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage. Oupsssss il est tard ...
Pour la postérité : l'option -r indique à grep de descendre dans les c'est nouveau ça ? c'est dans le grep de BSD ?
répertoires ; ainsi, voyant . comme fichier à examiner, il va constater que c'est un répertoire et examiner récursivement tous les fichiers qu'il contient. Ahhh oui, ça marche sur ma linux-box ... zarbi! quoi que :
Mais J'ai des excuses j'ai appris les commandes shell sur sunos ... or leur grep n'a meme pas l'option -r (/usr/bin/grep [ -bchilnsvw ]) qui je le reconnais, m'a bien manquée, maintenant que je l'aperçois ... J'aime bien les GNUseries !
Nicolas George
"X.B" wrote in message <40e31fb4$0$6621$:
c'est nouveau ça ? c'est dans le grep de BSD ?
Il n'y a pas de grep BSD.
Ah, si, tiens, OpenBSD a son propre grep depuis quelques temps, et il supporte l'option -r. Ça ne va plus, ça, depuis quand BSD se met-il à avoir les options utiles dans des trucs qu'ils n'ont pas pompé sur GNU ?
"X.B" wrote in message <40e31fb4$0$6621$636a15ce@news.free.fr>:
c'est nouveau ça ? c'est dans le grep de BSD ?
Il n'y a pas de grep BSD.
Ah, si, tiens, OpenBSD a son propre grep depuis quelques temps, et il
supporte l'option -r. Ça ne va plus, ça, depuis quand BSD se met-il à
avoir les options utiles dans des trucs qu'ils n'ont pas pompé sur GNU ?
Ah, si, tiens, OpenBSD a son propre grep depuis quelques temps, et il supporte l'option -r. Ça ne va plus, ça, depuis quand BSD se met-il à avoir les options utiles dans des trucs qu'ils n'ont pas pompé sur GNU ?
GP
Nicolas George wrote:
"X.B" wrote in message <40e31089$0$6603$:
-ir option
Non, option*s*.
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage.
Et pourtant, elle tourne, comme disait l'autre. Faut dire que j'ai tout un avantage: celui d'avoir pouvoir pu tenter l'expérience.
Pour la postérité : l'option -r indique à grep de descendre dans les répertoires ; ainsi, voyant . comme fichier à examiner, il va constater que c'est un répertoire et examiner récursivement tous les fichiers qu'il contient.
L'autre option, sans descendre dans les répertoires, étant:
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce tout chamboulé?
GP
Nicolas George wrote:
"X.B" wrote in message <40e31089$0$6603$636a15ce@news.free.fr>:
-ir option
Non, option*s*.
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage.
Et pourtant, elle tourne, comme disait l'autre. Faut dire que j'ai tout un
avantage: celui d'avoir pouvoir pu tenter l'expérience.
Pour la postérité : l'option -r indique à grep de descendre dans les
répertoires ; ainsi, voyant . comme fichier à examiner, il va constater
que c'est un répertoire et examiner récursivement tous les fichiers
qu'il contient.
L'autre option, sans descendre dans les répertoires, étant:
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait
remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce tout
chamboulé?
. n'est pas un file mais un path : ça ne peut pas marcher
Et pourtant ça marche. Dommage.
Et pourtant, elle tourne, comme disait l'autre. Faut dire que j'ai tout un avantage: celui d'avoir pouvoir pu tenter l'expérience.
Pour la postérité : l'option -r indique à grep de descendre dans les répertoires ; ainsi, voyant . comme fichier à examiner, il va constater que c'est un répertoire et examiner récursivement tous les fichiers qu'il contient.
L'autre option, sans descendre dans les répertoires, étant:
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce tout chamboulé?
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce tout chamboulé? grep [options] PATTERN [FILE...]
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait
remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce
tout chamboulé?
grep [options] PATTERN [FILE...]
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce tout chamboulé? grep [options] PATTERN [FILE...]
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce tout chamboulé?
je ne vois rien de chamboulé ... qui remplace quoi et où ?
Essaie de lire le fil avant de répondre. Je ne peux pas tout repiquer à chaque fois. Je veux dire chamboulé par rapport à find.
Se peut-il que tu cherches tellement à t'opposer à tout ce que je dis que tu en sois venu à écrire n'importe quoi, comme dans ton message précédent à mon endroit.
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait
remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce
tout chamboulé?
je ne vois rien de chamboulé ... qui remplace quoi et où ?
Essaie de lire le fil avant de répondre. Je ne peux pas tout repiquer à chaque
fois. Je veux dire chamboulé par rapport à find.
Se peut-il que tu cherches tellement à t'opposer à tout ce que je dis que tu en
sois venu à écrire n'importe quoi, comme dans ton message précédent à mon endroit.
Seulement, fichier ou path, ça ne change rien à l'affaire, l'un devrait remplacer l'autre au même endroit dans la commende. Alors, pourquoi est-ce tout chamboulé?
je ne vois rien de chamboulé ... qui remplace quoi et où ?
Essaie de lire le fil avant de répondre. Je ne peux pas tout repiquer à chaque fois. Je veux dire chamboulé par rapport à find.
Se peut-il que tu cherches tellement à t'opposer à tout ce que je dis que tu en sois venu à écrire n'importe quoi, comme dans ton message précédent à mon endroit.
GP
TiChou
Dans le message <news:, *GrandPlouc* tapota sur f.c.o.l.configuration :
Essaie de lire le fil avant de répondre. Je ne peux pas tout repiquer à chaque fois. Je veux dire chamboulé par rapport à find.
Se peut-il que tu cherches tellement à t'opposer à tout ce que je dis que tu en sois venu à écrire n'importe quoi, comme dans ton message précédent à mon endroit.
Et vous, vous avez fini de nous casser les pieds ? Aller troller ailleurs, on a que faire de vos imbécilités pour ne pas dire autre chose !
-- TiChou
Dans le message <news:10e6kdu6u91tc00@corp.supernews.com>,
*GrandPlouc* tapota sur f.c.o.l.configuration :
Essaie de lire le fil avant de répondre. Je ne peux pas tout repiquer à
chaque fois. Je veux dire chamboulé par rapport à find.
Se peut-il que tu cherches tellement à t'opposer à tout ce que je dis que
tu en sois venu à écrire n'importe quoi, comme dans ton message précédent
à mon endroit.
Et vous, vous avez fini de nous casser les pieds ? Aller troller ailleurs,
on a que faire de vos imbécilités pour ne pas dire autre chose !
Dans le message <news:, *GrandPlouc* tapota sur f.c.o.l.configuration :
Essaie de lire le fil avant de répondre. Je ne peux pas tout repiquer à chaque fois. Je veux dire chamboulé par rapport à find.
Se peut-il que tu cherches tellement à t'opposer à tout ce que je dis que tu en sois venu à écrire n'importe quoi, comme dans ton message précédent à mon endroit.
Et vous, vous avez fini de nous casser les pieds ? Aller troller ailleurs, on a que faire de vos imbécilités pour ne pas dire autre chose !
-- TiChou
news
GP wrote:
grep [options] PATTERN [FILE...] find [path...] [expression] De find à grep, on constate que tout est chamboulé.
cela dit en reflechissant un peu on peut se douter que expression c'est pas PATTERN, et que les options penvent rentrer dans l'expression. C'est pas le cas pour le path. En cas de toute, il y'a toujours de la documentation...
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais permis que les choses se passent ainsi.
oui c'est vrai, c'est bien pratique d'utiliser un outil sans avoir a reflechir. Ils y'arrivent si bien, que certains de leurs clients ne pensent pas que ca puisse etre different (mieux ou moins bien ca depend des cas) ...
GP wrote:
grep [options] PATTERN [FILE...]
find [path...] [expression]
De find à grep, on constate que tout est chamboulé.
cela dit en reflechissant un peu on peut se douter que expression c'est
pas PATTERN, et que les options penvent rentrer dans l'expression. C'est
pas le cas pour le path.
En cas de toute, il y'a toujours de la documentation...
Juste au niveau des commandes, les "suits" de Microsoft n'auraient
jamais permis que les choses se passent ainsi.
oui c'est vrai, c'est bien pratique d'utiliser un outil sans avoir a
reflechir. Ils y'arrivent si bien, que certains de leurs clients ne
pensent pas que ca puisse etre different (mieux ou moins bien ca depend
des cas) ...
grep [options] PATTERN [FILE...] find [path...] [expression] De find à grep, on constate que tout est chamboulé.
cela dit en reflechissant un peu on peut se douter que expression c'est pas PATTERN, et que les options penvent rentrer dans l'expression. C'est pas le cas pour le path. En cas de toute, il y'a toujours de la documentation...
Juste au niveau des commandes, les "suits" de Microsoft n'auraient jamais permis que les choses se passent ainsi.
oui c'est vrai, c'est bien pratique d'utiliser un outil sans avoir a reflechir. Ils y'arrivent si bien, que certains de leurs clients ne pensent pas que ca puisse etre different (mieux ou moins bien ca depend des cas) ...
