FOR/R syntax bug

[Todd Vargo]

I seem to recall there was a bug using the FOR command's /R or /D switches,
but I can not recall what the circumstances around them were.

Due to a recent post using FOR/R in it's solution, I was going to ask if
anyone could briefly refresh my memory on the reason the DIR command within
a FOR command is preferred (other than being more flexible) but instead I
did some light searching and came up with a post indicating quoted paths
being a problem with FOR/R. But on doing my own FOR/R testing I found the
following bug is not related to quoting at all.

==== Screen Capture (Win95cmd.exe in Windows 98)
E:\>dir/s/b
File Not Found

E:\>md test

E:\>echo test>test\x.txt

E:\>for /r %f in (x.txt) do @echo %f
E:\x.txt
E:\test\x.txt

==== end capture

In my test above, there is no x.txt in the root of the drive, but the FOR/R
command erroneously reports there is. Due to my time being short, I can not
examine FOR/D right now but I seem to recall there being a bug with it also.

I'm not at an XP console right now and was hoping someone could refresh my
memory on these switches and if they had been fixed in XP's cmd.exe.

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)

[billious]

"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
news:HtIlg.69618$4L1....@newssvr11.news.prodigy.com...

In XP,

for /r %f in (x.txt) do @echo %f

will report

dirname\x.txt

for every directory - or at least every non-hidden directory - in the tree

[foxidrive]

On Tue, 20 Jun 2006 01:48:23 GMT, Todd Vargo wrote:

> I seem to recall there was a bug using the FOR command's /R or /D switches,
> but I can not recall what the circumstances around them were.
>
> Due to a recent post using FOR/R in it's solution, I was going to ask if
> anyone could briefly refresh my memory on the reason the DIR command within
> a FOR command is preferred (other than being more flexible) but instead I
> did some light searching and came up with a post indicating quoted paths
> being a problem with FOR/R. But on doing my own FOR/R testing I found the
> following bug is not related to quoting at all.
>
> ==== Screen Capture (Win95cmd.exe in Windows 98)
> E:\>dir/s/b
> File Not Found
>
> E:\>md test
>
> E:\>echo test>test\x.txt
>
> E:\>for /r %f in (x.txt) do @echo %f
> E:\x.txt
> E:\test\x.txt
>
> ==== end capture
>

It is echoing %f for every filespec in the tree - try replacing x.txt with
xyz for example.

A common usage to enumerate the tree is to use
for /r %f in (.) do @echo %f

[Harlan Grove]

foxidrive wrote...
...

>A common usage to enumerate the tree is to use
>for /r %f in (.) do @echo %f

dir . /b /s /ad

needs less typing, though it doesn't include . in its output and it
shows the subdirs in a different order.

[Todd Vargo]

"foxidrive" <woo...@gotcha.invalid> wrote in message
news:1q4bkjltyue83$.l58pxhfefood.dlg@40tude.net...

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.

The /D has the same ailments.

==== Screen Capture (Win95cmd.exe in Windows 98)

E:\>rem Same setup as above

E:\>md test

E:\>echo x>test\x.txt

E:\>dir/s/b/a-d
E:\test\x.txt

E:\>for /r %f in (x.txt) do @echo %f
E:\x.txt
E:\test\x.txt

E:\>for /r %f in (.) do @echo %f
E:\.
E:\test\.

E:\>for /r %f in (:) do @echo %f
E:\:
E:\test\:

E:\>for /r %f in (/) do @echo %f
E:\/
E:\test\/

E:\>for /r %f in (test\x.txt) do @echo %f
E:\test\x.txt
E:\test\test\x.txt

E:\test>for /r %f in (x.txt*) do @echo %f

E:\test\x.txt
==== end capture

Thanks for each of your inputs.

[foxidrive]

Thanks, Harlan.

The discussion was relating to for /R and its limitations and bugs.