在Linux上，我可以做:
$ FOO=BAR ./myscript
在设置环境变量FOO的情况下调用myscript。
在PowerShell中是否可能出现类似的情况，即无需首先设置变量，调用命令，然后再次取消设置变量?
为了更清楚地说明我的用例——我不想把它用作脚本的一部分。相反，我有一个第三方脚本，我可以使用环境变量控制其行为，但在本例中，不能使用命令行参数。所以能够在打字之间交替
$ OPTION=1 ./myscript
and
$ ./myscript
会很方便的。
当前回答
可以将变量作用于函数和脚本。
$script:foo = "foo"
$foo
$function:functionVariable = "v"
$functionVariable
New-Variable也有一个-scope参数，如果你想要正式并使用New-Variable声明你的变量。
其他回答
要实现与Unix语法相同的功能，您不仅必须设置环境变量，还必须在执行命令后将其重置为以前的值。通过在PowerShell概要文件中添加类似于下面的函数，我已经为我使用的常见命令实现了这一点。
function cmd_special()
{
$orig_master = $env:app_master
$env:app_master = 'http://host.example.com'
mycmd $args
$env:app_master = $orig_master
}
mycmd是一些可执行文件，根据环境变量app_master的值，它的操作方式不同。通过定义cmd_special，我现在可以使用app_master环境变量set…从命令行执行cmd_special(包括其他参数)。在执行命令后，它会被重置(甚至取消设置)。
据推测，您也可以为单个调用执行这种临时操作。
& { $orig_master = $env:appmaster; $env:app_master = 'http://host.example.com'; mycmd $args; $env:app_master = $orig_master }
实际上应该比这个简单，但显然PowerShell并不支持这种用例。也许未来的版本(或第三方功能)将促进这个用例。如果PowerShell有一个cmdlet可以做到这一点，那就太好了，例如:
with-env app_master='http://host.example.com' mycmd
也许PowerShell专家可以建议如何编写这样的cmdlet。
可以将变量作用于函数和脚本。
$script:foo = "foo"
$foo
$function:functionVariable = "v"
$functionVariable
New-Variable也有一个-scope参数，如果你想要正式并使用New-Variable声明你的变量。
一般来说，通过参数传递信息给脚本比通过参数传递信息更好 全局(环境)变量。但如果这是你需要做的，你可以这样做:
$env:FOO = 'BAR'; ./myscript
环境变量$env:FOO可以稍后删除，如下所示:
Remove-Item Env:\FOO
两种简单的方法:
$env:FOO='BAR'; .\myscript; $env:FOO=''
$env:FOO='BAR'; .\myscript; Remove-Item Env:\FOO
只是从其他答案(谢谢大家)中总结了一些信息，出于某种原因，这些答案不包含纯一行程序。
你可以通过将脚本作为Job运行来实现:
Start-Job -InitializationScript { $env:FOO = 'BAR' } -FilePath .\myscript.ps1 |
Receive-Job -Wait -AutoRemoveJob
你也可以使用Start-Job的ArgumentList参数向脚本传递参数:
$jobArgs = @{
InitializationScript = { $env:FOO = 'BAR' }
FilePath = '.\myscript.ps1'
ArgumentList = 'arg1', 'arg2'
}
Start-Job @jobArgs | Receive-Job -Wait -AutoRemoveJob
优点和缺点
You don't have to reset the environment variable after the script finishes (which would require try / finally to do it correctly even in the presence of exceptions). The environment variable will be really local to the launched script. It won't affect other, possibly launched in parallel, jobs. The script will run in its own, somewhat isolated environment. This means that the launched script can't set variables of the main script, it has to write to the success stream (implicitly or by calling another command that already writes to the success stream) to communicate back to the main script. This could be an advantage or a disadvantage, depending on the use case.
