Як отримати поточне ім'я користувача в 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, але він все ще є, як і для не-нано Windows Server 2012.
[Environment]::UserName
повертає лише ім'я користувача. Напр. Bob
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
повертає ім’я користувача з префіксом домену, де це доречно. Наприклад, ДЕЯКІСТЬ \ bob
Раніше я використовував $env:username
, але колега зазначив, що це змінна середовище, і її можна змінити користувачем, тому, якщо ви дійсно хочете отримати ім'я користувача поточного користувача, вам не слід довіряти цьому.
Я б схвалив відповідь Марка Семана: [System.Security.Principal.WindowsIdentity] :: GetCurrent ().
Але мені це не дозволено. Відповідь Марка, якщо вам потрібно лише ім'я користувача, вам, можливо, доведеться проаналізувати його, оскільки в моїй системі воно повертається, hostname\username
а на приєднаних до домену машинах з обліковими записами домену воно повернеться domain\username
.
Я б не користувався, whoami.exe
оскільки він присутній не у всіх версіях Windows, а це виклик в інший бінарний файл і може привести до відповідності деяким командам безпеки.
[Environment]::UserName
менш типування, незалежно від $env:username
і крос-платформний: Див pastebin.com/GsfR6Hrp
Тепер, коли PowerShell Core (він же 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: \ користувачів \% ім'я користувача%. Мені потрібно було запустити сценарій, змінивши шлях до робочого столу користувачів. Я зміг це зробити за допомогою зверху та в іншому місці за допомогою аплета get-location.
У вас може бути інший або навіть кращий спосіб зробити це, але це працювало для мене:
$ Path = Отримати місцезнаходження
Встановити місце розташування $ Шлях \ Настільний
Якщо ви звикли до партії, ви можете зателефонувати
$user=$(cmd.exe /c echo %username%)
Це в основному викрадає вихід з того, що ви отримали, якби у вас був пакетний файл із просто "echo% username%".
$(...)
це зайве: $a = cmd.exe /c echo %username%
працює, б) воно не є портативним, в) воно насправді не відповідає на питання, як це зробити в powerhell, він відповідає, як це зробити в 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
отримання імені користувача з відповідної змінної середовища.