Como obtenho o nome de usuário atual no Windows PowerShell?
Como obtenho o nome de usuário atual no Windows PowerShell?
Respostas:
Eu encontrei:
$env:UserName
Há também:
$env:UserDomain
$env:ComputerName
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$env:USERNAME
pode ser alterada pelo usuário, mas isso não será enganado ao fazer isso.
Eu pensei que seria valioso resumir e comparar as respostas dadas.
(opção mais fácil / mais curta / memorável)
[Environment]::UserName
- @ThomasBratt$env:username
- @Eoinwhoami
- @galaktor(opção mais confiável)
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
- @MarkSeemann(em vez do nome do usuário que está executando a instância do PowerShell)
$(Get-WMIObject -class Win32_ComputerSystem | select username).username
- @TwonOfAn neste outro fórumO comentário de @Kevin Panko na resposta de @Mark Seemann trata da escolha de uma das categorias em detrimento da outra:
[A abordagem do token de acesso do Windows] é a resposta mais segura, porque $ env: USERNAME pode ser alterado pelo usuário, mas isso não será enganado.
Em resumo, a opção de variável de ambiente é mais sucinta e a opção de token de acesso do Windows é mais confiável.
Eu tive que usar a abordagem de token de acesso do Windows Seemark no Windows PowerShell em um script do PowerShell que eu estava executando em um aplicativo C # com representação.
O aplicativo C # é executado com minha conta de usuário e executa o script do PowerShell como uma conta de serviço. Devido a uma limitação da maneira como estou executando o script do PowerShell a partir do C #, a instância do PowerShell usa as variáveis de ambiente da minha conta de usuário, mesmo que seja executada como usuário da conta de serviço.
Nesta configuração, as opções da variável de ambiente retornam o nome da minha conta e a opção de token de acesso do Windows retorna o nome da conta de serviço (que era o que eu queria), e a opção de usuário conectado retorna o nome da minha conta.
Além disso, se você quiser comparar as opções, aqui está um script que você pode usar para executar um script como outro usuário. Você precisa usar o cmdlet Get-Credential para obter um objeto de credencial e, em seguida, executar esse script com o script para executar como outro usuário como argumento 1 e o objeto de credencial como argumento 2.
Uso:
$cred = Get-Credential UserTo.RunAs
Run-AsUser.ps1 "whoami; pause" $cred
Run-AsUser.ps1 "[System.Security.Principal.WindowsIdentity]::GetCurrent().Name; pause" $cred
Conteúdo do script 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
é a melhor opção, pois funciona em várias plataformas. whoami
também parece funcionar, mas depende da whoami
ferramenta estar disponível na plataforma.
$env:USERNAME
produz , a SYSTEM
menos que eu corra como administrador, enquanto [Environment]::UserName]
produz meu nome de usuário de qualquer maneira.
Get-WmiObject
método não funciona mais no pwsh. Até tentou importar o módulo de compatibilidade e o Microsoft.PowerShell.Management
que possui o cmdlet. Alguma idéia do que está acontecendo?
Eu gostaria de lançar o comando whoami , que basicamente é um bom alias para fazer %USERDOMAIN%\%USERNAME%
como proposto em outras respostas.
Write-Host "current user:"
Write-Host $(whoami)
$env:USERNAME
pode ser alterado pelo usuário, mas isso não será enganado ao fazer isso.
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
)
whoami
é um executável. Não pode ser removido do PowerShell. Ele poderia ser removido do Windows, mas ele ainda está lá como de não-Nano Windows Server 2012.
[Environment]::UserName
retorna apenas o nome do usuário. Por exemplo, bob
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
retorna o nome do usuário, prefixado por seu domínio, quando apropriado. Por exemplo, ALGUM LUGAR ONDE
Eu usei $env:username
no passado, mas um colega apontou que é uma variável de ambiente e pode ser alterada pelo usuário e, portanto, se você realmente deseja obter o nome de usuário do usuário atual, não deve confiar nela.
Eu recomendo a resposta de Mark Seemann: [System.Security.Principal.WindowsIdentity] :: GetCurrent (). Name
Mas eu não tenho permissão. Com a resposta de Mark, se você precisar apenas do nome de usuário, talvez seja necessário analisá-lo, pois no meu sistema ele retorna hostname\username
e em máquinas ingressadas no domínio com contas de domínio ele retornará domain\username
.
Eu não usaria, whoami.exe
pois ele não está presente em todas as versões do Windows, e é uma chamada para outro binário e pode dar alguns ajustes às equipes de segurança.
[Environment]::UserName
é menos digitado, independente $env:username
e multiplataforma: consulte pastebin.com/GsfR6Hrp
Agora que o PowerShell Core (também conhecido como v6) foi lançado e as pessoas podem querer escrever scripts entre plataformas, muitas das respostas aqui não funcionarão em nada além do Windows.
[Environment]::UserName
parece ser a melhor maneira de obter o nome de usuário atual em todas as plataformas suportadas pelo PowerShell Core, se você não deseja adicionar detecção de plataforma e revestimento especial ao seu código.
$username=( ( Get-WMIObject -class Win32_ComputerSystem | Select-Object -ExpandProperty username ) -split '\\' )[1]
$username
O segundo nome de usuário é apenas para exibição, se você o copiar e colar.
Não vi nenhum exemplo baseado em tipo de adição. Aqui está um usando o GetUserName diretamente do 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
e UNLEN
é 256), desconsidera qualquer erro que possa ser retornado de GetUserName (por meio de preserva GetLastError, um bom ponto), não limpa o buffer da string; e provavelmente alguns outros. E, como outros disseram, também faltam comentários.
Acho mais fácil de usar: cd $ home \ Desktop \
No meu caso, eu precisava recuperar o nome de usuário para permitir que o script alterasse o caminho, ou seja. c: \ users \% nome de usuário%. Eu precisava iniciar o script alterando o caminho para a área de trabalho dos usuários. Consegui fazer isso, com a ajuda de cima e de outros lugares, usando o applet get-location.
Você pode ter outra maneira, ou ainda melhor, de fazer isso, mas isso funcionou para mim:
$ Path = Get-Location
Set-Location $ Path \ Desktop
Se você está acostumado ao lote, pode ligar para
$user=$(cmd.exe /c echo %username%)
Isso basicamente rouba a saída do que você obteria se tivesse um arquivo em lotes com apenas "echo% username%".
$(...)
é supérfluo: $a = cmd.exe /c echo %username%
funciona, b) não é portátil, c) na verdade, não responde à pergunta de como fazê-lo no PowerShell, responde como fazê-lo no DOS, e é melhor dar a um homem uma vara de pescar do que dar a ele um peixe, por exemplo 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}
No meu caso, eu precisava recuperar o nome de usuário para permitir que o script alterasse o caminho, ou seja. c:\users\%username%\
. Eu precisava iniciar o script alterando o caminho para a área de trabalho dos usuários. Consegui fazer isso, com a ajuda de cima e de outros lugares, usando o applet get-location .
Você pode ter outra maneira, ou ainda melhor, de fazer isso, mas isso funcionou para mim:
$Path = Get-Location
Set-Location $Path\Desktop
Set-Location Desktop
. ( Get-Location
Apenas retorna o local atual, o que está implícito para um Set-Location
com um caminho relativo.)
$env:username
recuperar o nome de usuário da variável de ambiente correspondente.