Dans les années 1990, j'utilisais " *.* "pour représenter n'importe quel nom de fichier sous MS-DOS, mais j'ai vu plus de scripts utilisant seulement " * " de nos jours. Est-ce que cela fait une différence de choisir l'un ou l'autre ?
Réponses
Trop de publicités?
Le nom et l'extension du fichier ont été a champ unique depuis que Windows 95 et NT 3.5 ont introduit la prise en charge des "noms de fichiers longs", et que les correspondances de caractères génériques sont effectuées sur l'ensemble du nom de fichier en une seule fois. Par conséquent, vous pouvez avoir un nom de fichier sans points (ce qui est peut-être rare pour les fichiers, mais très courant pour les dossiers/répertoires) et à première vue *.* ne correspondrait pas à de tels fichiers.
Anciens scripts utilisant des *.* volonté fonctionnent toujours en raison du code de compatibilité - si le caractère générique se termine par .* , cette partie est ignorés par le système d'exploitation. (Ainsi, si vous souhaitez faire correspondre spécifiquement des fichiers avec une extension, je suppose que vous auriez besoin *.?* pour cela).
Si vous écrivez des scripts pour les versions modernes de Windows, suivez leurs conventions, no Conventions MS-DOS. (Notez qu'à partir de Windows NT, les scripts .bat sont no interprété par MS-DOS, mais par cmd.exe (un programme Win32 natif).
Sous Linux et divers autres Unixen, le nom et l'extension n'ont jamais été séparés en premier lieu, et il y a n'est pas une magie particulière pour faire *.* travail, donc * est le seul choix qui ait du sens.
laura
Points
101
Il est probablement utile de mentionner que les shells unixy/posixy comme bourne Shell, bash, ksh, zsh, etc. font de l'expansion de caractères génériques (des caractères globaux comme * , ? , [range] , [!range] et d'autres expansions comme les accolades et les globs étendus) pour compiler une liste d'arguments avant la commande est exécutée. Cette expansion est donc effectuée par le Shell et non par la commande dont il peut être l'argument.
C'est-à-dire que le Shell est responsable de ce qui suit * , *.* 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.xlsxCe n'est pas le cas dans CMD (et de même pour les utilitaires powershell ), car il transmet les caractères globaux tels quels à la commande exécutée - et l'expansion relève donc de la responsabilité de la commande/utilité et non du Shell. En fin de compte, ce que *.* ou * est laissée à l'utilitaire, ce qui lui permet de se conformer (ou non) aux conventions - c'est pourquoi les utilitaires de CMD tels que dir *.* correspond également (sans doute de manière incorrecte, mais en préservant les attentes) à des fichiers sans extension.
Je pense qu'il est prudent de résumer la situation de la manière suivante.
- Sous CMD, cela dépend de l'utilitaire.
- Sous PowerShell, les utilitaires qui utilisent la fonction Classe WildCardPattern fournira un sous-ensemble cohérent de comportements posixy.
