Provide a platform-agnostic way to determine the temp. directory, e.g., via an automatic variable.

^{Related: #3442 and #4215}

The various supported platforms have different native ways to determine the directory in which to store temporary files and directories:

• Windows:
  • $env:TEMP
• macOS:
  • $env:TMPDIR
• Linux:
  • /tmp

Currently, there is no platform-agnostic way to refer to this directory, which is cumbersome.

An automatic variable, say $TEMP, could provide this abstraction.

Environment data

PowerShell Core v6.0.0-beta.3

[iSazonov]

Why we cannot use [system.io.path]::GetTempPath()?

https://github.com/dotnet/coreclr/blob/6ba74dc2a7194f8d6c86c3aeab572a074ef645c8/src/mscorlib/shared/System/IO/Path.Unix.cs#L153 https://github.com/dotnet/coreclr/blob/6ba74dc2a7194f8d6c86c3aeab572a074ef645c8/src/mscorlib/shared/System/IO/Path.Windows.cs#L94

[Jaykul]

Short answer: [IO.Path]::GetTempPath() is the ONLY answer.

The idea that we need to protect people from learning about .NET is, frankly, silly. That static method is backwards compatible all the way to Windows PowerShell 1.0 and no matter how many improvements we add in the future, it’s still the one and only correct answer to the original question today (over a year after it was asked and answered).

However, I like the idea that we should make this easier in the future, even though anything we come up with won’t be reliably usable for years, because PowerShell Core 6 and 6.1 have already shipped without it.

Of all the ideas expressed above, the only idea I like (and I love it) is the idea of creating a Temp: drive and pointing it at (a new folder named after a GUID and/or date in) the location returned by [IO.Path]::GetTempPath() (and maybe cleaning it up when PowerShell exits). Creating a Temp drive is something we can easily do in both PowerShell Core and in a compatibility module for already released versions. It’s very unlikely to cause a problem (it’s just a question of whether anyone is likely to have created a Temp: drive) and if it does, fixing it in the script where that problem occurs would be trivial.

Obviously we could also add New-TempDirectory to the New-TempFile command – but that should be done in an external module to start with so that it can be inherently cross-platform and backwards compatible.