WAD /Sn mishandled in DIR and PDIR, possibly elsewhere

[Steve Fabian]

Two separate issues, the first is just documentation.

1/ Typical statement regarding /Sn: "If you specify a number after the /S, PDIR will limit the subdirectory recursion to that number. For example, if you have a directory tree "\a\b\c\d\e", /S2 will only affect the "a", "b", and "c" directories." In fact, the example shows that n+1 levels of subdirectories are reported. There is no "0th recursion".

2/ /S0 is interpreted as /S in both DIR and PDIR. For example, the command *dir/b/s0/a:d" in a test directory hierarchy reports:
F:\TEST\a
F:\TEST\b
F:\TEST\c
F:\TEST\h
F:\TEST\c\d
F:\TEST\c\f
F:\TEST\c\d\e
F:\TEST\c\f\g
F:\TEST\h\i
F:\TEST\h\i\j
F:\TEST\h\i\j\k
F:\TEST\h\i\j\k\l

TREE /S0 reports only the top level subdirectories of its start point. I have not tested other commands, esp. COPY and its relatives, nor DEL and its relatives.

Note: V9 processes /S0 consistently with /S1, /S2, etc.

 

[rconn]

Two separate issues, the first is just documentation.

1/ Typical statement regarding /Sn: "If you specify a number after the /S, PDIR will limit the subdirectory recursion to that number. For example, if you have a directory tree "\a\b\c\d\e", /S2 will only affect the "a", "b", and "c" directories." In fact, the example shows that n+1 levels of subdirectories are reported. There is no "0th recursion".

The help is confusing because it left out the assumption that you were already in the "\a" directory. (A /Sn always affects the current directory + the number of subdirectory levels you specify.) I will update the help to make that clearer.

2/ /S0 is interpreted as /S in both DIR and PDIR.

WAD -- because there's no reason to use /S0 in DIR or PDIR, TCC is assuming the user did something wrong and it's fixing the syntax for you.

 

[Frank]

WAD -- because there's no reason to use /S0 in DIR or PDIR, TCC is assuming the user did something wrong and it's fixing the syntax for you.

I would definitely prefer that the commands are working as documented, e.g. dir /s0 shouldn't walk through subdirs.

 

[rconn]

I would definitely prefer that the commands are working as documented, e.g. dir /s0 shouldn't walk through subdirs.

Why would you ever want to do that? If you don't want subdirectories, save yourself typing an extra 4 characters and leave off the /s0!

(BTW, it's been working this way for several years -- it doesn't seem to have caused anyone great inner turmoil until now.)

 

[JohnQSmith]

Why would you ever want to do that?

Passing the recursion depth as a parameter from a variable.

[C:\]
13:41:17 $ mkdir 1\2\3\4\5
 
[C:\]
13:41:31 $ cd 1
 
[C:\1]
13:41:33 $ tree
 
C:\1
└──2
  └──3
      └──4
        └──5
 
[C:\1]
13:41:36 $ set depth=1
 
[C:\1]
13:41:45 $ dir /b /s%depth
C:\1\2
C:\1\2\3
 
[C:\1]
13:41:53 $ set depth=0
 
[C:\1]
13:41:57 $ dir /b /s%depth
C:\1\2
C:\1\2\3
C:\1\2\3\4
C:\1\2\3\4\5

 

[rconn]

I meant a real use, not an imaginary one. (Have you ever actually wanted to do that?)

 

[JohnQSmith]

(Have you ever actually wanted to do that?)

Not until somebody pointed out that I couldn't do it. (I didn't even know you could limit the recursion depth until seeing this thread.)

 

[Frank]

I nearly daily have to study software-documentations, mostly very comprehensive (oracle, vmware ...).
And in my understanding all software should work as documented (or at least try to).
In this case it isn't so severe, but I can remember that once I tried PDIR and used /S0 to test the result and limit the output.
I was astonished that the output was a little bit more bulky than expected
I know, I can press ctrl-c ...
Is DIR /S0 working different as DEL /S0 ? I wouldn't like that, sorry.

 

[Steve Fabian]

WAD -- because there's no reason to use /S0 in DIR or PDIR, TCC is assuming the user did something wrong and it's fixing the syntax for you.

Yes there is - to list the contents of the current directory and the contents of its immediate (first level) subdirectories. And why would DIR and PDIR interpret /S0 totally differently than TREE?

 

[Steve Fabian]

It is especially bothersome in @FILES. How can I count the subdirectories of the current directory?

 

[thedave]

Yes there is - to list the contents of the current directory and the contents of its immediate (first level) subdirectories. And why would DIR and PDIR interpret /S0 totally differently than TREE?

Maybe I'm missing something, but wouldn't /S1 do the trick?

If you think of TREE as a nicely formatted "dir /h /a:d /b" then TREE and DIR act similarly. TREE arguably needs a /S0 since it implicitly includes a /S (whereas DIR does not have any implicit /S)

Or am I totally misunderstanding your question here?

 

[Steve Fabian]

Maybe I'm missing something, but wouldn't /S1 do the trick?

If you think of TREE as a nicely formatted "dir /h /a:d /b" then TREE and DIR act similarly. TREE arguably needs a /S0 since it implicitly includes a /S (whereas DIR does not have any implicit /S)

Or am I totally misunderstanding your question here?

"*dir/b/h/a:d/s1 path" reports both immediate subdirectories of path, AND its immediate subdirectories, i.e., it reports 2 levels of subdirectories. This is identical to reports of TREE/s1 - 2 levels down from base directory. /Sn always reports n+1 levels of hierarchy.

 

[thedave]

So again, think of TREE as a formatted version of DIR. With a recursion level of zero, it provides a list of objects (directories) contained in the current directory. With a recursion level of 1, it goes one level down and lists all the directories contained there.

In fact, except for the fact that tree lists the current directory first (and a line of whitespace), once you strip the formatting (/b) and resort, the output is identical:

@ECHO OFF
*dir /a:d /b /s5 | sort > 1.txt
*tree /s5 /b | sort > 2.txt
fc 1.txt 2.txt
del /q 1.txt 2.txt

So the data is identical and consistent, it's just that DIR and TREE present things slightly differently. This makes it much easier to predict expected behaviour, and it makes a /s0 make sense on TREE (to remove the implicit /s) whereas it doesn't do anything at all on a DIR (since there is no implicit /s)

I might argue that /s0 could just be ignored completely for DIR since there's no recursion expected by default, but I can't see how it much matters since saying "Oh by the way, can you give me an extra nothing" is non-nonsensical.

 

[Steve Fabian]

So again, think of TREE as a formatted version of DIR. With a recursion level of zero, it provides a list of objects (directories) contained in the current directory. With a recursion level of 1, it goes one level down and lists all the directories contained there.

In fact, except for the fact that tree lists the current directory first (and a line of whitespace), once you strip the formatting (/b) and resort, the output is identical:

@ECHO OFF
*dir /a:d /b /s5 | sort > 1.txt
*tree /s5 /b | sort > 2.txt
fc 1.txt 2.txt
del /q 1.txt 2.txt

So the data is identical and consistent, it's just that DIR and TREE present things slightly differently. This makes it much easier to predict expected behaviour, and it makes a /s0 make sense on TREE (to remove the implicit /s) whereas it doesn't do anything at all on a DIR (since there is no implicit /s)

I might argue that /s0 could just be ignored completely for DIR since there's no recursion expected by default, but I can't see how it much matters since saying "Oh by the way, can you give me an extra nothing" is non-nonsensical.

If I want to have separate lists of the recursion level-0, recursion level-1, etc. entries, in TREE and in V9 version of DIR and PDIR O can treat all levels identically:

for /l %n in (0,1,5) dir/s%n/s+%n

But since V10 I need two commands, one for recursion level 0, and one for deeper recursions:

dir
for /l %n in (1,1,5) dir/s%n/s+%n

And here is the first step toward the DWRM parserr: because there's no reason to use /S0 in DIR or PDIR, TCC is assuming the user did something wrong and it's fixing the syntax for you.

 

[mfarah]

And here is the first step toward the DWRM parserr: because there's no reason to use /S0 in DIR or PDIR, TCC is assuming the user did something wrong and it's fixing the syntax for you.

In my opinion, an error message should be displayed in this case. Something along the lines of "The /S0 option makes no sense in this context.". This should be applicable to pairs of mutually exclusive options, as well.

 

[rconn]

Yes there is - to list the contents of the current directory and the contents of its immediate (first level) subdirectories. And why would DIR and PDIR interpret /S0 totally differently than TREE?

No, there isn't. /S0 would only read the current directory. /S1 lists the current directory and the contents of its first-level subdirectories.

DIR and PDIR interpret it differently because years ago, certain beta testers (you know who you are ...) complained bitterly about having to change the illegal syntax in their batch files and aliases (i.e., no trailing whitespace after a /S).