{"id":105433,"date":"2021-07-13T07:00:00","date_gmt":"2021-07-13T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=105433"},"modified":"2021-07-14T07:07:11","modified_gmt":"2021-07-14T14:07:11","slug":"20210713-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20210713-00\/?p=105433","title":{"rendered":"How did copying and renaming with wildcards work in MS-DOS?"},"content":{"rendered":"

Some time ago, I described how wildcards worked in MS-DOS<\/a>, specifically how wildcards participate in pattern matching. Today, I’ll look at how wildcards participate in copying and renaming.<\/p>\n

First, the source and destination patterns are expanded into the eleven-character FCB format by the algorithm I described in that earlier article.<\/p>\n

Next, the directory is searched for files that match the source pattern.<\/p>\n

Once such a match is found, the fun begins: Applying the rename pattern.<\/p>\n

The way it works is that the rename pattern is used to produce the resulting file name, except that if a question mark is encountered in the rename pattern, then the corresponding character from the source file name is copied.<\/p>\n

Here’s an example with renaming, although the same exercise also applies to copying:<\/p>\n

REN ABC*.D?F GHIJ*.KL?\r\n<\/pre>\n
The source and destination patterns are<\/p>\n\n\n\n\n\n
\u00a0<\/th>\nHuman-readable<\/th>\nParsed pattern<\/th>\n<\/tr>\n
Source<\/td>\nABC*.D?F<\/tt><\/td>\nA<\/tt><\/td>\nB<\/tt><\/td>\nC<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\nD<\/tt><\/td>\n?<\/tt><\/td>\nF<\/tt><\/td>\n<\/tr>\n
Destination<\/td>\nGHIJ*.KL?<\/tt><\/td>\nG<\/tt><\/td>\nH<\/tt><\/td>\nI<\/tt><\/td>\nJ<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\nK<\/tt><\/td>\nL<\/tt><\/td>\n?<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Suppose we have a file ABC12345.D6F<\/tt> that matches the source pattern. How do we transform it according to the destination pattern?<\/p>\n
Simple: Stack the original file name and the destination pattern on top of each other. For each character of the output, take the corresponding character from the destination pattern, unless it is a question mark, in which case you take the corresponding character from the original file name.<\/p>\n\n\n\n\n\n\n
\u00a0<\/th>\nHuman-readable<\/th>\nParsed pattern<\/th>\n<\/tr>\n
Actual<\/td>\nABC12345.D6F<\/tt><\/td>\nA<\/tt><\/td>\nB<\/tt><\/td>\nC<\/tt><\/td>\n1<\/tt><\/td>\n2<\/tt><\/td>\n3<\/tt><\/td>\n4<\/tt><\/td>\n5<\/tt><\/td>\nD<\/tt><\/td>\n6<\/tt><\/td>\nF<\/tt><\/td>\n<\/tr>\n
Destination<\/td>\nGHIJ*.KL?<\/tt><\/td>\nG<\/tt><\/td>\nH<\/tt><\/td>\nI<\/tt><\/td>\nJ<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\nK<\/tt><\/td>\nL<\/tt><\/td>\n?<\/tt><\/td>\n<\/tr>\n
Result<\/td>\nGHIJ2345.KLF<\/tt><\/td>\nG<\/tt><\/td>\nH<\/tt><\/td>\nI<\/tt><\/td>\nJ<\/tt><\/td>\n2<\/tt><\/td>\n3<\/tt><\/td>\n4<\/tt><\/td>\n5<\/tt><\/td>\nK<\/tt><\/td>\nL<\/tt><\/td>\nF<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
One way of thinking of this is that you treat the destination pattern as a stencil, with holes punched out where the question marks are. You then overlay the stencil on top of the original file name. The characters from the original file name show through the holes, and what you see is the result.<\/p>\n
\n\n\n\n
G<\/tt><\/td>\nH<\/tt><\/td>\nI<\/tt><\/td>\nJ<\/tt><\/td>\n2<\/tt><\/td>\n3<\/tt><\/td>\n4<\/tt><\/td>\n5<\/tt><\/td>\nK<\/tt><\/td>\nL<\/tt><\/td>\nF<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
This algorithm enabled some simple rename patterns, like changing a file extension:<\/p>\n
REN FRED*.TXT *.DOC\r\n<\/pre>\n
Suppose there is a file called FRED123.TXT<\/tt>. Let’s see what happens:<\/p>\n\n\n\n\n\n\n\n
\u00a0<\/th>\nHuman-readable<\/th>\nParsed pattern<\/th>\n<\/tr>\n
Source<\/td>\nFRED*.*<\/tt><\/td>\nF<\/tt><\/td>\nR<\/tt><\/td>\nE<\/tt><\/td>\nD<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n<\/tr>\n
Match<\/td>\nFRED123.TXT<\/tt><\/td>\nF<\/tt><\/td>\nR<\/tt><\/td>\nE<\/tt><\/td>\nD<\/tt><\/td>\n1<\/tt><\/td>\n2<\/tt><\/td>\n3<\/tt><\/td>\n\u00b7<\/tt><\/td>\nT<\/tt><\/td>\nX<\/tt><\/td>\nT<\/tt><\/td>\n<\/tr>\n
Destination<\/td>\n*.DOC<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\nD<\/tt><\/td>\nO<\/tt><\/td>\nC<\/tt><\/td>\n<\/tr>\n
Result<\/td>\nFRED123.DOC<\/tt><\/td>\nF<\/tt><\/td>\nR<\/tt><\/td>\nE<\/tt><\/td>\nD<\/tt><\/td>\n1<\/tt><\/td>\n2<\/tt><\/td>\n3<\/tt><\/td>\n\u00b7<\/tt><\/td>\nD<\/tt><\/td>\nO<\/tt><\/td>\nC<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Observe that we didn’t have to repeat FRED<\/tt> in the replacement pattern. The asterisk (which parses into question marks) just copies the existing file name, which includes the FRED<\/tt>.<\/p>\n
Does this make sense? Because it does carry its own consequences.<\/p>\n
If you’re not expecting the “copies the existing file name” behavior, and the question marks in the destination don’t match the question marks in the source, the results can be somewhat surprising:<\/p>\n
ren FRED*.* WILMA*.*\r\n<\/pre>\n
Suppose there is a file called FRED123.TXT<\/tt>, and you were hoping to rename it to WILMA123.TXT<\/tt>. Let’s see what happens:<\/p>\n\n\n\n\n\n\n\n
\u00a0<\/th>\nHuman-readable<\/th>\nParsed pattern<\/th>\n<\/tr>\n
Source<\/td>\nFRED*.*<\/tt><\/td>\nF<\/tt><\/td>\nR<\/tt><\/td>\nE<\/tt><\/td>\nD<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n<\/tr>\n
Match<\/td>\nFRED123.TXT<\/tt><\/td>\nF<\/tt><\/td>\nR<\/tt><\/td>\nE<\/tt><\/td>\nD<\/tt><\/td>\n1<\/tt><\/td>\n2<\/tt><\/td>\n3<\/tt><\/td>\n\u00b7<\/tt><\/td>\nT<\/tt><\/td>\nX<\/tt><\/td>\nT<\/tt><\/td>\n<\/tr>\n
Destination<\/td>\nWILMA*.*<\/tt><\/td>\nW<\/tt><\/td>\nI<\/tt><\/td>\nL<\/tt><\/td>\nM<\/tt><\/td>\nA<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n?<\/tt><\/td>\n<\/tr>\n
Result<\/td>\nWILMA23.TXT<\/tt><\/td>\nW<\/tt><\/td>\nI<\/tt><\/td>\nL<\/tt><\/td>\nM<\/tt><\/td>\nA<\/tt><\/td>\n2<\/tt><\/td>\n3<\/tt><\/td>\n\u00b7<\/tt><\/td>\nT<\/tt><\/td>\nX<\/tt><\/td>\nT<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Since WILMA<\/tt> is one character longer than FRED<\/tt>, the question marks don’t line up. After copying WILMA<\/tt> to the result, we reach the first question mark in the destination, which lines up with the second<\/i> question mark in the source, not the first. The character that is copied is the sixth character from the source, which is a 2<\/tt>. The 1<\/tt> from the source is not copied because it was overwritten by the A<\/tt> in WILMA<\/tt>.<\/p>\n
Wildcards are just question marks, and question marks match or copy a single corresponding character. They don’t “go looking around for their buddy question mark”. Computers weren’t that fancy back then.<\/p>\n
We had agreed that the REN FRED*.TXT *.DOC<\/tt> made sense in that it didn’t rename FRED123.TXT<\/tt> to 123.DOC<\/tt>. But that rule that made sense then doesn’t seem to make sense in this more complicated case where we are doing what is more like a search\/replace in the filename.<\/p>\n
It’s important to understand the MS-DOS wildcard copy\/rename algorithm because Windows remains compatible with it, so as not to break existing batch files. We’ll look at this some more  next time<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
By lining up two parallel arrays.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-105433","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"
By lining up two parallel arrays.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105433","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=105433"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105433\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=105433"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=105433"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=105433"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}