This is driving me nuts... I've been using some of Abbodi1406's excellent batch scripts, for example W10UI.cmd (to install or integrate Windows 10 updates), and (of course) it works like a charm. That is: as long as I start it in the "normal" fashion, so either: - Start File Explorer, right click the .cmd file, run as administrator, or: - From my TCC/LE (JPSoft) prompt (administrator), type "cmd" to start a (normal, or is it?) Windows prompt as administrator. In both cases, the batch runs as expected. I wanted to combine a few steps (run W10UI, run other stuff) in a "master" TCC/LE batch command, so to launch W10UI, I used this TCC command (it's a bit different than standard Windows .cmd syntax, but I'm sure you can tell what it does): Code: start /b /PGM "c:\windows\system32\cmd.exe" /c e:\W10UI.cmd When I test this single line of code in a batch file, something weird is going on: Most of the W10UI script is running just fine (it passes the administrator check), but other things don't work, and I don't understand why. The first thing W10UI.cmd complains about is: (W10UI.cmd 8.4 (current version as of today), lines 141-144: Code: :ReadINI find /i "%1 " W10UI.ini >nul || goto :eof for /f "skip=2 tokens=1* delims==" %%A in ('find /i "%1 " W10UI.ini') do call set "%1=%%~B" goto :eof The third line of this section produces "File not found: W10UI.ini", which is very strange, because to me it looks like the first line of the section did in fact find W10UI.ini, otherwise the rest of the section would not be processed in the first place. When I add my working directory to the third line ("find /i "%1 " E:\W10UI.ini), the section is executed as expected. Please note: This is just an example of how things are running differently as I explected, in no way am I criticizing Abbodi1406's work. As I said before: this is not about the W10UI.cmd script, but about the fact that I am too dumb to understand what is going on when I launch the file in a different way. Further "down the road" the script produces more unexpected behaviour, but that's not the point either, fact is that "most" of the script works just fine, I just can't explain what I've done to make things act this "weird". Maybe somebody can give me some pointers on what to try next? I know (eg. from using GUI launchers for batch files in PE) that it can be tricky to get cmd.exe to act exactly as you want to (WOW64, admin, Sysnative, etc.), so who knows what I'm missing here? (Don't say "a brain"...)
Enable debug mode helps a little bit (i didn't do any updating nor placed any updates next to the script) comparing W10UI_Debug.log from normal cmd and tcc (using your command), first thing i noticed it does not set host os winbuild correctly Code: >for /F "tokens=6 delims=[]. " %# in ('ver') do set winbuild=%# >set winbuild=Windows which derived from Code: TCC LE 14.00.9 Windows 8.1 [Version 6.3.9600] running the command without start /b /PGM fix this this command also fix it Code: cmd /c start "" /b cmd.exe /c e:\W10UI.cmd i could not replicate the "File not found" issue but you could test this alternative ReadINI code, or try the command above Code: :ReadINI findstr /i "%1 " W10UI.ini >nul || goto :eof for /f "tokens=1* delims==" %%A in ('findstr /i /c:"%1 " W10UI.ini') do call set "%1=%%~B" goto :eof
But I'm supposed to be in CMD.exe after using start /b /PGM, right? The "/c e:\W10UI.cmd" is supposed to be executed in CMD, not TCC. This little test confirms this: e:\Test.cmd: Code: ver pause run in TCC/LE: Code: start /b /PGM "c:\windows\system32\cmd.exe" /c e:\test.cmd correctly displays: Code: Microsoft Windows [Version 10.0.14393] You're right, it DOES fix it. THANKS! But now I'm still confused. Looks like you do a "double" start of cmd.exe here? So why would a "double cmd.exe start" work better than the "single cmd.exe start" in my TCC batch above? (If, in fact, that does work as I mentioned, confirmed by the "14393" output)? As you can see, I'm working with 14393 (LTSB) here, I did some testing on updating the x86 version as well, and as you know that needs your excellent FixSSShim14393x86.cmd script to work. And as luck would have it, running a similar TCC command DOES work for that particular file: Code: start /B /PGM "c:\windows\system32\cmd.exe" /c e:\FixSSShim14393x86.cmd Once again: As taken from the TCC/LE help file: the "/c e:\FixSSShim14393x86.cmd" part is passed on to cmd.exe, not TCC/LE: Code: The quoted string following this option is the program name. Any additional text beyond the quoted string is passed to the program as its parameters, so to use other START switches you must place them before /PGM which must be the last option for START. You can use /PGM to allow START to differentiate between a quoted long filename and a quoted title for the session.
While typing my previous reply, W10UI.cmd did a complete runthrough, so this confirms this way of starting the file in TCC/LE does work, but I still wonder about all the issues I mentioned...
Yes, ver command alone works, but try it inside the for loop to produce the issue Code: @for /f "tokens=* delims=" %%# in ('ver') do echo %%# The first cmd.exe is to run start under cmd.exe interpreter (TCC/LE's start is apparently not the same) the second cmd.exe is needed because start run batches with cmd.exe /k by default Who knows, it could be bug in TCC/LE, or unexpected behavior inside loop, or maybe it's bug in my Win 8.1 like i said, it get ran by TCC/LE not cmd.exe when inside loop
@Atari800XL, Can you just use the CALL cmd? All I have is "call W10UI.cmd" in by script which workeds fine...
Thank you for this example, thanks to your help, I finally found the issue! Because other (simpler) batch files never caused a lot of problems with TCC/LE's "Start" command, this one had me very confused for quite a while... But even FixSSShim14393x86.cmd worked, so I didn't expect any problems with W10UI. Of course there are no problems with W10UI, that's why I didn't post this question in the Updates topic, but created this separate topic, clearly stating this might be "TCC" related. But let's talk about the solution: All I needed to add was the "/I" (Inherit standard environment) switch. From TCC/LE help: Code: Inherit the default (startup) environment, rather than the current environment I do remember reading about "/I" before, but I must have thought the "Inherit" switch should not be used, as I did not want to inherit anything, but of course after reading again we can see that the switch inherits the standard environment, which is exactly what we want. We want standard .cmd files to be executed with a standard cmd.exe environment, not any TCC/LE inherited stuff (all those wonderful extra TCC command should go into a .btm file, not a .cmd file). So now you ask: what is actually being inherited when we don't use "/I" ? What about this tiny change in the environment variables: Code: Standard environment for TCC/LE "Start" command: ComSpec=C:\windows\system32\cmd.exe Inherited environment for TCC/LE "Start" command: ComSpec=C:\Program Files\TCCLE\TCC.EXE Yep, there we have it! And of course, that is the reason for the "unexpected" (but not anymore) behaviour of commands like "ver", "find", etc. These commands work differently in TCC, which might be great for some cases, but of course not if you expect the output to be in a certain standard format. Thanks again for listening, and for restoring my sanity.