Case sensitivity of environmental variables in Windows

[NiceGuyIT]

I'm using task to write cross-platform tasks and in doing so, I need to work through any OS specific issues. One issue is with case sensitivity of environmental variables. The statement that env vars are case sensitive in this comment is true for *nix but not for Windows. Consider the following PowerShell.

PS C:\Users\dev\projects\taskfiles\tmp> $ENV:val_lowercase = "lowercase"
PS C:\Users\dev\projects\taskfiles\tmp> $ENV:VAL_LOWERCASE
lowercase
PS C:\Users\dev\projects\taskfiles\tmp> $ENV:VAL_LOWERCASE = "uppercase"
PS C:\Users\dev\projects\taskfiles\tmp> $ENV:val_lowercase
uppercase

Since Task treats environmental variables as case sensitive, I need to use the case sensitive form when used as {{.VAR}} but not when used as $ENV:Var. This is not a problem until I run a task in another task at which point Task will make all environmental variables uppercase in {{.VAR}}. This Taskfile.yaml demonstrates this.

---
version: '3'

tasks:

  print-powershell-env:
    desc: Prints the environmental variables using PowerShell
    env:
      PROGRAMDATA: '{{.PROGRAMDATA | default "non-existent"}}'
    vars:
      PROGRAMDATA_VAR: '{{.PROGRAMDATA_VAR | default "non-existent"}}'
    cmds:
      - cmd: |
          echo "sub-task environment"
          echo "\$ProgramData: \"$ProgramData\""
          echo "\$PROGRAMDATA: \"$PROGRAMDATA\""
          echo '{{ print `{{.ProgramData}}` }}: "{{.ProgramData}}"'
          echo '{{ print `{{.PROGRAMDATA}}` }}: "{{.PROGRAMDATA}}"'
          echo 'PROGRAMDATA_VAR: {{.PROGRAMDATA_VAR}}'
      - cmd: |
          powershell -NonInteractive -NoProfile -NoLogo -InputFormat text -OutputFormat text -Command '
            Write-Output "PowerShell ENV:ProgramData: $ENV:ProgramData"
            Write-Output "PowerShell ENV:PROGRAMDATA: $ENV:PROGRAMDATA"
          '
        platforms:
          - windows

  print-task-env:
    desc: Prints the environmental variables using Task
    env:
      PROGRAMDATA: '{{.PROGRAMDATA | default "non-existent"}}'
    vars:
      PROGRAMDATA_VAR:
        sh: |
          echo $PROGRAMDATA
    cmds:
      - cmd: |
          echo "Original environment"
          echo "\$ProgramData: \"$ProgramData\""
          echo "\$PROGRAMDATA: \"$PROGRAMDATA\""
          echo '{{ print `{{.ProgramData}}` }}: "{{.ProgramData}}"'
          echo '{{ print `{{.PROGRAMDATA}}` }}: "{{.PROGRAMDATA}}"'
          echo 'PROGRAMDATA_VAR: {{.PROGRAMDATA_VAR}}'
          echo "Calling task print-powershell-env"
          echo ""
          task --silent print-powershell-env

Output:

PS C:\Users\dev\projects\taskfiles\tmp> task --silent print-task-env
Original environment
$ProgramData: "C:\ProgramData"
$PROGRAMDATA: "C:\ProgramData"
{{.ProgramData}}: "C:\ProgramData"
{{.PROGRAMDATA}}: ""
PROGRAMDATA_VAR: C:\ProgramData
Calling task print-powershell-env

sub-task environment
$ProgramData: "C:\ProgramData"
$PROGRAMDATA: "C:\ProgramData"
{{.ProgramData}}: ""
{{.PROGRAMDATA}}: "C:\ProgramData"
PROGRAMDATA_VAR: non-existent
PowerShell ENV:ProgramData: C:\ProgramData
PowerShell ENV:PROGRAMDATA: C:\ProgramData

Notice how $ProgramData and $PROGRAMDATA are the same because env vars are case insensitive on Windows. The docs state variables are populated (interpolated) with environmental variables being lowest importance. The translation from case-insensitive env vars to case-sensitive variables changes when Task calls itself, implying the internal env var representation is UPPERCASE and passed to future invocations within a task.

If environmental variables are case sensitive, the case should be preserved, even in sub-tasks such that {{.SOME_VAR}} works in call cases.

Also note that casting an env: to vars: using sh: | does not work in the main task (for reasons mentioned in other issues) but can be used to pass env vars consistently to sub-tasks using variables.

Feature Request: Make this work without checking both versions of the variable name interpolated from the environmental name. I recognize name=$ProgramData works but then I lose the richness of Go's templating, mainly osClean.

Note: This is probably specific to Windows since env vars are case sensitive in other OS's.