Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Subdir level inconsistencies and exclusion ranges

Apr
318
7
The command TREE /B /S0 C:\ shows top-level dirs only.
The command DIR /A:D /F /H /S0 C:\ shows the whole dir tree where one would expect the first level only.

This difference exits only for level 0. Higher subdir-levels work as expected.

Also, in both commands I can't get the exclusion range to work.
E.g: TREE /[!AMD] /B /S0 C:\ shows C:\AMD and all subdirs.

This used to work in the past, didn't it?

Regards,
DJ
 
Last edited:
Okay. You're right. Forget TREE for the moment. Let's return to DIR. Something is not working. I don't know what. Maybe its a combination of options, I don't know.
This has worked in the past, I'm sure of that. Only recently I discovered that certain batches suddenly were taking a long time to finish. These batches share an input file containing a list of dirs to work on. That list used to be short and sweet but suddenly contained every dir on the device. The exclusion and/or the subdirlevel limitation is not working anymore.
I'm afraid I don't know which change introduced this.

What I want to accomplish is
- list all full dir names
- that are on a single device
- excluding certain dirs and their subdirs

I build a space separated list of dirnames - quoted if necessary - in an envar and then do this:

dir /[!%DirExclude] /A:+D+H-J /S3 c:\

Whatever variation of options I try, It returns every dir on the device as soon as I add /Sx to the command.

Please advice.
 
DIR assumes that a 0 following a /S is an error, so it resets itself to show everything.

I don't understand why you would want to do this (as opposed to simply not specifying the /S0 at all).

Why assume an error? /S0 could just as easy be construed as the default value if /Sx is missing from the command line.
Also why would TREE /S0 be valid and DIR /S0 suddenly be an error? That is quirky not only for reasons of lexical symmetry but also because it actually refers to the same thing on both cases.
A reason one might want to do this (but not the reason I was doing it) is if x in /Sx is a parameter, the minimum of a range of calculated values.

Regards, DJ
 
Why assume an error? /S0 could just as easy be construed as the default value if /Sx is missing from the command line.
Also why would TREE /S0 be valid and DIR /S0 suddenly be an error? That is quirky not only for reasons of lexical symmetry but also because it actually refers to the same thing on both cases.

TREE defaults to /S, DIR does not. A /S0 actually means something to TREE; it's an obvious error for DIR. (And not "suddenly"; DIR has worked that way since the /Sn option was introduced.)
 
I disagree, but never mind. I can live without DIR /S0. It was just one of many trial-and-error attempts to get the thing to do the seemingly simple thing I want; traverse a tree skipping all directories and their subdirectories that match one of the given exclusions.

Are you saying that is a case of WAD too?

Regards, DJ.
 
I have a vague memory that, once, you could block recursion into matching subdirectories by adding a backslash to the end of the spec: DIR /[!FOO\] /S /B TEST.* to recurse into all subdirectories not matching FOO.

I can't make this work now; not sure whether this feature broke somewhere along the way, or whether I'm just totally misremembering it.
 
Thank you for your reply Charles.

I too seem to be suffering from "false memories". Because the feedback here seems to be that a DIR command that uses any form of the option /S _and_ any form of exclusion-range could never have worked in any of my batches. That certainly comes as a surprise to me! Of course *now* I think I should have had some kind of version control on my source files :-)

Have you got any time-saving suggestions or snippets for hand-crafting this code? Because it's decision-time.

Regards, DJ.
 
Back
Top