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

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
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:
Code:
  @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
 
#3
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

Super Moderator
Staff member
May 20, 2008
3,385
39
Albuquerque, NM
prospero.unm.edu
#4
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:

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

samintz

Scott Mintz
May 20, 2008
1,204
11
Solon, OH, USA
#6
This may do what you want:
Code:
do D in /p (dir /a:d /sb | sort /r) (if %@files["%D\*"] == 2 echo %D is empty)
or in V14
Code:
do D in /p (dir /a:d /sb .. | sort /r) (if %@files[/h,%D\*]==1 echo %D is empty)
-Scott
 
#9
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
 
#10
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:

Code:
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

Code:
(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

Super Moderator
Staff member
May 20, 2008
3,385
39
Albuquerque, NM
prospero.unm.edu
#11
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 ....
 
#12
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.)?
Code:
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.
Code:
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:\>
 
#13
perhaps @PATH could be helpful, too.
Code:
>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?
Code:
>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
 
#15
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?
 
#18
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.
 
#20
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!
 
#21
in addition, how about this one (I call it recurse.btm):
Code:
@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
 
#23
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...
 
#25
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

Super Moderator
Staff member
May 20, 2008
3,385
39
Albuquerque, NM
prospero.unm.edu
#26
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....
 
May 31, 2008
376
2
#28
Here's yet another way (I like sed)
Code:
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.
 
#30
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...