Any bang which has the syntax [RainmeterBangName ConfigName .iniName] fails when using the new variable #CURRENTPATH# in the "ConfigName". This is due to the trailing "\" at the end of the path variables, which the bangs seem to hate.

[!RainmeterDeactivateConfig #CURRENTPATH# Menu.ini]

We should look at allowing either a trailing "\" or not on all bangs that require only a path as a parameter.

"#CURRENTPATH#" is a PATH and is not ConfigName. All environment variables are assigned to the absolute path. On the other hand, the path used within BANG is a relative path defined as the root from Skins dir. When you use a absolute path in BANG, it will be ignored.

Since there is not the variable assigned to ConfigName at the present, you need to define ConfigName oneself.

[Variables] CURRENTNAME=Menu

[!RainmeterDeactivateConfig #CURRENTNAME#]

Understood. The confusion for users comes from the fact that the current directory is in fact also the configname from a logical standpoint. There actually is no such thing as a "config", it is just a way of describing the current directory. We might want to consider adding a variable #CURRENTCONFIG# which would be nothing but a copy of #CURRENTPATH# without the trailing "\". Otherwise we will get questions about this from time to time when folks are trying to activate or deactivate the current config and want to make it "generic" so they don't have to hard code the name of the config.

I may need to supplement with my comment a little bit.

In the case where #CURRENTPATH# is used, I can consider the situation where the "CurrentConfig" oneself becomes the object. Basically, When "CurrentConfig" oneself receives BANG command, we do not need to specify [config-name]. Because if [config-name] is omitted, the command is inevitably sent to the "CurrentConfig". So when you want to close "CurrentConfig" oneself, only "[!RainmeterDeactivateConfig]" is enough.

On the other hand, though when other Config is operated by BANG, the specification of [config-name] is indispensable, it is not possible to deal in this case uniformly by the universal variable anymore.

Good point, I will pass this info back the user with the question.