Implement `Export` command to allow setting of environment variables in a bash-like way

[JohnLBevan]

Summary of the new feature / enhancement

As a scripter I want to be able to run export DEMO_CLIENT_ID="ff3b7b84-e041-4e76-993e-239930808aa7" in powershell and have it update the DEMO_CLIENT_ID environment variable with a value of ff3b7b84-e041-4e76-993e-239930808aa7 as it would in Bash.

PowerShell has been written to mirror shell script in many cases, often providing aliases for PowerShell cmdlets to allow the shell script syntax to be used without modification.
One of the most common things we see in sample code / documentation is the use of Linux export statement; often this documentation doesn't have the PowerShell equivalent (e.g. TerraForm's docs) meaning examples are harder to follow / require more effort to amend syntax. Having native support for an export command would save many users effort.

Proposed technical implementation details (optional)

Something similar to the below would be good. Note: this is a quick version that I knocked up for personal use; it's not yet a perfect like-for-like with the linux/mac shell script equivalent; but works in the majority of simple use cases.

Function Export {
    $regex = [System.Text.RegularExpressions.Regex]::new('^\s*([^=]+?)\s*=(.*)$')
    $result = $regex.Match(($args -join ' '))
    if (!$result.Success) {
        throw "Could not set an environment variable based on [$($args -join ' ')]"
    }
    [Environment]::SetEnvironmentVariable($result.Groups[1].Value, $result.Groups[2].Value)
}

Side note: I've also posted this function to StackExchange's CodeReview, so improved versions or feedback on the above may be available.

[237dmitry]

I use $env:Variable = "Value" syntax. For example for coloring linux manual pages:

$env:LESS = "-R"
$env:LESS_TERMCAP_mb = "`e[1;31m"
$env:LESS_TERMCAP_md = "`e[1;36m"
$env:LESS_TERMCAP_me = "`e[0m"   
$env:LESS_TERMCAP_so = "`e[1;33m"
$env:LESS_TERMCAP_se = "`e[0m"   
$env:LESS_TERMCAP_us = "`e[1;32m"
$env:LESS_TERMCAP_ue = "`e[0m"   
$env:GROFF_NO_SGR = "1"

[mklement0]

Related:

• Provide simple one-time setting of environment variable #3316

As for providing a built-in export command:
That name should be an alias, whereas the implementing command should follow PowerShell's naming conventions, analogous to exec vs. Switch-Process (even though, for technical reasons, exec eventually became a function that calls Switch-Process).

I've posted a proof-of-concept as an answer to your codereview.stackexchange.com question.

[StartAutomating]

@JohnLBevan I'm with @mklement0 on the naming concern here.

"Export" is probably the right verb.

I'd call it Export-Environment, personally.

Additionally, I think we might want to make this hypothetical command support dictionary / PSObject input.

I'm less certain it is something that should be part of PowerShell itself (as $env: already does the job for an environment variable)

[JohnLBevan]

I'm in favour of the code suggested by @mklement0 on the code review post (quoted below for convenience):

Set-Alias export Set-EnvironmentVariableByNameValuePair

function Set-EnvironmentVariableByNameValuePair {
  param(
    [Parameter(Mandatory, ValueFromPipeline, ValueFromRemainingArguments)]
    [string[]] $NameValuePair
  )
  process {
    foreach ($pair in $NameValuePair) {
       $name, $value = $pair -split '=', 2
       if (-not $name -or -not $value) { Write-Error "Not in <name>=<value> format: `"$pair`". For technical reasons, you must supply a value."; continue }
       Set-Content Env:$name $value
    }
  }
}

i.e. This uses the Set verb, which is correct as we're setting the value of an environment variable; then creating an alias export so we can use it in the same way as export works in other OS's shells.

As @StartAutomating suggests, having this cmdlet also take input from hashtable/dictionary/psobject is a good way to set multiple variables at once (e.g. it could iterate through their name-value pair collections and assign those values to environment variables of the same name). The aim I had in mind when creating this post was just to narrow the gap between various shells; but if we can also implement additional logic I've no objections.
Here's a tweak to @mklement0 's version which would implement that additional functionality, if there's a desire for it.

function Set-EnvironmentVariableByNameValuePair {
  [CmdletBinding(DefaultParameterSetName='ByNVPArray')]
  Param(
    [Parameter(ParameterSetName='ByNVPArray',Mandatory, ValueFromPipeline, ValueFromRemainingArguments)]
    [string[]] $NameValuePair
    ,
    [Parameter(ParameterSetName='ByIDictionary', Mandatory, ValueFromPipeline)]
    [System.Collections.IDictionary] $Dictionary
    ,
    [Parameter(ParameterSetName='ByPSObject', Mandatory, ValueFromPipeline)]
    [PSObject] $InputObject
  )
  process {
    if ($PSCmdlet.ParameterSetName -eq 'ByNVPArray') {
      foreach ($pair in $NameValuePair) {
        $name, $value = $pair -split '=', 2
        if (-not $name -or -not $value) { Write-Error "Not in <name>=<value> format: `"$pair`". For technical reasons, you must supply a value."; continue }
        Set-Content Env:$name $value
      }
      return
    }
    if ($PSCmdlet.ParameterSetName -eq 'ByPSObject') {
        $Dictionary = @{}
        $InputObject.PSObject.Properties | ForEach-Object {$Dictionary.Add($_.Name, $_.Value)}
    }
    foreach ($pair in $Dictionary.GetEnumerator()) {
      if (-not $pair.Value) { Write-Error "$($pair.Key) has an invalid value: `"$($pair.Value)`". For technical reasons, you must supply a value."; continue }
      Set-Content Env:$($pair.Name) $pair.Value
    }
  }
}

[iRon7]

@237dmitry,

I use $env:Variable = "Value" syntax. For example for coloring linux manual pages:

I guess @JohnLBevan is looking for a Run-Time solution

@JohnLBevan ,
I suspect the propose is helpful as a custom cmdlet but to specific to make it into a standard PowerShell cmdlet (taken e.g. that this only applies to the Env: provider).
At the other hand, I see 3 general things that could be considered to make this use case easier to implement.
(see: #20489, #20490 #20491)

These 3 proposals will allow for syntaxes along with (wishful thinking):

$HashTable = @{ DEMO_CLIENT_ID="ff3b7b84-e041-4e76-993e-239930808aa7"; Name = "Value" }
Invoke-Comand -Location "ENV:"  { $HashTable | Set-Content }

and

$Json = {
  "DEMO_CLIENT_ID": "ff3b7b84-e041-4e76-993e-239930808aa7",
  "Name": "Value"
}
$Json | ConvertFrom-Json | ForEach-Object -Property { Set-Content Env:$($_.Name) $_.Value }

[JohnLBevan]

Thanks @iRon7 ; those are interesting ideas.

The aim of what I'm proposing here is closing the gap on syntax differences between shells for common features; so whilst those are interesting options that would allow other ways to set values for environment variables; the aim of this request is to enable support for the specific export name=value syntax.

[iRon7]

@JohnLBevan,
Agreed, my general proposes are no reason to exclude this propose, it is up to the PowerShell team to make the decision for this.

[JamesWTruher]

in powershell all environment variables are "exported", what ps does not have is a way to keep variables from being exported when a new process is executed (or for a single invocation as suggested by mklement0). It boils down to how new processes are started by dotnet.

[SteveL-MSFT]

@JamesWTruher I don't think the problem is the action of exporting env vars, but the syntax. I believe the ask is to support the same syntax as bash making it easier to port scripts. My concern is that this is just the tip of an iceberg and even if this is supported, many other aspects of bash syntax won't work.

[StartAutomating]

My concern is that this is just the tip of an iceberg and even if this is supported, many other aspects of bash syntax won't work.

Agreed!

Also:

I, for one, would not like it if PowerShell started camping the word Export only to use it for psuedo compatibility with Bash (it would create conflicts with future intentions for export).

[JohnLBevan]

I believe the ask is to support the same syntax as bash making it easier to port scripts.

Thank-you @SteveL-MSFT ; that's correct.

My concern is that this is just the tip of an iceberg and even if this is supported, many other aspects of bash syntax won't work.

Understood; my thinking was that PowerShell already does this aliasing in a lot of places (e.g. cat, ls); but agreed that in those cases there's already a cmdlet that handles near identical behaviour; whilst for this export use case it's more fiddly / not as simple as aliasing Set-Item / Set-Content given those cmdlets handle content other than environment variables, and would need the env: prefix for any paths appended to work this way.

Happy to close this if people are against the proposal in general; or to leave it open to debate for longer if anyone feels it's worth it? My own requirement's met by copying mklement0's code into my profile script anyway.