CMD: *. * Ou juste *?

Dans les années 1990, j’utilisais " *.*" pour représenter tout nom de fichier dans MS-DOS, mais j’ai vu plus de scripts utiliser simplement " *" ces jours-ci. Cela fait-il réellement une différence que j'utilise?

Le nom de fichier et son extension constituent un champ unique depuis que Windows 95 et NT 3.5 ont introduit la prise en charge du "nom de fichier long", et les correspondances avec des caractères génériques sont effectuées en même temps sur le nom de fichier complet. En conséquence, vous pouvez avoir un nom de fichier sans points (peut-être rare pour les fichiers, mais très commun pour les dossiers / répertoires) et à première vue, *.*il ne correspondrait pas à de tels fichiers.

Anciens scripts à l' aide *.* sera encore du travail à cause du code de compatibilité - si les extrémités génériques avec .*, cette partie est ignorée par le système d' exploitation. (Donc, si vous vouliez faire spécifiquement correspondre les fichiers avec une extension, je suppose que vous en auriez besoin *.?*pour cela.)

Mais ce n'est pas quelque chose sur lequel vous devriez compter; si vous écrivez des scripts pour les versions Windows modernes, suivez leurs conventions, et non celles de MS-DOS. (Notez qu'à partir de Windows NT, les scripts .bat ne sont plus interprétés par MS-DOS mais par cmd.exeun programme Win32 natif.)

Sous Linux et beaucoup d’autres Unixen, nom et extension n’ont jamais été séparés, et il n’ya pas de magie particulière pour faire *.*fonctionner, c’est donc *le seul choix qui a du sens.

Il est sans doute mentionner la valeur que le unixy / coquilles posixy comme shell bash, ksh, zsh, etc font expansions génériques (des caractères glob aiment *, ?, [range], [!range]et d' autres extensions comme des accolades et globs étendus) pour dresser la liste des arguments avant la commande est exécuté. Donc, cette expansion est faite par le shell et non par la commande à laquelle ils peuvent être des arguments.

c'est-à-dire que le shell est responsable de quoi *, *.*s'étend à

 $ ls
 file.csv  file.doc  file.pdf  file.txt  file.xlsx  zz-file-without-extension

 $ (set -xv; foo *)   # is actually expanded to the following
   + foo file.csv file.doc file.pdf file.txt file.xlsx zz-file-without-extension

 $ (set -xv; foo *.*)  # note this does not match `zz-file-without-extension`
   + foo file.csv file.doc file.pdf file.txt file.xlsx

Ce n'est pas le cas dans CMD (et de la même manière pour les utilitaires powershell ) car il transmet les caractères globaux mot pour mot à la commande exécutée - et donc le développement est la responsabilité de la commande / utilitaire et non du shell. En fin de compte, ce *.*ou des *moyens est laissée à l'utilitaire en laissant de se conformer (ou non) aux conventions - ce qui explique pourquoi les utilitaires de CMD aiment dir *.*également les fichiers correspondants (sans doute préserver de manière incorrecte encore aux attentes) sans extensions.

Je crois qu'il est prudent de résumer de cette façon.

• Sous CMD, cela dépend de l'utilitaire.
• Sous PowerShell, les utilitaires utilisant la classe WildCardPattern fournissent un sous-ensemble cohérent de comportements posixy.