Environment variables have some nasty edge cases
Windows Environment Var Names are not Case-Sensitive
Whoever sets the variable first lays claim to the case, so:
C:\> set WHATEVER="foo"
C:\> set WhAtEvEr="bar"
If you list the environment variables after that, it will say WHATEVER="bar"
I nearly hate this enough to want to fix it by layering on a case-sensitive default behavior, and try and force Windows users to straighten out their systems and use consistent casing.
>> env.WhAtEvEr: "bar"
** Error: existing environment variable casing is WHATEVER, not WhAtEvEr
Beyond just bringing about more sanity in the world, this would mean your programs would run better cross-platform (as I try to maintain Windows, Mac, Linux, HaikuOS, etc. I'm particularly attuned to when these undesirable design choices make that miserable.)
It's technically possible to do this. But you'd need a way to get past it.
-
There could be a setting on the ENVIRONMENT! you can tweak regarding case sensitivity.
-
It could be a difference in behavior between WORD! lookup and TEXT! lookup
- (I like this less, because it seems unmotivated)
Empty Strings <> Unset Variables (But APIs Confuse...)
Setting an environment variable to an empty string is possible, and it's not the same as the environment variable not being set.
The prescriptivist in me says you should avoid this pattern. One thought I have is that this could be a "null-vs-trash-vs-text" distinction, e.g. if:
C:\> set SOME_VAR=""
Then...
>> env.SOME_VAR
== ~null~ ; anti
Basically, disallow you from setting environment variables to empty strings, and consider that empty state to be something you have to handle specially.
Although...this dovetails in an interestingly with raised errors for variables that aren't there:
>> env.ASDFASDF
** Error: ASDFASDF not assigned in environment
Because TRY converts that raised error to a null:
>> try env.ASDFASDF
== ~null~ ; anti
This means that if you're willing to accept non-set environment variables, you can conflate their intents just by getting null for them and environment variables set to empty strings. If you need to discern them, then you'd use EXCEPT to say what to do with the not set case differently from the set to empty string case.
I like it... BUT I'm not so keen on letting you set environment variables to NULL and producing empty strings casually, when what you meant to do was set them to VOID to remove them. But you have to know the difference when setting fields in objects.
Anyway, just throwing this out there. As usual, I think we have opportunities to be a force for sanity, and there can always be a fallback for people who want to live in the ugly world... just don't make ugly the default.