DosTips.com

set "A=B"
echo %undefined:~0,10%A%A%
echo %undefined%A%A%

dbenham (linked post) wrote:•If VAR is undefined then
Remove %VAR: and continue scan.

set "A=B"
echo %undefined:~0,10%A%A%
echo %undefined%A%A%

dbenham wrote:No, your examples can be explained by how undefined variable expansion works when extensions are enabled: http://stackoverflow.com/a/7970912/1012053

The example below helps to demonstrate the issue:

Code: Select all

@echo off
set "undefined="
echo %undefined:~0,10%

--- OUTPUT ---

Code: Select all

~0,10

The =:: variable actually does exist at some level on some machines. But some machines do not seem to have the variable. My current machine does not have it.

When I had a machine that had the variable, the value was ::\

When the variable exists, it can be seen by using SET "" or by disabling extensions and using ECHO %=::%. Extensions have to be disabled because the substring and search/replace syntax introduced with extensions interferes.


Dave Benham

@Echo Off

:ExitInfo
    Echo(
    Echo(ExitInfo legacy list
    Echo(List of active drive Current Directories:
    Echo(=========================================

::  Alternate list methods in subroutine format
    Call :CDs

Rem.Echo/List of active drive Current Directories - the hard way:
    Echo(
    Call :CDsComplex
Exit /B
    
:CDs
    For /F "tokens=2 delims==" %%D IN ('set "" ^| findstr "^=[A-Z]:="') do Echo(%%D
Exit /B

:CDsComplex
::  Dependency JREPL.bat - expected if subfolder got defined
set "" | jrepl "(^=.:=)([^:])(.*)" "$2+$3"  /jmatch
Exit /B

Output wrote:ExitInfo legacy list
List of active drive Current Directories:
=========================================
C:\Users\Yanci\Documents\Scripts
F:\

C:\Users\Yanci\Documents\Scripts
F:\

• The variable does not exists at the start

• After having started a cmd instance as administrator (right button on task bar icon), new cmd instances (non admin) executed with Win+R or from start menu show the variable.

• Once the variable is visible if a new cmd instance is started by Shif+RightClick on a folder + start command here, this instance does not show the variable, but this instance is created from a different parent process

• If I kill the explorer.exe that handles the current desktop and start a new one, new cmd instances don't show the variable.

RtlDosPathNameToNtPathName_U_WithStatus ( "::{52205FD8-5DFB-447D-801A-D0B52F2E83E1}.VisualElementsManifest.xml", 0x0000000012f5e6c0, NULL, NULL )
RtlIsDosDeviceName_U ( "::{52205FD8-5DFB-447D-801A-D0B52F2E83E1}.VisualElementsManifest.xml" )

mcnd wrote:After some tests in W10 64bits

• The variable does not exists at the start

• After having started a cmd instance as administrator (right button on task bar icon), new cmd instances (non admin) executed with Win+R or from start menu show the variable.

• Once the variable is visible if a new cmd instance is started by Shif+RightClick on a folder + start command here, this instance does not show the variable, but this instance is created from a different parent process

• If I kill the explorer.exe that handles the current desktop and start a new one, new cmd instances don't show the variable.

It seems that the variable is associated to the explorer.exe that handles the desktop.

Executing an API monitor attached to the desktop explorer instance, I can see some requests to resolve shell extensions by low level file system functions

Code: Select all

RtlDosPathNameToNtPathName_U_WithStatus ( "::{52205FD8-5DFB-447D-801A-D0B52F2E83E1}.VisualElementsManifest.xml", 0x0000000012f5e6c0, NULL, NULL )
RtlIsDosDeviceName_U ( "::{52205FD8-5DFB-447D-801A-D0B52F2E83E1}.VisualElementsManifest.xml" )

For me, it seems that some shell operations are incorrectly handled and they end being processed by the functions that check for the `::` drive references and insert the current drive path into the environment block.

But it is just an opinion.

npocmaka_ wrote:Sometimes I have "::" on my windows 10 machine , but I didn't know how make it appear.