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.
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. "par rapport à find" ne me semble pas trop long a ecrire ; sans pour autant
tout recopier, essaie juste d'etre explicite ...
un peu d'histoire ne nuit pas :
-grep : recherche de patternes dans un fichier ; ainsi grep pour fonctionner n'a besoin que de du patterne et de la liste de fichiers a "screener" : c'est le grep canonique ... Pour des raisons d'usage, les developeurs gnu ont rajouté une option : -r pour recursif, et une ellipse : quand au lieu d'indiquer une liste de fichier on indique un repertoire alors c'est equivallent a la liste de tous les fichiers des repertoir visités ; donc une forme canonique devrait etre grep -ir "IPv6" * cette synthaxe est absurde etant donné que l'on raisonne en repertoire avec avec l'option -r donc on surcharge la liste de fichier par une liste de repertoire.
-find : en fait il devrait y avoir une option, au meme titre que -name, -type, -exec : -dir pour preciser le repertoir de depart ; mais comme il est idiot de faire une recherche de fichiers sans indiquer le point de depart, l'option -dir devient systematique et donc dans sa grande sagesse, l'equipe qui a developpé find a supprimé l'option -dir et a fixé la synthaxe de find en : find PATH expression
donc find et grep ne sont pas synthaxé pareil car ils ne font pas la meme chose et ne repondent pas à la même logique d'usage :
si tu choisis une forme grep PATH|FILE expression alors l'expression qui est specifique a la recherche deviend preponderante a la liste de fichiers, ce qui est plutot anti naturelle :
est d'un usage assez courant ; et la synthaxe que tu proposerais ne le permettrait plus (man xargs).
En fait quand je faisais référence a l'age d'unix, ce n'était pas pour dire qu'il y a 25 ans uns bande d'associaux caractériels psychorigides se sont réunis pour proposer une alternative à multics en creeant les base d'un OS, d'un shell et un ensemble de commandes imbitables, mais que si depuis 25 ans la synthaxe etait débile, alors elle aurait ete corrigee depuis ; cela a déjà ete fait :il y a des commandes GNU dont la synthaxe n'est pas identique aux version initial que l'on trouve dans les unix berkeley :
sur sunos : man ifconfig NAME ifconfig - configure network interface parameters
d'ailleurs je ne suis pas sur qu'une forme l'emporte sur l'autre
Mais si pour toi appeler un man pour te rememorer une synthaxe exact est un exercice hors de ta portée, le plus simple que tu es a faire est d'ecrire un wrapper qui appelle ces commandes selon la norme que te convient le mieux ...
toutes les approximations, que j'assume, sont essentiellement du a une volonte de simplifier ... Mais n'hesitez pas a corriger (gentiement?) ce qui serait trop approximé.
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.
"par rapport à find" ne me semble pas trop long a ecrire ; sans pour autant
tout recopier, essaie juste d'etre explicite ...
un peu d'histoire ne nuit pas :
-grep : recherche de patternes dans un fichier ; ainsi grep pour fonctionner
n'a besoin que de du patterne et de la liste de fichiers a "screener" :
c'est le grep canonique ...
Pour des raisons d'usage, les developeurs gnu ont rajouté une option : -r
pour recursif, et une ellipse : quand au lieu d'indiquer une liste de
fichier on indique un repertoire alors c'est equivallent a la liste de tous
les fichiers des repertoir visités ; donc une forme canonique devrait etre
grep -ir "IPv6" *
cette synthaxe est absurde etant donné que l'on raisonne en repertoire
avec avec l'option -r donc on surcharge la liste de fichier par une liste
de repertoire.
-find : en fait il devrait y avoir une option, au meme titre que -name,
-type, -exec : -dir pour preciser le repertoir de depart ; mais comme il
est idiot de faire une recherche de fichiers sans indiquer le point de
depart, l'option -dir devient systematique et donc dans sa grande sagesse,
l'equipe qui a developpé find a supprimé l'option -dir et a fixé la
synthaxe de find en :
find PATH expression
donc find et grep ne sont pas synthaxé pareil car ils ne font pas la meme
chose et ne repondent pas à la même logique d'usage :
si tu choisis une forme
grep PATH|FILE expression
alors l'expression qui est specifique a la recherche deviend preponderante a
la liste de fichiers, ce qui est plutot anti naturelle :
est d'un usage assez courant ; et la synthaxe que tu proposerais ne le
permettrait plus (man xargs).
En fait quand je faisais référence a l'age d'unix, ce n'était pas pour dire
qu'il y a 25 ans uns bande d'associaux caractériels psychorigides se sont
réunis pour proposer une alternative à multics en creeant les base d'un OS,
d'un shell et un ensemble de commandes imbitables, mais que si depuis 25
ans la synthaxe etait débile, alors elle aurait ete corrigee depuis ; cela
a déjà ete fait :il y a des commandes GNU dont la synthaxe n'est pas
identique aux version initial que l'on trouve dans les unix berkeley :
sur sunos :
man ifconfig
NAME
ifconfig - configure network interface parameters
d'ailleurs je ne suis pas sur qu'une forme l'emporte sur l'autre
Mais si pour toi appeler un man pour te rememorer une synthaxe exact est un
exercice hors de ta portée, le plus simple que tu es a faire est d'ecrire
un wrapper qui appelle ces commandes selon la norme que te convient le
mieux ...
toutes les approximations, que j'assume, sont essentiellement du a une
volonte de simplifier ... Mais n'hesitez pas a corriger (gentiement?) ce
qui serait trop approximé.
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. "par rapport à find" ne me semble pas trop long a ecrire ; sans pour autant
tout recopier, essaie juste d'etre explicite ...
un peu d'histoire ne nuit pas :
-grep : recherche de patternes dans un fichier ; ainsi grep pour fonctionner n'a besoin que de du patterne et de la liste de fichiers a "screener" : c'est le grep canonique ... Pour des raisons d'usage, les developeurs gnu ont rajouté une option : -r pour recursif, et une ellipse : quand au lieu d'indiquer une liste de fichier on indique un repertoire alors c'est equivallent a la liste de tous les fichiers des repertoir visités ; donc une forme canonique devrait etre grep -ir "IPv6" * cette synthaxe est absurde etant donné que l'on raisonne en repertoire avec avec l'option -r donc on surcharge la liste de fichier par une liste de repertoire.
-find : en fait il devrait y avoir une option, au meme titre que -name, -type, -exec : -dir pour preciser le repertoir de depart ; mais comme il est idiot de faire une recherche de fichiers sans indiquer le point de depart, l'option -dir devient systematique et donc dans sa grande sagesse, l'equipe qui a developpé find a supprimé l'option -dir et a fixé la synthaxe de find en : find PATH expression
donc find et grep ne sont pas synthaxé pareil car ils ne font pas la meme chose et ne repondent pas à la même logique d'usage :
si tu choisis une forme grep PATH|FILE expression alors l'expression qui est specifique a la recherche deviend preponderante a la liste de fichiers, ce qui est plutot anti naturelle :
est d'un usage assez courant ; et la synthaxe que tu proposerais ne le permettrait plus (man xargs).
En fait quand je faisais référence a l'age d'unix, ce n'était pas pour dire qu'il y a 25 ans uns bande d'associaux caractériels psychorigides se sont réunis pour proposer une alternative à multics en creeant les base d'un OS, d'un shell et un ensemble de commandes imbitables, mais que si depuis 25 ans la synthaxe etait débile, alors elle aurait ete corrigee depuis ; cela a déjà ete fait :il y a des commandes GNU dont la synthaxe n'est pas identique aux version initial que l'on trouve dans les unix berkeley :
sur sunos : man ifconfig NAME ifconfig - configure network interface parameters
d'ailleurs je ne suis pas sur qu'une forme l'emporte sur l'autre
Mais si pour toi appeler un man pour te rememorer une synthaxe exact est un exercice hors de ta portée, le plus simple que tu es a faire est d'ecrire un wrapper qui appelle ces commandes selon la norme que te convient le mieux ...
toutes les approximations, que j'assume, sont essentiellement du a une volonte de simplifier ... Mais n'hesitez pas a corriger (gentiement?) ce qui serait trop approximé.
GP
news wrote:
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.
Bien justement. N'est-ce pas inutilement compliqué que de faire rentrer les options dans l'expression? Où est l'avantage autant pratique que didactique?
GP
news wrote:
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.
Bien justement. N'est-ce pas inutilement compliqué que de faire rentrer les
options dans l'expression? Où est l'avantage autant pratique que didactique?
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.
Bien justement. N'est-ce pas inutilement compliqué que de faire rentrer les options dans l'expression? Où est l'avantage autant pratique que didactique?
GP
X.B
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.
Bien justement. N'est-ce pas inutilement compliqué que de faire rentrer et te remettre en cause, tu y a pensé ?
les options dans l'expression? Où est l'avantage autant pratique que didactique?
au risque de me repeter :
si tu choisis une forme grep PATH|FILE expression alors l'expression qui est specifique a la recherche devient preponderante a la liste de fichiers, ce qui est plutot anti naturelle :
est d'un usage assez courant ; et la synthaxe que tu proposes ne le permets plus (man xargs). donc la synthaxe grep [options] PATTERN [FILE...] est appropiée a l'usage general de grep ; ou plutot il a d'abord ete conçu pour faire ça.
Par contre pour find comme le point de depart de la recherche est obligatoire, il parait naturel que cet argument suive la commande : find PATH expression ou l'expression n'est pas forcement une suite d'option mais peut etre egalement une serie d'expression rationnelle par options :
tu vois bien qu'il s'agit bien d'une expression qu'evalue find apres le "PATH" d'un autre coté tu aurais man find en voyant ça (*) tu n'aurais meme pas posé l'expression ...
(*) OPÉRATEURS Dans l'ordre de priorité décroissante :
( expr ) Force la priorité.
! expr Vrai si expr est fausse.
-not expr Comme ! expr.
expr1 expr2 ET (implicite) ; expr2 n'est pas évaluée si expr1 est fausse.
expr1 -a expr2 Comme expr1 expr2.
expr1 -and expr2 Comme expr1 expr2.
expr1 -o expr2 OU ; expr2 n'est pas évaluée si expr1 est vraie.
expr1 -or expr2 Comme expr1 -o expr2.
expr1 , expr2 Liste ; expr1 et expr2 sont toujours évaluées toutes les deux. La valeur de expr1 est ignorée ; la valeur de la liste est celle de expr2.
etc, etc
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.
Bien justement. N'est-ce pas inutilement compliqué que de faire rentrer
et te remettre en cause, tu y a pensé ?
les options dans l'expression? Où est l'avantage autant pratique que
didactique?
au risque de me repeter :
si tu choisis une forme
grep PATH|FILE expression
alors l'expression qui est specifique a la recherche devient preponderante a
la liste de fichiers, ce qui est plutot anti naturelle :
est d'un usage assez courant ; et la synthaxe que tu proposes ne le
permets plus (man xargs). donc la synthaxe
grep [options] PATTERN [FILE...]
est appropiée a l'usage general de grep ; ou plutot il a d'abord ete conçu
pour faire ça.
Par contre pour find comme le point de depart de la recherche est
obligatoire, il parait naturel que cet argument suive la commande :
find PATH expression
ou l'expression n'est pas forcement une suite d'option mais peut etre
egalement une serie d'expression rationnelle par options :
tu vois bien qu'il s'agit bien d'une expression qu'evalue find apres le
"PATH"
d'un autre coté tu aurais man find en voyant ça (*) tu n'aurais meme pas
posé l'expression ...
(*) OPÉRATEURS
Dans l'ordre de priorité décroissante :
( expr )
Force la priorité.
! expr Vrai si expr est fausse.
-not expr
Comme ! expr.
expr1 expr2
ET (implicite) ; expr2 n'est pas évaluée si expr1 est fausse.
expr1 -a expr2
Comme expr1 expr2.
expr1 -and expr2
Comme expr1 expr2.
expr1 -o expr2
OU ; expr2 n'est pas évaluée si expr1 est vraie.
expr1 -or expr2
Comme expr1 -o expr2.
expr1 , expr2
Liste ; expr1 et expr2 sont toujours évaluées toutes les
deux. La valeur de expr1 est ignorée ; la valeur de la liste
est celle de expr2.
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.
Bien justement. N'est-ce pas inutilement compliqué que de faire rentrer et te remettre en cause, tu y a pensé ?
les options dans l'expression? Où est l'avantage autant pratique que didactique?
au risque de me repeter :
si tu choisis une forme grep PATH|FILE expression alors l'expression qui est specifique a la recherche devient preponderante a la liste de fichiers, ce qui est plutot anti naturelle :
est d'un usage assez courant ; et la synthaxe que tu proposes ne le permets plus (man xargs). donc la synthaxe grep [options] PATTERN [FILE...] est appropiée a l'usage general de grep ; ou plutot il a d'abord ete conçu pour faire ça.
Par contre pour find comme le point de depart de la recherche est obligatoire, il parait naturel que cet argument suive la commande : find PATH expression ou l'expression n'est pas forcement une suite d'option mais peut etre egalement une serie d'expression rationnelle par options :
tu vois bien qu'il s'agit bien d'une expression qu'evalue find apres le "PATH" d'un autre coté tu aurais man find en voyant ça (*) tu n'aurais meme pas posé l'expression ...
(*) OPÉRATEURS Dans l'ordre de priorité décroissante :
( expr ) Force la priorité.
! expr Vrai si expr est fausse.
-not expr Comme ! expr.
expr1 expr2 ET (implicite) ; expr2 n'est pas évaluée si expr1 est fausse.
expr1 -a expr2 Comme expr1 expr2.
expr1 -and expr2 Comme expr1 expr2.
expr1 -o expr2 OU ; expr2 n'est pas évaluée si expr1 est vraie.
expr1 -or expr2 Comme expr1 -o expr2.
expr1 , expr2 Liste ; expr1 et expr2 sont toujours évaluées toutes les deux. La valeur de expr1 est ignorée ; la valeur de la liste est celle de expr2.
