Back in the 1990s, I would use "*.*" to represent any filename in MS-DOS, but I've seen more scripts using just "*" these days. Does it actually make any difference which one I use?

  • 9
    While it is true that * and *.* are now equivalent for cmd internal commands and modern command-line utilities, some older utilities that take file mask parameters may use the older file matching functions, and for them the masks will not be equivalent. – AFH Jul 3 '17 at 11:01
  • @AFH I do not think that the tokens are equal. The *.* token shouldn't return extensionless files. – tuskiomi Jul 11 '17 at 18:29
  • 1
    @tuskiomi - I would agree with you that *.* shouldn't return extensionless files. Unfortunately it does. See Grawity's answer. – AFH Jul 11 '17 at 19:40

File name and extension have been a single field ever since Windows 95 and NT 3.5 introduced "long file name" support, and wildcard matches are done against the entire filename at once. As a result, you can have a filename with no dots in it (perhaps rare for files, but very common for folders/directories) and at first glance *.* wouldn't actually match such files.

Old scripts using *.* will still work because of compatibility code – if the wildcard ends with .*, that part is ignored by the OS. (So if you wanted to specifically match files with an extension, I guess you would need *.?* for that.)

But it's not something you should rely on; if you're writing scripts for modern Windows versions, follow their conventions, not MS-DOS conventions. (Note that as of Windows NT, .bat scripts are not interpreted by MS-DOS anymore but by cmd.exe, a native Win32 program.)

On Linux and various other Unixen, name & extension have never been separate in the first place, and there isn't any special magic to make *.* work, so * is the only choice that makes sense.

  • 14
    "Let's make it harder to filter files with extensions! Yay!" -Anonymous Microsoft Developer – John Hamilton Jul 3 '17 at 11:27
  • 50
    "Let's break the millions of existing batch scripts for everyone! Yay!" -No Microsoft Developer, Ever – grawity Jul 3 '17 at 13:15
  • 3
    ISTR that on some old versions of DOS, * would only match filenames without an extension. The 'safe' way to be compatible with both was to use **. – Random832 Jul 3 '17 at 13:51
  • 8
    The OP is about Windows, but since you've mentioned Linux: In some shells (Bash, for example), * does (by default) not match hidden filenames (starting with a .). – Florian Brucker Jul 3 '17 at 14:37
  • 4
    For some values of "OS level"... It's really a shell (Explorer) concept in Windows, too – the kernel doesn't care about .exe on executables, nor anything else. Whether Windows Explorer is more "OS level" than e.g. Nautilus in Linux can be argued. – grawity Jul 3 '17 at 21:53

It's probably worth mentioning that the unixy/posixy shells like bourne shell, bash, ksh, zsh, etc do wildcard expansion (of glob characters like *, ?, [range], [!range] and other expansions like braces and extended globs) to compile a list of arguments before the command is executed. So this expansion is done by the shell not the command to which these may be arguments of.

i.e. The shell is responsible for what *, *.* expands to

 $ 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

This is not the case in CMD (and similarly for powershell utilities) as it passes the glob characters verbatim in to the executed command - and so expansion is the responsibility of the command/utility and not the shell. So ultimately, what *.* or * means is left to the utility leaving it to conform (or not) to conventions - which is why CMD's utilities like dir *.* also matched (arguably incorrectly yet preserving expectations) files without extensions.

I believe it's safe to summarize this way.

  • Under CMD it depends on the utility.
  • Under PowerShell, utilities that make use of the WildCardPattern Class will provide a consistent subset of posixy behaviours.
  • Another difference is that under CMD, most programs actually forward the raw wildcard to the kernel (FindFirstFile), while glob on Linux just grabs the full list and does filtering in userspace. – grawity Jul 3 '17 at 16:51
  • When you run * on a directory with a million files, the command will complain of too many parameters. In the worst case, it could silently drop the tail of the list. In those cases, you need to pipe two or more commands, or save a list of filenames in a file, so other process can read the list. – Enric Naval Jul 4 '17 at 8:05
  • 3
    @grawity To be more accurate, the filtering is done by the file system driver on Windows. This is especially useful on network file systems (especially back when you could be running a 8 kb line to a remote file system), but it also means you can't do arbitrary searches as well as explicitly supported searches. The implications of this have been explored many times on Raymond Chen's blog. FindFirstFile itself is user-mode (both kernel32.dll and ntdll.dll are user-mode libraries - it's part of the Win32 subsystem, not the kernel), but it doesn't really do much. – Luaan Jul 4 '17 at 8:20
  • Ah, I was under the impression that FindFirstFile pretty much directly wrapped a similarly named syscall (like how open(3) in libc just wraps open(2) in Linux kernel). – grawity Jul 4 '17 at 8:34
  • 1
    @cup: Just use quotes to prevent the shell from expanding globs, so you can pass them to commands. e.g. mmv "fred.*" "tom.#1". (The replacement uses #1 instead of *, which has the advantage of letting you re-order fields). mmv isn't installed by default on most systems, but other batch-rename tools often are. See this article about it, and stackoverflow.com/questions/417916/how-to-do-a-mass-rename. – Peter Cordes Jul 4 '17 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.