WAD /Sn mishandled in DIR and PDIR, possibly elsewhere

May 20, 2008
3,515
4
Elkridge, MD, USA
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

Administrator
Staff member
May 14, 2008
12,406
152
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.
 
Aug 2, 2011
258
4
Berlin, Germany
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

Administrator
Staff member
May 14, 2008
12,406
152
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.)
 
Jan 19, 2011
605
15
Norman, OK
Why would you ever want to do that?
Passing the recursion depth as a parameter from a variable.
Code:
[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
 
Jan 19, 2011
605
15
Norman, OK
(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.)
 
Aug 2, 2011
258
4
Berlin, Germany
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 :confused:
I know, I can press ctrl-c ...
Is DIR /S0 working different as DEL /S0 ? I wouldn't like that, sorry.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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?
 
Nov 13, 2008
255
3
www.thedave.me
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?
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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.
 
Nov 13, 2008
255
3
www.thedave.me
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:

Code:
@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.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
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:

Code:
@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.
 
Nov 2, 2009
295
6
Chile
www.farah.cl
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

Administrator
Staff member
May 14, 2008
12,406
152
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).
 
Similar threads
Thread starter Title Forum Replies Date
E Fixed Bug with DIR /Z displaying descriptions Support 8
J Paths shown in DIR /B Support 2
K Fixed Prompt display will be shifted after use dir to display a filename with Chinese. (v25.00.28 x64) Support 18
Jesse Heines How to? How to display picture creation date with dir command Support 6
vefatica WAD DIR.BTM? Support 11
DrusTheAxe DIR reports meaningless SYMLINK information Support 14
C show file description? with dir? Support 8
vefatica DIR /F and streams? Support 7
rps Multi-column DIR /v not displaying all files. Support 5
R How to? Dir specific file search patterns with spaces in the pathnames? Support 6
rps Dir /Nfv -> Alt-F2 Support 2
rps @FILESIZE[....,a] allocated size not matching Dir results Support 8
A TCMD - Dir Command puts out blank lines? Support 16
S Problems with dir command in the debugger Support 5
M TCC incorrect dir output since Windows 1803 Support 6
x13 Problem listing repository files using DIR http(s)://... Support 8
cxxl dir /s works in mysterious ways :( Support 4
vefatica Help nit (FFIND and DIR with /S) Support 0
N Fixed Strange dir behavior Support 6
JohnQSmith Weird DIR output (missing lines) Support 1
C 7zip with date range .vs. filelist created with dir and daterange Support 0
D Towards shared (dir-)history lists Support 3
vefatica WAD DIR /HL still gets names wrong Support 16
vefatica DIR /S /HL? Support 4
H Fixed DIR /G returns wrong sizes Support 2
nickles WAD dir.htm Support 2
vefatica DO dir in /s /a:+d /d"g:\" * ( ... ) Support 26
vefatica DIR \\.\...? Support 4
M Fixed DIR /S /B1 ignores "/S" Support 5
C tcmd.ini not loading from program dir? Support 5
D Fixed Dir /Nm:n has changed Support 1
rps How to? dir /s unexpected results Support 10
vefatica Update to current install dir? Support 8
cgunhouse Problem with "dir /=" Support 4
T dir /h error in empty directory Support 22
P WAD TC 15.0.1.58 x64 crasches with a simple dir command Support 18
CWBillow dir /4 strange Support 2
samintz WAD DIR /B1 and /X Support 2
nickles dir behaves inconsistently Support 5
vefatica DIR, streams, and wildcards? Support 1
vefatica DIR /: /u ... streams not counted? Support 7
vefatica Documentation DIR /B /S /: Support 2
samintz How to? DIR listing for exact match Support 1
dcantor WAD dir "ftp:// ..." fails in TCC 15 Support 7
T How to? dir/pdir - 2nd level down only Support 7
MikeBaas How to? DIR: supress extensions? Support 5
old coot dir /s dies on my C: drive Support 2
A WAD Dir daterange + multiple path wildcards crashes tcc Support 2
old coot TC DIR command has trouble on my SSD Support 2
M Fixed character set in dir/copy Support 3

Similar threads