Windows PowerShell: Pense em comandos, não em scripts

  • Artigo

Não ser intimide, o termo “ script ”, como é possível fazer muito com o Windows PowerShell com comandos simples.

Don Jones

Percepção tem sido um dos livrou maiores que do Windows PowerShell teve em termos de aceitação de administrador. Existe uma percepção remanescentes que o shell é “ linguagem de script ”, semelhante a VBScript. Enquanto muitos administradores adorar o que podem fazer com uma linguagem de script, muito mais são desativadas pela percepção da complexidade e a uma curva de aprendizado steep.

É uma pena. O shell oferece suporte a uma abordagem de robusta baseados em script, mas igualmente bem em uma abordagem mais simples e orientado por comando. A beleza real do shell é que você pode usar qualquer abordagem para realizar muitas das mesmas tarefas.

Basta um script

A função a seguir irá aceitar nomes de computador a partir da linha de comando, como seqüências de caracteres ou na propriedade “ NomeDoComputador ” de um objeto de entradaEle também irá recuperar as informações de BIOS e o sistema operacional de cada computador usando o WMI (Instrumentação de gerenciamento do Windows):

function Get-Inventory
{
   [CmdletBinding()]
   Param(
       [Parameter(Mandatory=$true,
                 ValueFromPipeline=$true,
                 ValueFromPipelineByPropertyName=$true)]
       [string] $computername
   )
   Process {
      $os = gwmi win32_operatingsystem -computername $computername
      $bios = gwmi win32_bios -computername $computername
      $obj = new-object psobject
      $obj | add-member noteproperty ComputerName $computername
      $obj | add-member noteproperty OSBuild ($os.buildnumber)
      $obj | add-member noteproperty SPVersion ($os.servicepackmajorversion)
      $obj | add-member noteproperty BIOSSerial ($bios.serialnumber)
      Write-output $obj
   }
}

Observe que os parênteses força o shell a executar expressões — como, por exemplo, obtendo a propriedade BuildNumber do objeto na variável $ SO — e retornar o resultado dessa expressão, como o terceiro valor de parâmetro de adicionar membros.

Eu também pode executar essa função, a tubulação em nomes de computador estático:

'localhost','server2' | Get-Inventory

Ou, enviando o conteúdo de um texto de arquivo que contém um nome de computador por linha:

Get-Content names.txt | Get-Inventory

Ou até mesmo recuperar objetos de computador do Active Directory, alterando a propriedade Name para NomeDoComputador e tubulação aqueles:

Import-Module ActiveDirectory
Get-ADComputer –filter * | Select-Object @{Label='ComputerName';Expression={$_.Name}} | Get-Inventory

A propósito, eu uso as chaves para encapsular o código executável. O alocador de espaço $ _ representa o objeto que enviada por pipe para o cmdlet Select-Object. Os resultados de um dos seguintes são uma tabela perfeitamente formatada de quatro colunas. Posso facilmente redirecionar essa saída para um arquivo, impressora ou uma grade de design, ou até mesmo filtrar e classificar os resultados antes de exibi-los. Por exemplo:

Get-Content names.txt | Get-Inventory | Where { $_.BuildNumber –eq 7600 } | Sort ComputerName

Uma vez, as chaves encapsulam um executável bloco de código — a expressão que deseja filtrar — e o espaço reservado para do $ _ representa o objeto de pipe.

Comando de desempenho

Não há nada de errado com um script como esse, mas ele está funcionando bem difícil. É uma abordagem de estilo do criador de scripts ou do programador que muitos administradores ache complicados. Você poderia fazer a mesma coisa em um único comando de um pouco complexa. Chave de si mesmo:

Get-WmiObject Win32_OperatingSystem -computername (get-content names.txt) | 
Select-object @{Label="ComputerName";Expression={$_.__SERVER}},
             @{Label="OSBuild";Expression={$_.BuildNumber}},
             @{Label="SPVersion";Expression={$_.ServicePackMajorVersion}},
             @{Label="BIOSSerial";Expression={(gwmi win32_bios -comp $_.__server).serialnumber}}

Não há muita coisa acontecendo lá. Aqui está uma análise detalhada:

  1. Primeiro, execute Get-WmiObject para recuperar o objeto Win32_OperatingSystem de nomes de computador especificado. Se você tiver um leitor regular desta coluna, talvez você saiba que a objetos retornados pelo Get-WmiObject sempre incluir uma propriedade __SERVER, que contém o nome do computador for proveniente de objetos WMI.
  2. Os objetos WMI forem canalizados para Select-Object. Usei quatro tabelas de hash para definir quatro propriedades: NomeDoComputador, OSBuild, SPVersion e BIOSSerial. Cada hashtable Especifica um rótulo, que será posteriormente usado como cabeçalho de coluna para a saída — e uma expressão. A hashtable é construído utilizando o @ operador de matriz, seguido pela definição de rótulo/expressão entre chaves. Essas chaves, coloque-o código executável que define a parte da expressão da hashtable.
  3. Para as três primeiras colunas, a expressão fizer referência apenas para uma propriedade existente do objeto;Eu estou basicamente apenas alterar o nome da propriedade.
  4. Para a quarta coluna, a minha expressão, na verdade, está executando uma segunda consulta do WMI em relação ao mesmo servidor. Ele está recebendo o nome de computador a partir da propriedade __SERVER. Ver como a chamada WMI inteira seja colocada entre parênteses? Os forçam a expressão a ser executado pela primeira vez. Qualquer objeto de resultado dessa expressão será inserido no lugar da parte entre parênteses. O período após os parênteses de fechamento me permite acessar as propriedades desse objeto resultante, para que eu estou acessando sua propriedade número de série para a minha coluna quarta.

De certa forma, essa sintaxe é mais difícil do que o script com o qual comecei. Ele está compactado e usa uma grande quantidade de pontuação. Este é o tipo de coisa, você pode usar como modelo e modificá-lo para atender às suas necessidades de outras. Se você não consegue descobrir por que ele não está funcionando, poste uma pergunta no meu blog em ConcentratedTech.com e vou ajudá-lo a descobrir.

Não chamar IT um script

A questão é que o Windows PowerShell não precisa ser usado como uma linguagem de script. O comando que demonstrei pode ser complexo, mas é não mais complexa do que alguns dos comandos far-out já vi os administradores de gravação para o antigo shell CMD. exe. Depois que você se acostuma a sintaxe — que leva sem dúvida alguma prática — o comando é muito menos complicado de escrever uma completa-no script ou uma função.

Portanto, não deixe que o termo “ linguagem de script ” ativa longe do shell. Só é tão “ scripty ” à medida que você escolher.

Don Jones

Don Jones é um fundador da Concentrated Technology e perguntas de respostas sobre o Windows PowerShell e outras tecnologias de ConcentratedTech.com. Ele também é autor de Nexus.Realtimepublishers.com, que faz com que muitos de seus livros disponíveis como livres edições eletrônicas por meio de seu site.

Conteúdo relacionado