Is there any way to work around this (apparent) limitation of TCC?

[mathewsdw]

Without going through a lot of details that I believe are irrelevant, I have a batch file that goes through all of the directories in a directory tree doing things that must be done after every subdirectory of every given subdirectory has been visited, so as far as I know (I could certainly be wrong, I suppose!) the simple "For /R[ecursive" loop won't do the job. So I have a (sample!) batch file ("D:\RecurseDirectories.btm") that does nothing more than the directory recursion and it looks like this:

  @Echo On
  SetLocal
  If "%1" == "D:\Top-Level Directory\2nd-Level Directory" Quit 0
  On Break Goto Cancel
  On ErrorMsg Goto Cancel
  Set StartDir=%1
  If "%StartDir" == "" Set StartDir="%_CWD"
  For /D %D in ("%StartDir\*") Do (
      Call D:\RecurseDirectories.btm "%D"
  )
  EndLocal
  Quit 0
:Cancel
  EndLocal
  Cancel 4

Well, when I run this sample batch file it executes for a second or two then the TCC session in which it is being run terminates without notice, and if I append ">>&D:\RecurseDirectories.txt" to the command the .txt file contains exactly what I would expect it to contain until the TCC session terminates, and the last line in the .txt file is the "Call" statement.

I would assume that I am exceeding some kind of "nesting" limit for TCC (although I don't know that for sure, of course). Is there any (easy!) way to avoid this limitation? Note that I want the "Cancels"'s to cancel the whole batch file recursion sequence.

- Dan

 

[samintz]

What are you doing at each parent level that you have to recurse its children first? You batch example isn't doing anything.

-Scott

 

[mathewsdw]

Scott, I'm ultimately going to 7z (like zip) files that meet certain criteria and delete them after which I want to delete the directories that they were in. I'm doing hard-disk "cleanup".

- Dan

 

[Charles Dye]

You need to process directories from the inside out?

My first thought would be to create a list of directories and reverse it with something like a port of the Unix 'tac' utility:

dir /a:d /s /b /h d:\directory | tac > dirs.txt
do dir in @dirs.txt
   ...

 

[Steve Fabian]

or put them in an array, and process its elements backwards

 

[samintz]

This may do what you want:

do D in /p (dir /a:d /sb | sort /r) (if %@files["%D\*"] == 2 echo %D is empty)

or in V14

do D in /p (dir /a:d /sb .. | sort /r) (if %@files[/h,%D\*]==1 echo %D is empty)

-Scott

 

[samintz]

This may do what you want:

do D in /p (dir /a:d /sb .. | sort /r) (if %@files[/h,%D\*]==1 echo %D is empty)

Whoops. That should be ==0 not ==1.

do D in /p (dir /a:d /sb .. | sort /r) (if %@files[/h,%D\*]==0 echo %D is empty)

 

[samintz]

I think my brain is working faster than my fingers...

Replace the .. with your directory of choice.

 

[mathewsdw]

Steve, the array isn't a bad idea but using Charles idea of using "TAC" is even better (simpler). (I haven't used UNIX professionally (or any other way, for that matter) for more than 20 years so I'm no longer familiar with it - when I last used it it didn't even have a GUI.) "KISS" rule - "Keep It Simple, Stupid" (and I'm often stupid!). But, as always, thank you both!

And Scott, your idea (which came in while I was originally typing this) is good, too, but Charles idea is still the least effort (for me, at least - less to think about).

- Dan

 

[vefatica]

You need to process directories from the inside out?

My first thought would be to create a list of directories and reverse it with something like a port of the Unix 'tac' utility:

dir /a:d /s /b /h d:\directory | tac > dirs.txt
do dir in @dirs.txt
  ...

Nice idea, Charles. But do you have a TAC.EXE that can read from a pipe? My Gnu TAC.EXE can't (though its help says it can and I couldn't Google any complaints about its failing).

GLOBAL seems to be strictly top-down. So this

(GLOBAL /I /Q /H /N ECHO %_CWD) > topdown.txt
TAC.EXE topdown.txt > bottomup.txt

gave me an ordered list of dirs that would have satisfied Dan's need.

And, Dan, the batch file nesting limit is 32 according to the help. Is your tree deeper than that?

 

[Charles Dye]

Nice idea, Charles. But do you have a TAC.EXE that can read from a pipe? My Gnu TAC.EXE can't (though its help says it can and I couldn't Google any complaints about its failing).

I have two, both from UnxUtils, and neither one works for me. (One just plain doesn't work; the other crashes.) So my "first thought" seems like a nice idea in theory, but I can't make it work in practice.

Happily, Scott has shown a way to make SORT do what tac is supposed to do. I suppose one could ALIAS TAC=SORT /R ....

 

[vefatica]

Happily, Scott has shown a way to make SORT do what tac is supposed to do. I suppose one could ALIAS TAC=SORT /R ....

Doesn't that reverse the **sorting** order (Z-A, 9-0, et c.)?

c:\> echo foo^r^nbar | sort /r
foo
bar

That's not exactly what TAC does. Nevertheless, SORT /R sorts longer strings first. I guess that's enough to guarantee bottom-up.

c:\> (global /q /i echo %_cwd) | sort /r
[snip]
C:\Program Files\Adobe\Reader 10.0\Reader\IDTemplates\ENU
C:\Program Files\Adobe\Reader 10.0\Reader\IDTemplates
C:\Program Files\Adobe\Reader 10.0\Reader\Browser
C:\Program Files\Adobe\Reader 10.0\Reader\AIR
C:\Program Files\Adobe\Reader 10.0\Reader
C:\Program Files\Adobe\Reader 10.0\Esl
C:\Program Files\Adobe\Reader 10.0
C:\Program Files\Adobe
C:\Program Files
C:\aemail
C:\

c:\>

 

[Frank]

perhaps @PATH could be helpful, too.

>echo %@path["C:\Program Files\Adobe\Reader 10.0\Reader\IDTemplates\ENU"]
C:\Program Files\Adobe\Reader 10.0\Reader\IDTemplates\

and wouldn't DIR | SORT be easier?

>tree /a d:\temp\recurse
 
D:\temp\recurse
+--dir1
|  \--a
|    \--b
|        \--c
+--dir2
|  \--a
|    \--b
|        \--c
\--dir3
  \--a
      \--b
         \--c
 
>dir /s /f /h d:\temp\recurse | sort /r
D:\temp\recurse\dir3\a\b\c
D:\temp\recurse\dir3\a\b
D:\temp\recurse\dir3\a
D:\temp\recurse\dir3
D:\temp\recurse\dir2\a\b\c
D:\temp\recurse\dir2\a\b
D:\temp\recurse\dir2\a
D:\temp\recurse\dir2
D:\temp\recurse\dir1\a\b\c
D:\temp\recurse\dir1\a\b
D:\temp\recurse\dir1\a
D:\temp\recurse\dir1

 

[Steve Fabian]

My GNU tac.exe (1999-11-10@23:00:00, 49664 93A4266C TAC.EXE) accepts piped input w/o problem. What a meaningful name! Describes its function as well as "awk" does...

 

[Frank]

Meaningful? I thought AWK got it's name from the 3 programmer who originally created it. And isn't TAC the twisted form of CAT?

 

[Charles Dye]

My GNU tac.exe (1999-11-10@23:00:00, 49664 93A4266C TAC.EXE) accepts piped input w/o problem. What a meaningful name! Describes its function as well as "awk" does...

I thought about providing my own version and calling it EPYT, but that's almost as bad....

 

[Charles Dye]

And isn't TAC the twisted form of CAT?

Which is also not a very informative name. Perhaps the programmer thought he was building a better mousetrap.

 

[Steve Fabian]

A utility program looses its utility if its name does not suggest what it does. If infrequent users must always refer to a whole series of manuals to find the utility that fits their needs the set is not utilitarian. Naming a program by its authors' initials provides no information about its purpose. Naming a program by reversing the order of letters in the name of another program is equally unclear. Does tac reverse the order of characters in the cat (catena: chain in Latin), i.e. the character stream? I happen to have discovered that it does not, but the casual user needs a name that at least hints at what it does. IMHO that's why TCC is so great a tool - all command, variable and function names are descriptive, or at least are abbreviations of long descriptions, and are easily found in a single document.

 

[vefatica]

My GNU tac.exe (1999-11-10@23:00:00, 49664 93A4266C TAC.EXE) accepts piped input w/o problem. What a meaningful name! Describes its function as well as "awk" does...

What does "TAC --version" report?

Mine (textutils 2.1), when used in a pipe, silently does nothing (with no output) on Win7; on XP it crashes.

 

[mathewsdw]

Thank you all guys, I was away from this for a while because I got involved in other things (the story of my life, I'm afraid). And I had sort of abandoned it in the short term when I couldn't get TAC (what a name!!!) to work. However, all's well now (I happened to use sort, but I then (re-?)downloaded the GNU TAC just as an experiment and the "new" version now worked). Thanks again!

 

[Frank]

in addition, how about this one (I call it recurse.btm):

@echo   off
setlocal
 
iff     "%1" eq "" then
        set        startdir=.\
else
        set startdir=%1
 
pushd   "%startdir"
gosub   sub2
popd
 
endlocal
quit
 
:sub2
 
for     /d %dir in (*.*) (
 
        pause     "%dir"
        pushd      "%dir"
        gosub      sub2
        popd
)
 
return

 

[mathewsdw]

Very clever, Frank!!! :) But for me the problem has been solved.

 

[mathewsdw]

Oh, and to answer a question that I almost forgot to answer, it would seem that my directory tree is too deep (I classify and sub-classify and sub-sub-classify and ... ad nauseum. Maybe it's a bad-memory thing...

 

[David Marcus]

Which is also not a very informative name. Perhaps the programmer thought he was building a better mousetrap.

According to Wikipedia, "The name is an abbreviation of catenate, a synonym of concatenate." Sometimes a memorable name is a good choice, even if a beginner may not know what it does.

 

[vefatica]

Thank you all guys, I was away from this for a while because I got involved in other things (the story of my life, I'm afraid). And I had sort of abandoned it in the short term when I couldn't get TAC (what a name!!!) to work. However, all's well now (I happened to use sort, but I then (re-?)downloaded the GNU TAC just as an experiment and the "new" version now worked). Thanks again!

Which "new" one ... coreutils 5.3.0? Does TAC.EXE work on the right side of a pipe?

 

[Charles Dye]

According to Wikipedia, "The name is an abbreviation of catenate, a synonym of concatenate." Sometimes a memorable name is a good choice, even if a beginner may not know what it does.

Yeah, I've heard that one. Only I've never actually known anyone to use "catenate" for "concatenate", and it seems it's most often used to just dump a single file to stdout.

My own theory is that the original author had a cat who liked to unspool all of the toilet paper from the roll. Anyone who's ever dumped a long file to teletype will make the connection....

 

[David Marcus]

Your theory is more interesting. But, I think it is just short for "concatenate". "cat" was better than "con".

 

[Stefano Piccardi]

Here's yet another way (I like sed)

sed -n '1!G;h;$p' file

and you can pipe to sed. Notably passing multiple files as arguments reverses the (con)catenation of all lines not each single file.

 

[mathewsdw]

Vince, sorry it took me to now to get back to this to answer your question (usual reason(s)), but my "new" "TAC" is 4/20/2005@13:41, and it does, in fact, work OK for me.

 

[Steve Fabian]

What does "TAC --version" report?

Mine (textutils 2.1), when used in a pipe, silently does nothing (with no output) on Win7; on XP it crashes.

tac (GNU textutils) 2.0
Written by Jay Lepreau and David MacKenzie.

Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Vince, maybe you need to go back to the earlier version... Oh, here everything is 32b.

BTW, "tack" means to attach. TAC? It's anybody's guess! Certainly not a name that promotes anything but rote memorization if meaningless character strings as usable for a purpose. I wonder how many monkeys were used to generate that name...