WAD 15.01.52 broke Windows 2003 SDK setenv.cmd

[jaltman]

After upgrading to .52 the following errors are produced:

C:\program files\Microsoft SDKs\Windows\2003\setenv.cmd [148] Usage : IF [/I] [NOT] condition [.AND. | .OR. | .XOR. [NOT] condition ...] command
C:\program files\Microsoft SDKs\Windows\2003\setenv.cmd [158] Usage : FOR [/A:[[-][+]rhsdaecjot] /D /F ["options"] /H /I"text" /L /Nj /O:[-]adegnrstu /R [path] /T"..." /W] %var IN ([@]set | start, step, end) [DO] command ...

Line 148 is

IF /i "%PROCESSOR_ARCHITECTURE%" == "ALPHA" (Set CPU=ALPHA) else (Set CPU=i386)

and line 158 terminates:

For /F "delims=;" %%i IN ('%windir%\system32\Cmd.exe /c Ver') DO (
IF "%%i"=="Windows NT Version 4.0 " (
IF "%CPU%" == "IA64" goto ErrorUsage9x_IA64
)
)

I'm fairly sure the upgrade was from .51 to .52 but it could have been from .48 to .52. Is it possible to download 15.01.51 so I can verify? (x64)

Thanks.

 

[jaltman]

Using BDEBUGGER to examine the parameters passed into setenv.cmd, it appears that any parameters with a leading slash are being modified similar to the following echo command:

[C:\]echo /2000
\\2000

I hope this is a clue. I've tried toggling off "UNIX/Linux-style Paths" without a change in behavior.

 

[jaltman]

I cannot reproduce the problem on another system. On the problem system all parameters with forward slashes are translated to double backslashes. For example, "LIST /S" attempts to process "LIST \\s" and fails to find a file by that name. "dir /s" attempts to process "dir \\s" and fails. It makes tcc.exe very difficult to use.

Any thoughts on how the command input could be captured and translated? How might I debug this situation?

 

[rconn]

Not reproducible here. Nothing has changed in the argument parsing in the last few builds.

I suspect this is local to your system (otherwise EVERYBODY would be complaining!). Are you running any plugins?

 

[jaltman]

Not reproducible here. Nothing has changed in the argument parsing in the last few builds.

I suspect this is local to your system (otherwise EVERYBODY would be complaining!). Are you running any plugins?

I'm not running any plug-ins that I am aware of or remember. Is there a command I can run to list take command plugins?

On this one system the substitution of all "/" with "\\" on each and every command line input is taking place:

• TCC 64-bit 15.01
• TCC 32-bit 15.01
• TCC 64-bit 14.03.59
• TCC 32-bit 12.11.76

The substitution does not occur if I run Cygwin bash, cmd, or powershell within Take Command.

I've either hit a very weird configuration bug or something is altering / filtering the command line input.

Of course, my systems have OpenAFS installed. The behavior is similar to what it would be if every parameter matched the AFS root.
In fact, that is indeed the problem. The TransarcAFSDaemon/Parameters "MountRoot" value was set to the empty string. So every parameter did have a matching AFS root prefix.

 

[samintz]

What are your aliases? Do you have PRE_INPUT or PRE_EXEC defined?

 

[jaltman]

Reply

What are your aliases? Do you have PRE_INPUT or PRE_EXEC defined?

Scott, thanks for the reply. PRE_INPUT and PRE_EXEC are not set. Take Command has the ability to automatically translate command line parameters that are known to be AFS paths by matching the prefix of the path, /afs/your-file-system.com/public/openafs, to a value specified in the registry, /afs. If there is a match, the path will be transformed into a Windows UNC path \\AFS\your-file-system.com\public\openafs. With the "MountRoot" registry value set to the empty string, every parameter appeared to match the requisite prefix and was converted.

 

[samintz]

Ouch. Is that an OpenAFS setting or a TCMD.INI setting? Was this behavior changed in 52 or was it coincidental?

 

[jaltman]

Its an openafs setting and I'm the developer of the OpenAFS Windows client. The bug was coincidental and quite bizarre.