Starting .cmd (eg. W10UI) from TCC - unexpected behaviour?

Discussion in 'Scripting' started by Atari800XL, Jul 20, 2020.

  1. Atari800XL

    Atari800XL MDL Addicted

    Apr 3, 2011
    954
    1,673
    30
    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"...)
     
  2. abbodi1406

    abbodi1406 MDL KB0000001

    Feb 19, 2011
    16,141
    84,319
    340
    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
     
  3. Atari800XL

    Atari800XL MDL Addicted

    Apr 3, 2011
    954
    1,673
    30
    #3 Atari800XL, Jul 20, 2020
    Last edited: Jul 20, 2020
    (OP)
    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.
     
  4. Atari800XL

    Atari800XL MDL Addicted

    Apr 3, 2011
    954
    1,673
    30
    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...
     
  5. abbodi1406

    abbodi1406 MDL KB0000001

    Feb 19, 2011
    16,141
    84,319
    340
    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
     
  6. Flipp3r

    Flipp3r MDL Expert

    Feb 11, 2009
    1,962
    904
    60
    @Atari800XL, Can you just use the CALL cmd? All I have is "call W10UI.cmd" in by script which workeds fine...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. Atari800XL

    Atari800XL MDL Addicted

    Apr 3, 2011
    954
    1,673
    30
    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.