14.01.33 unset doesn't complain about undefined variables

[Stefano Piccardi]

As the help file says, option /Q keeps UNSET from complaining about undefined variables, and it used to be that - without /Q - unset did complain about such variables. Apparently now it doesn't complain anymore, but it should.

C:\>type x.btm
set x=
set x
unset x
C:\>x.btm
set x=
set x
TCC: C:\temp\maxleo\x.btm [2] Not in environment "x*"
unset x

C:\>ver

TCC 14.01.33 Windows 7 [Version 6.1.7601]

C:\>

 

[Howard Goldstein]

As the help file says, option /Q keeps UNSET from complaining about undefined variables, and it used to be that - without /Q - unset did complain about such variables. Apparently now it doesn't complain anymore, but it should.

C:\>type x.btm
set x=
set x
unset x
C:\>x.btm
set x=
set x
TCC: C:\temp\maxleo\x.btm [2] Not in environment "x*"
unset x

C:\>ver

TCC 14.01.33 Windows 7 [Version 6.1.7601]

C:\>

It works correctly here. Are you sure you don't have an alias for UNSET?

--
Howard

 

[vefatica]

Here, none of v11, v12, v13, v14 produce an error message on Win7. This may have something to do with Windows versions. Under Win7, a call to SetEnvironmentVariable(L"variable", NULL) succeeds when "variable" doesn't exist, and also in that case GetLastError() returns 0. That's OK with me.

 

[Steve Fabian]

Here, none of v11, v12, v13, v14 produce an error message on Win7. This may have something to do with Windows versions. Under Win7, a call to SetEnvironmentVariable(L"variable", NULL) succeeds when "variable" doesn't exist, and also in that case GetLastError() returns 0. That's OK with me.

I agree with Vince - the purpose of UNSET is to remove a single variable or a whole set of variables. IMHO it is not an error to remove a variable that did not exist - it means that your goal has already been accomplished. For my own use, I have always aliased UNSET=*UNSET /Q i.e. the new operation.

What would be the purpose of checking the existence of a variable using UNSET anyway? If its existence before UNSET is relevant, it should be checked with IF DEFINED, a test which allows using the value before destroying it (though in some cases all that matters whether or not the variable is defined, not its value).

Rex:
From the performance standpoint, when one uses only the existence or absence of a variable (i.e., using IF DEFINED test), what is the best value to set the variable to? I realize that the difference between different values is minimal, unless it is done millions of times.
--
Steve

 

[vefatica]

From the performance standpoint, when one uses only the existence or absence of a variable (i.e., using IF DEFINED test), what is the best value to set the variable to? I realize that the difference between different values is minimal, unless it is done millions of times.

No doubt, a one-character value would be best. If the value is being fetched, it must be copied. And even if it's not to be fetched, (GetEnvironmentVariable() with a NULL buffer) it's length must be determined. That said, it probably takes under a microsecond to do either in most cases. And from a practical point of view if you're only testing for existence, "1", "true", "on", "yes", or any of myriad other values might serve to remind the batch programmer what he's doing.

Actually ... SetEnvironmentVariable() allows the value L"" (empty string). A variable with no value shows up if you GetEnvironmentStrings(). If such a variable is set, GetEnvironmentVariable() will return 0 (the length of the data, typically meaning failure) but GetLastError() will be 0 (ERROR_OK). OTOH if it's not set, GetEnvironmentVariable() will return 0, and GetLastError() will be 203 ("The system could not find the environment option that was entered."). I suppose a shell could allow variables with no value, and "IF DEFINED" could be made to work correctly with them. But why ... to save one keystroke and (perhaps) a nanosecond? I wonder what "IF DEFINED" would say if a plugin set a variable with an empty string as value.

 

[David Marcus]

What would be the purpose of checking the existence of a variable using UNSET anyway?

To catch typos.

 

[rconn]

As the help file says, option /Q keeps UNSET from complaining about undefined variables, and it used to be that - without /Q - unset did complain about such variables. Apparently now it doesn't complain anymore, but it should.

Neither does CMD.EXE.

Since Microsoft changed the behavior in Windows 7, the only way for TCC to do this would be to try to read the variable first before attempting to delete it. Which would slow everything down measurably, and result in error messages being returned in scripts that do not display errors with CMD.

 

[Charles Dye]

Perhaps the best solution in this case is to update the documentation to match the actual behavior...?

 

[Stefano Piccardi]

Perhaps the best solution in this case is to update the documentation to match the actual behavior...?

Yes.