ChatGPT解决这个技术问题 Extra ChatGPT

How do I get the current username in Windows PowerShell?

How do I get the current username in Windows PowerShell?


P
Peter Mortensen

I found it:

$env:UserName

There is also:

$env:UserDomain
$env:ComputerName

The answer is just using a static .NET method from within Powershell which might be a useful technique to use elsewhere.
Not currently logged user but simply environment variables! Do not answer the question.
C
Chris F Carroll

On Windows, you can:

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

This is the most secure answer because $env:USERNAME can be altered by the user, but this will not be fooled by doing that.
@KevinPanko True, but at the point that you can't trust your user, there are other, more philosophical questions that need to be asked. ;-)
This method includes the domain name and username. Definitely beneficial if you have multiple domains in play.
Works as expected. Tested for url address reservation.
Also, this looks to work in PowerShell 6 as well, meaning it's cross platform (.Net Standard) compatible. Thought it was worth mentioning since I questioned it when I saw the namespace.
P
Peter Mortensen

I thought it would be valuable to summarize and compare the given answers.

If you want to access the environment variable:

(easier/shorter/memorable option)

[Environment]::UserName -- @ThomasBratt

$env:username -- @Eoin

whoami -- @galaktor

If you want to access the Windows access token:

(more dependable option)

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name -- @MarkSeemann

If you want the name of the logged in user

(rather than the name of the user running the PowerShell instance)

$(Get-WMIObject -class Win32_ComputerSystem | select username).username -- @TwonOfAn on this other forum

Comparison

@Kevin Panko's comment on @Mark Seemann's answer deals with choosing one of the categories over the other:

[The Windows access token approach] is the most secure answer, because $env:USERNAME can be altered by the user, but this will not be fooled by doing that.

In short, the environment variable option is more succinct, and the Windows access token option is more dependable.

I've had to use @Mark Seemann's Windows access token approach in a PowerShell script that I was running from a C# application with impersonation.

The C# application is run with my user account, and it runs the PowerShell script as a service account. Because of a limitation of the way I'm running the PowerShell script from C#, the PowerShell instance uses my user account's environment variables, even though it is run as the service account user.

In this setup, the environment variable options return my account name, and the Windows access token option returns the service account name (which is what I wanted), and the logged in user option returns my account name.

Testing

Also, if you want to compare the options yourself, here is a script you can use to run a script as another user. You need to use the Get-Credential cmdlet to get a credential object, and then run this script with the script to run as another user as argument 1, and the credential object as argument 2.

Usage:

$cred = Get-Credential UserTo.RunAs
Run-AsUser.ps1 "whoami; pause" $cred
Run-AsUser.ps1 "[System.Security.Principal.WindowsIdentity]::GetCurrent().Name; pause" $cred

Contents of Run-AsUser.ps1 script:

param(
  [Parameter(Mandatory=$true)]
  [string]$script,
  [Parameter(Mandatory=$true)]
  [System.Management.Automation.PsCredential]$cred
)

Start-Process -Credential $cred -FilePath 'powershell.exe' -ArgumentList 'noprofile','-Command',"$script"

For PowerShell 6 on Mac OS X and Linux, [Environment]::UserName is the best option, as it works cross platform. whoami seems to also work, but depends on the whoami tool being available on the platform.
For Powershell 6 on Windows, $env:USERNAME produces SYSTEM unless I run-as-administrator, while [Environment]::UserName] yields my username either way.
Seem like the Get-WmiObject method no longer works in pwsh. Even tried to import compatibility module and the Microsoft.PowerShell.Management that has the cmdlet. Any idea what's happening?
Correct. It was fazed over to Get-CimInstance quite a while back for performance reasons... and CIM has to be used over WMI in v6 for cross-compatibility reasons. If you see a command with GWMI, check if you can do GCIM instead.
J
Jasper

$env:username is the easiest way


You can assign it this way, and build up directories and what not.
g
galaktor

I'd like to throw in the whoami command, which basically is a nice alias for doing %USERDOMAIN%\%USERNAME% as proposed in other answers.

Write-Host "current user:"
Write-Host $(whoami)

it works for me on PS version 2. Are you saying it was dropped in PS3? C:\>powershell Windows PowerShell Copyright (C) 2009 Microsoft Corporation. All rights reserved. PS C:\> whoami mydomain\myusername
$env:USERNAME can be altered by the user, but this will not be fooled by doing that.
whoami wins for interactive use. It's short enough that I can remember how to type it without consulting SO :-)
Not a thing in Nano Server. Don't use it in scripts, do the correct thing ([System.Security.Principal.WindowsIdentity]::GetCurrent().Name)
whoami is an executable. It can't be removed from PowerShell. It could potentially be removed from Windows, but it's still there as of non-Nano Windows Server 2012.
W
WaffleSouffle

[Environment]::UserName returns just the user name. E.g. bob [System.Security.Principal.WindowsIdentity]::GetCurrent().Name returns the user name, prefixed by its domain where appropriate. E.g. SOMEWHERENICE\bob


P
Peter Mortensen

Now that PowerShell Core (aka v6) has been released, and people may want to write cross-platform scripts, many of the answers here will not work on anything other than Windows.

[Environment]::UserName appears to be the best way of getting the current username on all platforms supported by PowerShell Core if you don't want to add platform detection and special casing to your code.


P
Peter Mortensen

I have used $env:username in the past, but a colleague pointed out it's an environment variable and can be changed by the user and therefore, if you really want to get the current user's username, you shouldn't trust it.

I'd upvote Mark Seemann's answer: [System.Security.Principal.WindowsIdentity]::GetCurrent().Name

But I'm not allowed to. With Mark's answer, if you need just the username, you may have to parse it out since on my system, it returns hostname\username and on domain joined machines with domain accounts it will return domain\username.

I would not use whoami.exe since it's not present on all versions of Windows, and it's a call out to another binary and may give some security teams fits.


Since the OP did ask about Windows-Powershell, that's valid, but [Environment]::UserName is less typing, independent of $env:username and cross-platform: See pastebin.com/GsfR6Hrp
P
Peter Mortensen

Just building on the work of others here:

[String] ${stUserDomain},[String]  ${stUserAccount} = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name.split("\")

S
Simbarashe Timothy Motsi
$username=( ( Get-WMIObject -class Win32_ComputerSystem | Select-Object -ExpandProperty username ) -split '\\' )[1]

$username

The second username is for display only purposes only if you copy and paste it.


$fullname=Get-WMIObject -class Win32_ComputerSystem | Select-Object -ExpandProperty username $username=$fullname.Replace("DOMAIN\","") $username
This one works the best if you want the user logged on to the machine, not the user running the powershell session. If you are running a script as system and want to know what user is logged on to the machine, the env variables dont help.
As per my investigation it seems that it is better to use Get-CIMInstance instead of Get-WMIObject. Please refer to the article here.
P
Peter Mortensen

I didn't see any Add-Type based examples. Here is one using the GetUserName directly from advapi32.dll.

$sig = @'
[DllImport("advapi32.dll", SetLastError = true)]
public static extern bool GetUserName(System.Text.StringBuilder sb, ref Int32 length);
'@

Add-Type -MemberDefinition $sig -Namespace Advapi32 -Name Util

$size = 64
$str = New-Object System.Text.StringBuilder -ArgumentList $size

[Advapi32.util]::GetUserName($str, [ref]$size) |Out-Null
$str.ToString()

Please explain what this code is doing and why it would be more useful than one of the shorter methods.
@BenjaminHubbard The question does not ask for the shortest method, it asks how to accomplish the feat with powershell. This does the trick differently then the other examples by calling the function inside the dll and using the Add-Type method to access .NET.
While this is a novel code block, it would be great if I knew what the heck it was doing. Can you annotate it with comments, maybe? Thanks!
I almost wanted to upvote, since I saw merit to the proposal. Yet the code has some flaws: it introduces a new namespace, it uses a magic constant (64) which value is not what the doctor prescribed (should be UNLEN+1, and UNLEN is 256), it disregards any error which might be returned from GetUserName (through it preserves GetLastError, a good point), it does not clean up the string buffer; and probably some others. And as others said, comments are sorely missing, too.
s
shaws

If you're used to batch, you can call

$user=$(cmd.exe /c echo %username%)

This basically steals the output from what you would get if you had a batch file with just "echo %username%".


I'm downvoting because: a) You the $(...) is superfluous: $a = cmd.exe /c echo %username% works, b) it's not portable, c) it doesn't actually answer the question of how to do it in powershell, it answers how to do it in dos, and it's better to give a man a fishing pole than give him a fish, e.g. powershell puts environment variables into $env, so %username% = $env:username.
K
Kes tas

I find easiest to use: cd $home\Desktop\

will take you to current user desktop

In my case, I needed to retrieve the username to enable the script to change the path, ie. c:\users\%username%. I needed to start the script by changing the path to the users desktop. I was able to do this, with help from above and elsewhere, by using the get-location applet.

You may have another, or even better way to do it, but this worked for me:

$Path = Get-Location

Set-Location $Path\Desktop


Making any assumptions based on the home directory is bound to only work under very specific conditions.
If you are working in a powershell terminal and just quickly want to find out what user you are, then typing "ls ~" should do the trick. Like the above poster, there might be exceptions, and this is definitely not good for scripts, so use Edouard Poor's example in that case.
T
Thomas Baruchel

In my case, I needed to retrieve the username to enable the script to change the path, ie. c:\users\%username%\. I needed to start the script by changing the path to the users desktop. I was able to do this, with help from above and elsewhere, by using the get-location applet.

You may have another, or even better way to do it, but this worked for me:

$Path = Get-Location

Set-Location $Path\Desktop

Welcome to Stack Overflow! This is equivalent to Set-Location Desktop. (Get-Location merely returns the current location, which is implicit for a Set-Location with a relative path.)