"Liviu" <lab...@gmail.c0m> wrote...
>
> I'd be curious about any specifics, if somebody remembered.
Thanks for all replies. In the meantime I've run some searches on
my own. Haven't found definitive proof of a killer bug, but here's
a few pointers to FOR/D/R behaviors one could call questionable.
Any further findings or insight appreciated.
1.
http://groups.google.com/group/alt.msdos.batch.nt/msg/3129991ba99e2f1b
"Ok, so after more testing there are multiple bugs present with /R.
(1)Enumeration of pathspec only regardless of (filename) specification.
(Whatever is inside the () is passed along with the path.)
(2)It only returns actual filespecs if a wildcard is used with
filename."
Both are in fact due to the same rule (2): an item in the control
section of a FOR loop is expanded to one or multiple matches against
actual files/directories _only_ if it contains a wildcard, otherwise it
is passed literally.
This rule may not be obvious upfront, and is not well documented in the
FOR help. Yet, it's been certainly known and used for a long time. For
example, that's what allows the following to quickly cleanup a few
unwanted types.
for %v in (tmp bak log) do del /q *.%v
If the literal tmp, bak, log were to be matched against existing files,
instead, the above would (almost) never work. Still, variations of that
construct are pretty commonplace. IMHO, this is not a bug.
2.
http://blogs.msdn.com/b/oldnewthing/archive/2007/05/11/2532913.aspx#2549194
"Might as well mention "for /r /d %I in (.) do @echo %I" as well, which
seems to be the method that whoever wrote the help text for the for
command recommends. You get names that end in \., but it lists
directories that (*) misses."
The first part about (.) is correct and, indeed, recommended. The note
about (*) missing directories is rather vague. It might refer to the
fact that "FOR /D /R %d in (*)" skips over the current directory, and
also any hidden subdirectories, while "FOR /D /R %d in (.)" includes the
"." current directory and all subdirectories regardless of attributes.
While an undocumented quirk, don't know that I'd call it a bug per se.
3.
http://stackoverflow.com/questions/8366864/windows-7-batch-script-for-command-error-bug
"There seems to be a bug with the Windows 7 batch file 'for' command.
This command can walk through a source directory and return one filename
at a time. But I found that if my command modify the files in that
source directory the 'for' command could invoke the do command with the
same file name more than 1 times."
I was not able to reproduce that in Win7 Sp1. One thing I noticed is
that the OP had the FOR/R loop return the files in some out-of-sequence
order. On an NTFS drive, they would be returned alphabetically by
default. Maybe the issue is file-system related, in which case it can't
be really tested without more information about the exact environment.
Regardless, if the body of the loop does modify the files/directories
that the FOR acts upon, I can see potential problems occurring.
4.
http://groups.google.com/group/alt.msdos.batch.nt/msg/0f309417184042ec
"Yes, I recall one issue. It was when specifying a starting directory
and it has long filename elements. I don't have an example, and know
that it only goes belly up on some combinations."
Ran a few tests, negative so far.
Liviu