Is the SET command OK?

[vefatica]

This TCC was newly started with /i from the Start/Run dialog. Look at the line beginning with NUMBER_OF_PROCESSORS.

 

[vefatica]

It's the same in the newly installed build 16. It's a little reminiscent of the FFIND misbehavior ... extra text showing up where it shouldn't.

 

[Charles Dye]

I see a few corrupt lines in mine, including OS and LOGONSERVER.

Oddly, set os displays the value of that one variable correctly, but set os* displays the same one variable with a bunch of gribble appended.

 

[Jay Sage]

Does that happen if you load TCC normally? I do not see any problem (though I was surprised to see that Windows thinks that I have 24 processors, when I really have only 12, but each can run two threads).

 

[Jay Sage]

Oh, I do see the problem with the OS variable. If I run set OS the result looks fine, but when I display all the variables, there is junk after the correct output.

 

[vefatica]

I see a few corrupt lines in mine, including OS and LOGONSERVER.

Oddly, set os displays the value of that one variable correctly, but set os* displays the same one variable with a bunch of gribble appended.

My LOGONSERVER is OK. But my OS looks a little odd.

 

[Charles Dye]

C:\>set number_of_processors
12

C:\>set number_of_processors*
NUMBER_OF_PROCESSORS=12es (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;c:\cygwin64\bin;;C:\Program Files\WindowsPowerShell\Scripts;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\dotnet\;C:\Users\cdye\AppData\Local\Microsoft\WindowsApps;c:\program files\git\bin;

C:\>set os
Windows_NT

C:\>set os*
OS=Windows_NT Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;c:\cygwin64\bin;;C:\Program Files\WindowsPowerShell\Scripts;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\dotnet\;C:\Users\cdye\AppData\Local\Microsoft\WindowsApps;c:\program files\git\bin;

C:\>set onedrive
C:\Users\cdye\OneDrive

C:\>set onedrive*
OneDrive=C:\Users\cdye\OneDriveerver\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files\PuTTY\;C:\Program Files\Git\cmd;c:\cygwin64\bin;;C:\Program Files\WindowsPowerShell\Scripts;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\dotnet\;C:\Users\cdye\AppData\Local\Microsoft\WindowsApps;c:\program files\git\bin;

C:\>

 

[vefatica]

Yes, and individually SET with /u /s /v /d are all OK. And when I (bare-handed) use GetEnvironmentStrings, they're OK.

 

[Charles Dye]

C:\>set os*
OS=Windows_NT Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program
Files\PuTTY\;C:\Program Files\Git\cmd;c:\cygwin64\bin;;C:\Program Files\WindowsPowerShell\Scripts;C:\Program Files (x86)
\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files\dotnet\;C:\Users\cdye\AppData\Local\Microsoft\WindowsApps
;c:\program files\git\bin;

C:\>set os* > con:
OS=Windows_NT

C:\>

I doubt that Rex has changed anything in the SET command. More likely, I think, is that this is some generic change in the console output routines, perhaps to check for/handle double-width characters.

 

[vefatica]

I doubt that Rex has changed anything in the SET command. More likely, I think, is that this is some generic change in the console output routines, perhaps to check for/handle double-width characters.

I was thinking of the allocation and re-use of temporary (?) string buffers.

 

[rconn]

Fixed in 34.0.17 (already uploaded).

 

[Charles Dye]

I'm not seeing this issue in build 17.

 

[vefatica]

I'm seeing a new glitch. Here's the PATH part of SET's output in different instances of TCC.

The first has C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DA; which should be ...\DAL.

The second has C:\Program Files\Intel\Intel(R) Management Egine Components\DAL; (Engine missing 'n')

In another instance I saw C:\Prgram Files\Microsoft Network Monitor 3\; (Program missing 'o').

 

[vefatica]

Looking more closely at those last two pics, there's "Mirosoft", "C:\WINOWS", and "(x8)" in there (maybe more).

 

[Charles Dye]

Toos\Binn\ should be Tools\Binn\, and and WindowPowerShell should be WindowsPowerShell.

(But "Program Fils" is too wonderfully French to complain about.)

 

[Alpengreis]

Before build .17 it was good HERE (I think), NOW I have also the problems with missing chars (discovered at least in "PATH") ...

 

[rconn]

Try it with 34.0.18 (already uploaded).

 

[Charles Dye]

Not seeing this in build 18.

 

[vefatica]

I'm also not seeing it. I'm a little skeptical because it can be hard to find even if it's there.

 

[Alpengreis]

Seems good here too! Ty!