Jak uzyskać bieżącą nazwę użytkownika w programie Windows PowerShell?
Jak uzyskać bieżącą nazwę użytkownika w programie Windows PowerShell?
Odpowiedzi:
Znalazłem to:
$env:UserName
Jest również:
$env:UserDomain
$env:ComputerName
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$env:USERNAME
może zostać zmieniona przez użytkownika, ale nie da się tego oszukać.
Pomyślałem, że warto podsumować i porównać podane odpowiedzi.
(łatwiejsza / krótsza / zapadająca w pamięć opcja)
[Environment]::UserName
- @ThomasBratt$env:username
- @Eoinwhoami
- @galaktor(bardziej niezawodna opcja)
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
- @MarkSeemann(zamiast nazwy użytkownika uruchamiającego instancję PowerShell)
$(Get-WMIObject -class Win32_ComputerSystem | select username).username
- @TwonOfAn na tym innym forumKomentarz @Kevin Panko do odpowiedzi @Mark Seemann dotyczy wyboru jednej z kategorii zamiast drugiej:
[Podejście do tokena dostępu do systemu Windows] jest najbezpieczniejszą odpowiedzią, ponieważ $ env: USERNAME może zostać zmieniony przez użytkownika, ale nie da się tego oszukać.
Krótko mówiąc, opcja zmiennej środowiskowej jest bardziej zwięzła, a opcja tokena dostępu do systemu Windows jest bardziej niezawodna.
Musiałem używać podejścia @Mark Seemann do tokena dostępu do systemu Windows w skrypcie PowerShell, który uruchamiałem z aplikacji C # z personifikacją.
Aplikacja C # jest uruchamiana z moim kontem użytkownika i uruchamia skrypt PowerShell jako konto usługi. Z powodu ograniczenia sposobu uruchamiania skryptu PowerShell z C #, instancja PowerShell używa zmiennych środowiskowych mojego konta użytkownika, nawet jeśli jest uruchamiana jako użytkownik konta usługi.
W tym ustawieniu opcje zmiennej środowiskowej zwracają nazwę mojego konta, a opcja tokena dostępu do systemu Windows zwraca nazwę konta usługi (czego chciałem), a zalogowana opcja użytkownika zwraca nazwę mojego konta.
Ponadto, jeśli chcesz porównać opcje samodzielnie, oto skrypt, którego możesz użyć do uruchomienia skryptu jako inny użytkownik. Aby uzyskać obiekt referencji, należy użyć polecenia cmdlet Get-Credential, a następnie uruchomić ten skrypt ze skryptem, aby uruchomić jako inny użytkownik jako argument 1, a obiekt referencji jako argument 2.
Stosowanie:
$cred = Get-Credential UserTo.RunAs
Run-AsUser.ps1 "whoami; pause" $cred
Run-AsUser.ps1 "[System.Security.Principal.WindowsIdentity]::GetCurrent().Name; pause" $cred
Zawartość skryptu 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
jest najlepszą opcją, ponieważ działa na wielu platformach. whoami
wydaje się również działać, ale zależy od whoami
narzędzia dostępnego na platformie.
$env:USERNAME
produkuje, SYSTEM
chyba że uruchomię się jako administrator, a jednocześnie podaje [Environment]::UserName]
moją nazwę użytkownika.
Get-WmiObject
metoda nie działa już w pwsh. Próbowałem nawet zaimportować moduł zgodności i ten, Microsoft.PowerShell.Management
który ma polecenie cmdlet. Masz pomysł, co się dzieje?
Chciałbym wrzucić komendę whoami , która w zasadzie jest fajnym pseudonimem do działania, %USERDOMAIN%\%USERNAME%
jak zaproponowano w innych odpowiedziach.
Write-Host "current user:"
Write-Host $(whoami)
$env:USERNAME
może zostać zmieniony przez użytkownika, ale nie da się tego oszukać.
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
)
whoami
jest plikiem wykonywalnym. Nie można go usunąć z PowerShell. Można go potencjalnie usunąć z systemu Windows, ale nadal jest dostępny od wersji innej niż Nano Windows Server 2012.
[Environment]::UserName
zwraca tylko nazwę użytkownika. Np. Bob
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
zwraca nazwę użytkownika, w razie potrzeby poprzedzoną jej domeną. Np. SOMEWHERENICE \ bob
Używałem $env:username
w przeszłości, ale kolega z pracy zauważył, że jest to zmienna środowiskowa i może być zmieniona przez użytkownika, dlatego jeśli naprawdę chcesz uzyskać nazwę użytkownika bieżącego użytkownika, nie powinieneś jej ufać.
Głosowałbym za odpowiedzią Marka Seemanna: [System.Security.Principal.WindowsIdentity] :: GetCurrent (). Nazwa
Ale nie wolno mi. Z odpowiedzią Marka, jeśli potrzebujesz tylko nazwy użytkownika, być może będziesz musiał ją przeanalizować, ponieważ w moim systemie ona zwraca, hostname\username
a na komputerach przyłączonych do domeny z kontami domeny to zwróci domain\username
.
Nie użyłbym tego, whoami.exe
ponieważ nie jest obecny we wszystkich wersjach systemu Windows, a jest to wezwanie do innego pliku binarnego i może dać atak zespołom bezpieczeństwa.
[Environment]::UserName
jest mniej $env:username
Teraz ten rdzeń PowerShell wydaniu (aka v6), a ludzie mogą chcieć pisać skrypty wieloplatformowe, wiele odpowiedzi tutaj nie będzie działać na niczym innym niż Windows.
[Environment]::UserName
wydaje się być najlepszym sposobem na uzyskanie bieżącej nazwy użytkownika na wszystkich platformach obsługiwanych przez PowerShell Core, jeśli nie chcesz dodawać wykrywania kodu i specjalnej obudowy do swojego kodu.
$username=( ( Get-WMIObject -class Win32_ComputerSystem | Select-Object -ExpandProperty username ) -split '\\' )[1]
$username
Druga nazwa jest tylko do wyświetlania celów wyłącznie jeśli skopiować i wkleić.
Nie widziałem żadnych przykładów opartych na Add-Type . Oto jeden za pomocą GetUserName bezpośrednio z 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
, a UNLEN
jest 256), to pomija żadnego błędu, który mógłby zostać zwrócony z GetUserName (poprzez zachowuje GetLastError, co jest dobrym punktem), nie czyści bufora ciągów; i prawdopodobnie kilka innych. I jak powiedzieli inni, bardzo brakuje też komentarzy.
Uważam, że najłatwiejszy w użyciu: cd $ home \ Desktop \
W moim przypadku musiałem pobrać nazwę użytkownika, aby umożliwić skryptowi zmianę ścieżki, tj. c: \ users \% nazwa użytkownika%. Musiałem uruchomić skrypt, zmieniając ścieżkę do pulpitu użytkownika. Byłem w stanie to zrobić, korzystając z pomocy z góry i gdzie indziej, używając apletu get-location.
Możesz mieć inny, a nawet lepszy sposób, aby to zrobić, ale to zadziałało dla mnie:
$ Path = Get-Location
Ustaw lokalizację $ Path \ Desktop
Jeśli jesteś przyzwyczajony do partii, możesz zadzwonić
$user=$(cmd.exe /c echo %username%)
To w zasadzie kradnie dane wyjściowe z tego, co byś otrzymał, gdybyś miał plik wsadowy z po prostu „echo% nazwa użytkownika%”.
$(...)
zbyteczny: $a = cmd.exe /c echo %username%
działa, b) nie jest przenośny, c) tak naprawdę nie odpowiada na pytanie, jak to zrobić w PowerShell, odpowiada, jak to zrobić w dos, i to jest lepiej dać mężczyźnie wędkę niż dać mu rybę, np 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}
W moim przypadku musiałem pobrać nazwę użytkownika, aby umożliwić skryptowi zmianę ścieżki, tj. c:\users\%username%\
. Musiałem uruchomić skrypt, zmieniając ścieżkę do pulpitu użytkownika. Byłem w stanie to zrobić, korzystając z pomocy z góry i gdzie indziej, używając get-location apletu .
Możesz mieć inny, a nawet lepszy sposób, aby to zrobić, ale to zadziałało dla mnie:
$Path = Get-Location
Set-Location $Path\Desktop
Set-Location Desktop
. ( Get-Location
jedynie zwraca bieżącą lokalizację, która jest domyślna dla Set-Location
ścieżki względnej.)
$env:username
pobranie nazwy użytkownika z odpowiedniej zmiennej środowiskowej.