What is "=::" and does its value ever changes?

[npocmaka_]

besides it's a environment variable visible when set " is executed.

I have a slight memory that I saw a post here where the variable was connected to the disabled/enabled extensions (google search is not good at searching "=::") , but the disabled extensions only allow you to print its value as there is no performed a substitution.

If I add/change/delete the variable in the registry it's value is changed but I can't see any other effect.

[einstein1969]

I struggled a lot to find them. This forum should enhance the search.

http://www.dostips.com/forum/viewtopic.php?p=24196#p24196
http://www.dostips.com/forum/viewtopic.php?p=8231#p8231

einstein1969

[npocmaka_]

Thanks einstein1969.

However I've found a way to change its value without tickling the registries.
Just used a discover of carlos described here: http://ss64.org/viewtopic.php?id=1599

Code: Select all

>start /b cmd /e:off


>subst :: %temp%

>pushd ::

>md somedir

>cd somedir

>cd
::\somedir

>echo %=::%
::\somedir

Still I'm not sure if this variable points to some kind of special drive (e.g. the boot partition or current dir?) or is something else...

[penpen]

Somehow i missed these posts (http://www.dostips.com/forum/viewtopic.php?p=8231#p8231), else i would have posted this earlier.

I assume, that there is no variable %=::% (at least not in win xp), it's just an illusion (there):

Code: Select all

@echo off
set "A=B"
echo %=C:%A%A%
echo %=:%A%A%
echo %=::%A%A%
echo %=:: %=::
echo %=::%=::
echo %=:
echo(
set "" | findstr "^="

Result:

Code: Select all

Z:\>test.bat
C:\TempAB
AB
:BA
: :
::
ECHO ist ausgeschaltet (OFF).

=C:=C:\Temp
=ExitCode=00000000
=Z:=Z:\

Sidenote: I cannot explain this behaviour, but as it has no use (or i haven't found one) i think this is a bug.

penpen

Edit: Corrected some wrong information.

[dbenham]

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

[penpen]

I've read the linked post multiple times (up to now)... but i always seem to miss some details ( sorry for that, and thanks for linking the post again; for example the difference between these two cases):

Code: Select all

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

•If VAR is undefined then
Remove %VAR: and continue scan.

(Hope this time, i have i read all ... .)

penpen

[jeb]

The important thing here is the point where the parsing of a variable expression restarts

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

In the first case the variable parser stops after the double colon, so the next percent sign is not the end of %undefined...%, instead it's the beginning of %A%

jeb

[npocmaka_]

Something I can confirm on windows 8.1 and windows 7.

The =:: is not there when the console is started with admin privileges (and is presented when the cmd is started with normal user).
Besides subst and editing registry here's one more way to set this variable (probably it is some 'fake' drive).Probably can be used for a fast (and not 100% reliable) check if the current user is admin.

I'll check on windows 10 too tomorrow , but I think it wont be available there (even in non admin privileged mode - there a lot of changes)

[NunoLava1998]

This is what i get when i try to write %=::% into a file named test12__ then try to open it:

Code: Select all

test12__.txt is not a valid Win32 application.

No, seriously, i actually got that.

Opening it manually just reveals "Echo is ON", and i see that it's just 0x00. What??

[NunoLava1998]

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

My machine also has the ::\ value (or 0x00) If i try to do anything within here, it's back to my current directory.

[thefeduke]

I did have a practical use for these variables. Here are some scraps from my archives. I lost track of where on DOStips I based them.

Code: Select all

@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

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

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

John A.

[mcnd]

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_]

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.

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


On a machines with earlier versions of windows (xp,7,8) the variable is always there except when the command prompt is started with admin privileges.

[jfl]

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

It seems that your memory is even worse than mine
Your own post in 2014 above clearly shows how to make it appear!
I've just played with subst on my Windows 10 machine, and your results from 2014 are easily duplicated.
This is clearly the trace of the current directory, on a temporary drive letter ':' created using the subst command.
The '=::' variable simply remains even after the subst :: drive is deleted.
A hidden /k initialization script must run on non-admin cmd shells, and temporarily create that : drive.