Declined Allow (require?) "0x" in environment variable type 3 (hex)

[vefatica]

Allow (require?) "0x" in environment variable type 3 (hex).

Also, could @VARTYPE show the regex when type is 7.

I like this type (though I don't much care for '0X').

/t:7:"^0[xX][0-9a-fA-F]+$"

 

[rconn]

What's special about type = 7 that @VARTYPE should break existing code?

 

[vefatica]

What's special about type = 7 that @VARTYPE should break existing code?

You have no idea what type 7 is without seeing the regex. The other types are spelled out in the help.

 

[rconn]

That doesn't make sense - you know it's a regex. You don't know what the regex *is* without a SET, but you don't know the value of any of the other types either without a SET. Why would breaking @VARTYPE be an improvement over simply looking at the variable?

Regarding type 3 - it doesn't really matter if I allow 0x. Everybody who's been using it will have to modify their code to accept it.

Both of these suggestions are breaking changes, and I'm not going to change @VARTYPE to break every batch file / alias that has been using it.

 

[vefatica]

I can't see allowing the prefix "0x" for type 3 breaking much.

 

[rconn]

I can't see allowing the prefix "0x" for type 3 breaking much.

It will if (as it always has been) the user code reading the variable isn't expecting a leading 0x. Or did you want TCC to always strip a leading 0x? (In which case, why are you entering it?)

 

[vefatica]

It will if (as it always has been) the user code reading the variable isn't expecting a leading 0x. Or did you want TCC to always strip a leading 0x? (In which case, why are you entering it?)

If "0x" were allowed (not required) and the user got a "0x" he wasn't expecting, I imagine he must have put it there.

To use a hex number you almost always have to have the prefix (always in the case of @EVAL). It seems easier to to that when a variable is created than every time it's used.