therube wrote: ↑Wed Sep 13, 2023 3:43 pm
On my end, at least as I've done it...
%source%, correctly returns source=, & correct number of results
%%source%%, returns %source% (literally), & an answer of 0
%%%source%%%, returns source= enclosed in (single) %'s, so %H:\Home\...\%, & an answer of 0
!source! acts as if it were nul (not null nor NotNull), as in as if the source= variable did not even exist, & answer is total number of all your files
Yes, I apologize for that. I created and shared a snippet of the much larger code that was inadvertently misleading in two regards:
(1) I forgot to include in the snippet the 'setlocal enabledelayedexpansion' environmental setting that goes at the top and would probably allow for your !source! to work
(2) I created example directories that do not include any spaces in their names. In the actual, long, process there are many directories that have long names and spaces, requiring "quotation marks" as part of the name. That alone causes so many problems using variables, I think.
therube wrote: ↑Wed Sep 13, 2023 3:43 pm
Does your window "Title" actually get set when using START /B ?
Good question. In the most recent batches I include START /B on built-in Windows commands like: start /b /wait cmd.exe /c findstr, start /b /wait cmd.exe /c type, start /b /wait cmd.exe /c del , etc, etc. But the command lines that include a Title I am just using: START /WAIT . Without the /B. And those windows do have their Titles set, but are running in separate windows.
therube wrote: ↑Wed Sep 13, 2023 3:43 pm Does /I make a difference ?
That's a good tip. I tried it both ways and there was not any difference. Because of all of the variables being used I definitely want each individual batch to operate in its own sandbox with nothing being carried/held over from the main calling batch -- or anywhere else -- so it doesn't seem that /I is what I would want. But, it didn't make any difference.
therube wrote: ↑Wed Sep 13, 2023 3:43 pm Does CMD /C or similar, or in conjunction with START, CMD /C START..., make a difference? Should you be using CMD /C rather then START - in some places?
That's another really good question. All of the batches are mixes of sometimes CMD /C, sometimes start /b /wait cmd.exe /c, just whatever ends up working. Many times there is no difference in what ends up happening. I have not figured out exactly WHY things work with certain syntaxes versus others, I just trial and error.
therube wrote: ↑Wed Sep 13, 2023 3:43 pm Is /wait necessarily needed, in some places?
Yeah, definitely. But not in all. Without the ability to chain batches in sequential order and taking turns I would have a mess. That's a good thought though, and I will skip the WAIT wherever I can. The reason I have that on so many lines is just force of habit and copy/paste.
There are other, third-party, programs that I use with internal scripting capabilities that just have run-on scripts that force building in 'wait' and 'pause' times just for things to even work-- so I just include things like that by habit now. Even in these CMD batch files that probably don't even need them.
I still have mysteries in this, but after some tinkering the latest runnings of the batch chain did produce the desired results. I am not sure why. This process normally runs automated at 2:15a.m. Maybe there is something different then that I am not aware of.
Of course all of this is Windows CMD questions now -- I came to this forum just in case there was an obvious known thing about using CS.EXE in batches that could be solved easily. Now that I have run a working chain that is probably not the case and it all just comes down to Windows CMD-- which is a whole different forum.
Thank you SO MUCH for asking questions and looking into this-- I tinkered around in response to your questions and had a successful run. Now the question is to see what happens tomorrow following the 2:15am automated run.
THANK YOU!!
.