Pourquoi le shell effectue-t-il l'expansion du chemin d'accès aux utilitaires?

1

Cette question est une suite de https://stackoverflow.com/questions/7136899/how-does-grep-work

Il semble que l’ shellextension de *.*tous les fichiers applicables / disponibles soit fournie aux utilitaires tels que grep.

Pourquoi faut-il le shellfaire? Pourquoi ne pas laisser l'expansion du chemin d'accès à l'utilitaire lui-même?

c shell unix grep

— hari
source

1

Pourquoi les fabricants de marteaux vissent-ils la tête au manche? Pourquoi ne pas laisser cela à l'artisan?

1

C’est particulièrement amusant si vous avez un fichier nommé -rfet que vous utilisez rm...

— Kerrek SB

2

Si vous venez d’un environnement Windows, il faut savoir que le joker correspondant à "tous les fichiers non cachés du répertoire en cours" est *non *.*. Il est très courant sous Unix / Linux d'avoir des fichiers sans points dans leurs noms. Le système utilise beaucoup moins les extensions de fichier pour décider du type de fichier qu’il contient. Par exemple, vous verrez généralement "README" plutôt que "README.TXT".

— Keith Thompson

1

et dans Windows, le shell ne fait pas l'expansion que l'utilitaire fait. Permettant ainsi de renommer * .txt * .bak

— Mark

@ Mark: Merci. Windows est vraiment un beau morceau de code: D

— hari

4

Une des raisons est que chaque utilitaire devrait implémenter cette fonctionnalité. Si le shell le fait, il n'est implémenté qu'une seule fois.

— ennuikiller
source

2

Parce que si le shell ne fournissait pas cette fonctionnalité, chaque petit utilitaire devrait l'implémenter.

Cela garantit également que l'extension fonctionne exactement de la même manière pour chaque commande.

BTW le développement ne se produit pas seulement dans les arguments de commande, il peut se produire n'importe où dans un script shell; par exemple:

for file in *.c; do something; done

— Arnaud Le Blanc
source

Pas tout à fait n'importe où, cependant: dans case $foo in *) command;; esacle * est syntaxiquement un motif, pas un caractère glob pour l'expansion du chemin. Votre page de manuel shell ou votre spécification POSIX contient tous les détails sanglants.

— Jens

2

Si le shell ne fournissait pas cette fonctionnalité, chaque utilitaire devrait alors implémenter sa propre fonctionnalité générique (et la plupart ne s'en lasseraient probablement pas). Dans l’état actuel des choses, chaque utilitaire ne doit traiter que des noms de fichiers individuels, ce qui est beaucoup plus simple.

1

Parce que la vie serait horriblement cauchemardesque si ce n'était pas le cas.

— Keith Thompson
source

Ok, j'avoue que ce n'est pas très constructif.

— Keith Thompson

1

C’est la philosophie Unix qui consiste à "avoir un seul outil pour faire une chose". Pourquoi quelqu'un voudrait-il que ce code soit répété dans tous les utilitaires? Quel est l'intérêt d'avoir chaque utilitaire après main (), appelez expand_pathnames ()? A quoi sert-il d'imposer ce fardeau non seulement aux programmes C, mais également à tous les langages compilés et à tous les langages de script? Cela ne sert à rien. C’est pourquoi Microsoft et l’abomination cmd.exe s’y sont trompés dès le premier jour :-)

BTW, si vous souhaitez désactiver la suppression du nom de fichier, vous pouvez le faire avec

$ set -f
$ echo *
*
$ set +f
$ echo *
readme foo.o bar.txt

— Jens
source