TCC dir /s command not showing all folders

[erpomik]

TCC and TCC/LE version 11.0.x and the new version 12.0.32 seems to have a general problem when using dir /s to search for a specific folder name.

If I search for a specific folder without using wildcards like 'dir /s foldername' and an empty folder with that specific name exists, the folder is not listed. The reason for this, I believe, is that TCC and TCC/LE thinks that I want the contents of this specific folder to be listed and not the folder itself. This is even if I specify the /a:d switch. CMD.exe seems to do this right (IMO ;)).

To illustrate the problem, I've created a script that creates a couple of directories and then executes dir commands with different switches and search patterns. The script is attached together with the result from TCC 11.00.52 and TCC 12.00.32. If you run the script, you'll see that the folder named 'folder2' is never listed unless wildcards are used in the search pattern.

Best regards
Ernst Mikkelsen
EM-Soft

 

[rconn]

TCC and TCC/LE version 11.0.x and the new version 12.0.32 seems to have a general problem when using dir /s to search for a specific folder name.

If I search for a specific folder without using wildcards like 'dir /s foldername' and an empty folder with that specific name exists, the folder is not listed. The reason for this, I believe, is that TCC and TCC/LE thinks that I want the contents of this specific folder to be listed and not the folder itself. This is even if I specify the /a:d switch. CMD.exe seems to do this right (IMO ;)).

WAD. TCC (and 4NT and 4DOS all the way back to the beginning) have always behaved this way. The reasoning is that expanding the argument name first (to resolve things like "....\foo", extended wildcards, directory wildcards, URLs, etc.) was more important than having DIR behave differently depending on whether the specified directory was in the current directory or a subdirectory. (A rather dubious CMD behavior, and one I've never actually seen documented.)

 

[erpomik]

WAD. TCC (and 4NT and 4DOS all the way back to the beginning) have always behaved this way. The reasoning is that expanding the argument name first (to resolve things like "....\foo", extended wildcards, directory wildcards, URLs, etc.) was more important than having DIR behave differently depending on whether the specified directory was in the current directory or a subdirectory. (A rather dubious CMD behavior, and one I've never actually seen documented.)

Okay, so doing a "dir /bsa:d C:\Desktop" giving an empty result is not considered an error in your opinion?

Example:
dir /bsa:d C:\Users\Desktop
<empty result="">[Empty List]

dir /bsa:d C:\Users\Deskto?
C:\Users\All Users\Desktop
C:\Users\Default\Desktop
C:\Users\EPM\Desktop
C:\Users\Public\Desktop

I will try to twist my mind, and try remembering to always replace the last character with a question mark when searching for a specific directory.;)

Best regards
Ernst Mikkelsen
EM-Soft</empty>

 

[nikbackm]

Pretty interesting! I never considered that this is how DIR /S works in TCC.

Okay, so doing a "dir /bsa:d C:\Desktop" giving an empty result is not considered an error in your opinion?

Example:
dir /bsa:d C:\Users\Desktop
<empty result="">[Empty List]
</empty>

Well, it will show the sub-directories of desktop if there are any. ;) I had quite a few.

But the "replace last char with ?" trick works quite well. Thanks for that tip! Might come in handy some time.

 

[rconn]

Okay, so doing a "dir /bsa:d C:\Desktop" giving an empty result is not considered an error in your opinion?

No, it's not. Certainly not enough to remove a half-dozen more important features in order to support this. (Apparently it's also not that important to anybody else, as this is the first time this issue has come up in 20 years!)

CMD behaving differently depending on whether the target is in the current directory or a subdirectory isn't considered an error in your opinion?

 

[Charles Dye]

<empty result="">
I will try to twist my mind, and try remembering to always replace the last character with a question mark when searching for a specific directory.;)
</empty>

If you only want to find subdirectories named "Desktop" and not "DeskTo1", "DesktoA", "Deskto_" and so on, add a pair of brackets instead:

dir /b /s /a:d c:\users\desktop[]

That's a wildcard too, just a more restrictive one.

 

[Jim Cook]

For what it's worth, my timedir has a switch that will enable the behavior
you want. By default I behave the same way as TCC does.

D:\JPtest>timedir /b /s folder2

D:\JPtest>timedir /b /s folder2 /\
D:\JPtest\JPsoft\folder2

You can find my timedir at jcook.net/timedir in case it proves useful to
you.

On Thu, Oct 28, 2010 at 11:42, erpomik <> wrote:

> TCC and TCC/LE version 11.0.x and the new version 12.0.32 seems to have a
> general problem when using dir /s to search for a specific folder name.
>
> If I search for a specific folder without using wildcards like 'dir /s
> foldername' and an empty folder with that specific name exists, the folder
> is not listed. The reason for this, I believe, is that TCC and TCC/LE thinks
> that I want the contents of this specific folder to be listed and not the
> folder itself. This is even if I specify the /a:d switch. CMD.exe seems to
> do this right (IMO ;)).
>
> To illustrate the problem, I've created a script that creates a couple of
> directories and then executes dir commands with different switches and
> search patterns. The script is attached together with the result from TCC
> 11.00.52 and TCC 12.00.32. If you run the script, you'll see that the folder
> named 'folder2' is never listed unless wildcards are used in the search
> pattern.
>
> Best regards
> Ernst Mikkelsen
> EM-Soft
>
> Attached to this message is JPtest.btm (
> http://jpsoft.com/forums/attachment.php?attachmentid=150&d=1288291087)<br>Attached
> to this message is JPtest-11.jpg (
> http://jpsoft.com/forums/attachment.php?attachmentid=151&d=1288291134)<br>Attached
> to this message is JPtest-12.jpg (
> http://jpsoft.com/forums/attachment.php?attachmentid=152&d=1288291157)<br>
>
>
>

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.