Как получить текущее имя пользователя в Windows PowerShell?
Как получить текущее имя пользователя в Windows PowerShell?
Ответы:
Я нашел это:
$env:UserName
А также есть:
$env:UserDomain
$env:ComputerName
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$env:USERNAME
может изменить его, но это не обманет.
Я подумал, что было бы полезно обобщить и сравнить приведенные ответы.
(проще / короче / запоминающийся вариант)
[Environment]::UserName
- @ThomasBratt$env:username
- @Eoinwhoami
- @galaktor(более надежный вариант)
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
- @MarkSeemann(а не имя пользователя, на котором запущен экземпляр PowerShell)
$(Get-WMIObject -class Win32_ComputerSystem | select username).username
- @TwonOfAn на этом другом форумеКомментарий @Kevin Panko к ответу @Mark Seemann касается выбора одной из категорий над другой:
[Подход с использованием маркера доступа Windows] является наиболее безопасным ответом, потому что пользователь может изменить $ env: USERNAME, но это не обманет.
Короче говоря, параметр переменной среды является более лаконичным, а параметр маркера доступа Windows - более надежным.
Мне пришлось использовать подход маркера доступа Windows @Mark Seemann в скрипте PowerShell, который я запускал из приложения C # с олицетворением.
Приложение C # запускается с моей учетной записью пользователя и запускает сценарий PowerShell в качестве учетной записи службы. Из-за ограничения способа запуска сценария PowerShell из C # экземпляр PowerShell использует переменные среды моей учетной записи, даже если он запускается как пользователь учетной записи службы.
В этой настройке параметры переменной среды возвращают имя моей учетной записи, а параметр токена доступа Windows возвращает имя учетной записи службы (именно это я и хотел), а параметр зарегистрированного пользователя возвращает имя моей учетной записи.
Также, если вы хотите сравнить параметры самостоятельно, вот скрипт, который вы можете использовать для запуска скрипта от имени другого пользователя. Вам нужно использовать командлет Get-Credential для получения объекта учетных данных, а затем запустить этот сценарий со сценарием, который будет запускаться от имени другого пользователя в качестве аргумента 1, и для объекта учетных данных в качестве аргумента 2.
Использование:
$cred = Get-Credential UserTo.RunAs
Run-AsUser.ps1 "whoami; pause" $cred
Run-AsUser.ps1 "[System.Security.Principal.WindowsIdentity]::GetCurrent().Name; pause" $cred
Содержимое скрипта Run-AsUser.ps1:
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"
[Environment]::UserName
это лучший вариант, так как он работает кроссплатформенно. whoami
Кажется, также работает, но зависит от whoami
инструмента, доступного на платформе.
$env:USERNAME
выдает, SYSTEM
если я не запускаю от имени администратора, а в [Environment]::UserName]
любом случае возвращает мое имя пользователя.
Get-WmiObject
метод больше не работает в pwsh. Даже пытался импортировать модуль совместимости и тот, Microsoft.PowerShell.Management
который имеет командлет. Есть идеи, что происходит?
Я хотел бы добавить команду whoami , которая в основном является хорошим псевдонимом для выполнения, %USERDOMAIN%\%USERNAME%
как предлагается в других ответах.
Write-Host "current user:"
Write-Host $(whoami)
$env:USERNAME
может быть изменено пользователем, но это не обманет.
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
)
whoami
это исполняемый файл. Его нельзя удалить из PowerShell. Он потенциально может быть удален из Windows, но он все еще там,
[Environment]::UserName
возвращает только имя пользователя. Например, bob
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
возвращает имя пользователя с префиксом его домена, где это необходимо. Например, что-то другое \ боб
я использовал $env:username
в прошлом, но коллега отметил, что это переменная среды и может быть изменена пользователем, и поэтому, если вы действительно хотите получить имя пользователя текущего пользователя, вы не должны доверять ему.
Я бы поддержал ответ Марка Симанна: [System.Security.Principal.WindowsIdentity] :: GetCurrent (). Name
Но мне нельзя. С ответом Марка, если вам нужно только имя пользователя, вам, возможно, придется проанализировать его, так как в моей системе он возвращается, hostname\username
а на компьютерах, присоединенных к домену, с учетными записями домена он будет возвращатьсяdomain\username
.
Я бы не стал использовать whoami.exe
его, так как он присутствует не во всех версиях Windows, и это вызов другого бинарного файла, который может подойти некоторым группам безопасности.
[Environment]::UserName
менее типирование, независимо от $env:username
и кросс-платформенный: См pastebin.com/GsfR6Hrp
Теперь, когда ядро PowerShell (также известный как v6) выпущен, и люди могут захотеть писать кроссплатформенные сценарии, многие ответы здесь не будут работать ни на чем, кроме Windows.
[Environment]::UserName
представляется наилучшим способом получения текущего имени пользователя на всех платформах, поддерживаемых PowerShell Core, если вы не хотите добавлять в код обнаружение платформы и специальный регистр.
$username=( ( Get-WMIObject -class Win32_ComputerSystem | Select-Object -ExpandProperty username ) -split '\\' )[1]
$username
Второе имя пользователя для отображения только в целях , только если скопировать и вставить его.
Я не видел никаких примеров на основе Add-Type . Вот тот, кто использует GetUserName непосредственно из 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()
UNLEN+1
и UNLEN
равно 256), он игнорирует любую ошибку, которая может быть возвращена из GetUserName (через это сохраняет GetLastError, хороший момент), он не очищает строковый буфер; и, возможно, некоторые другие. И, как говорили другие, комментарии тоже крайне отсутствуют.
Я считаю, что проще всего использовать: cd $ home \ Desktop \
В моем случае мне нужно было получить имя пользователя, чтобы скрипт мог изменить путь, т.е. C: \ Users \% имя пользователя%. Мне нужно было запустить скрипт, изменив путь к рабочему столу пользователя. Я смог сделать это с помощью сверху и из других источников с помощью апплета get-location.
У вас может быть другой, или даже лучший способ сделать это, но у меня это сработало:
$ Path = Get-Location
Set-Location $ Path \ Desktop
Если вы привыкли к партии, вы можете позвонить
$user=$(cmd.exe /c echo %username%)
Это в основном крадет вывод из того, что вы получили бы, если бы у вас был командный файл с просто «echo% username%».
$(...)
лишний: $a = cmd.exe /c echo %username%
работает, б) он не переносим, в) он на самом деле не отвечает на вопрос, как сделать это в powershell, отвечает на вопрос, как это сделать в dos, и это лучше дать человеку удочку, чем дать ему рыбу, например powershell puts environment variables into $env, so %username% = $env:username
.
get-content "cm.txt"
write-host "entr file name"
$file = read-host
get-content $file
$content = get-content "cm.txt"
$content = get-content "cn.txt"
for each ($line in $count)
{write-host $line}
В моем случае мне нужно было получить имя пользователя, чтобы скрипт мог изменить путь, т.е. c:\users\%username%\
, Мне нужно было запустить скрипт, изменив путь к рабочему столу пользователя. Я смог сделать это, с помощью сверху и из других источников, используя get-location апплета .
У вас может быть другой, или даже лучший способ сделать это, но у меня это сработало:
$Path = Get-Location
Set-Location $Path\Desktop
Set-Location Desktop
. ( Get-Location
просто возвращает текущее местоположение, что неявно для Set-Location
относительного пути.)
$env:username
- получить имя пользователя из соответствующей переменной среды.