Essa é criação minha... mas provavelmente alguém já deve ter feito: como enviar um pacote UDP na rede usando apenas uma linha no Windows Powershell. Ingredientes utilizados:

• Link: http://msdn.microsoft.com/msdnmag/issues/06/02/udp/default.aspx
• Object Browser do Visual Studio (para ver a referência das classes usadas)
• Ethereal - Network Protocol Analyzer (para ver que o pacote realmente foi)
• Um editor de textos pra ir salvando à medida que as coisas forem funcionando (nesse caso, usei o gVim)
• Windows Powershell (óbvio!)
• Uma pitada de paciência (3 minutos só, não exagere)

Resultado: (new-object System.Net.Sockets.Socket(2,2,17)).SendTo("Vinicius".toCharArray(),(new-object System.Net.IPEndPoint(([System.Net.IPAddress]::Parse("192.168.1.2")),2000))) Dois detalhes: o exemplo acima manda um pacote com 8 bytes (os bytes da String "Vinicius") para o IP 192.168.1.2 na porta 2000. Agora vou dormir. Amanhã posto algo mais decente que usa isso... como por exemplo uma possível função chamada Wake-computer que recebe um MAC Address. Ela vai acordar o computador, desde que ele esteja com fonte de energia, com a opção WakeOnLan na BIOS ativada e na rede local. Boa noite!

Olá, Acabei de ler um artigo interessante na RedmondMag sobre o Windows Server Core. Ao contrário do que muitos estavam achando, o Windows Powershell não estará disponível na versão Core do Windows, que conterá somente uma linha de comando e alguns recursos. A idéia é que ele seja uma opção de instalação como qualquer outra, e que possa servir somente como servidor de arquivos, controlador de domínio, servidor DHCP ou DNS. Ponto. Essas são as funções que ele poderá exercer na rede... mas recursos mesmo ele tem bastante. Duas restrições curiosas que me chamaram a atenção:

• ele não vai rodar o .Net Framework (tá aí o motivo da ausência do Powershell)
• até o Bloco de Notas nele foi adaptado, e não vai existir a opção Save As...

Pra quem quiser ver e ler mais, segue o link: http://redmondmag.com/features/article.asp?EditorialsID=640

Olá, Estou aqui hoje para comentar um feito formidável de um grande amigo meu, Wesley Fernandes. Ele criou e postou no MSN SoapBox (mais lugarzinho legal pra postar vídeos... com vários recursos legais e bem rápido) um vídeo sobre como configurar o IIS no computador para dar suporte aos recursos do SMS. Enfim, não tem nada a ver com scripting, mas sim com gerenciamento. Aliás, tá aí uma coisa que eu preciso (e recomendo) aprender. Aqui vai uma demonstração:
Video: Como configurar o IIS para suportar as funções do SMS 2003 Futuramente, farei um teste com um vídeo sobre Scripting... vamos ver se o pessoal gosta. O Wesley, por sua vez, disse que vai postar mais vídeos, inclusive com áudio. Obrigado e parabéns Wes!

Olá, hoje pela manhã me deparei com um problema bem comum: como listar os subdiretórios de um diretório? A princípio, parece bem simples. Quem está acostumado com o DOS e com o prompt de comando deve conhecer o comando DIR e o parâmetro /A dele, que permite listar somente os arquivos que tenham um atributo específico, que pode ser A (marca de arquivo), H (oculto), S (sistema), R (somente-leitura) e D (diretório). Logo, digitar dir /AD resolve nosso problema. No Windows Powershell, curiosamente, não existe essa opção, por vários motivos. No entanto, ele também permite realizar esta tarefa, com alguns parâmetros a mais. Basta usar o comando Get-ChildItem (também conhecido por dir ou ls) e redirecionar a saída para o cmdlet Where-Object, que filtra a saída dele: Get-ChildItem | where-object {$_.attibutes -band 16} ou ainda dir | where-object {$_.attibutes -band 16} ls | where {$_.attibutes -band 16} ls | ? {$_.attibutes -band 16} Todos fazem a mesma coisa, mas usando atalhos, que encurtam a digitação no console. O operador -band é um operador binário, que pega a propriedade attibutes (um mapa de bits, que especifica quais atributos estão presentes) e faz um E bit a bit com o número 16 (nesse caso, o AND bit a bit com o 16 serve para testar se o quinto bit está presente. Este quinto bit indica a flag de diretório). Ainda existe uma saída mais "antiquada" para o problema. Vamos pensar: se o comando DIR /AD resolve o problema e as ferramentas internas do Powershell são mais complicadas, vamos usar o DIR mesmo. A diferença é que podemos usar ele dentro do Powershell também: cmd /c dir /ad Note que usar o comando DIR dessa forma, por meio de um parâmetro do comando CMD, não retorna objetos do tipo arquivo, mas sim objetos tipo String, que nada mais são do que as linhas que o comando CMD retorna ao Powershell. Em resumo: você perde a orientação à objetos do Powershell. Outro detalhe importante: a primeira solução, usando o get-childitem com o where-object é a mais lenta de todas. Seria muito mais interessante utilizar um parâmetro do comando get-childitem, que melhoraria consideravelmente a performance. O problema é que eu não encontrei esse parâmetro ainda. Se quiser testar você mesmo, use o parâmetro -Recurse, que olha também nas subpastas, e veja o tempo que isso leva. Existe a possibilidade de criar uma função no Powershell que simula a digitação de comandos no CMD, mas esse é assunto para outro post... Até mais, Vinicius

Olá a todos! Primeiramente, feliz 2007. Que seja bom pra todos nós. Estive fora um tempo para as festas de fim de ano, e voltei agora. Dentre as minhas metas para as férias ainda estão fazer um curso para aprimorar meu inglês e estudar Estatística. Logo, começamos o ano bem... e sem descanso. Para começar, encontrei a solução para um problema antigo, daqueles que eu e várias pessoas já passaram e não souberam explicar como. Trata-se da questão entre o Windows Script Host e o UTF-8. Já cheguei a postar sobre ele aqui mesmo. Até 10 minutos atrás, sempre que alguém me perguntava assim: "Vinicius, estou encontrando, em alguns arquivos, um erro estranho, na linha 0, caractere 0. Já cansei de olhar e não encontrei nada..." eu respondia usando a resposta mais simples, que encontrei experimentalmente na faculdade: "esse é um problema do Windows Script Host, que não consegue trabalhar com arquivos UTF-8". Com o que eu acabo de ler, agora sei que isso é meia verdade. O problema é mais embaixo e tem a ver diretamente com a forma como os caracteres são codificados. Vamos primeiro à uma breve (e sem muitos detalhes) explicação sobre o que é essa codificação. Tome, por exemplo, um arquivo de texto simples qualquer. Como os dados são armazenados em disco? Nos primórdios da computação, cada caractere tinha um código numérico associado, que era usado diretamente no disco rígido (uma vez que tudo que um computador faz é manipular números... nada mais que isso). A forma como esses caracteres são transformados para números e vice-versa recebe o nome de codificação (encoding, em Inglês). A famosa tabela ASCII é um exemplo disso. Para quem fala e escreve em inglês, os caracteres da tabela ASCII dão conta de quase todas as possibilidades. Ela tem 128 caracteres, o que representa quase tudo nesse idioma. No entanto, para o Português e vários outros idiomas, ela não é totalmente adequada, e falta espaço para alguns caracteres, como as vogais acentuadas, por exemplo. Para isso foram criados outras codificações, como o UTF-8. A idéia básica é usar de um a quatro bytes para representar os caracteres, o que garante muito mais possibilidades. Mais detalhes podem ser encontrados aqui. Até aqui eu sabia, e boa parte de vocês também. O que há de novo é o fato de como o Windows Script Host e o bloco de notas (curioso, não?) trabalham. Tudo começou quando eu percebi que os arquivos gerados no Bloco de Notas algumas raras vezes continham falhas nos 3 ou 4 primeiros caracteres. Resolvi buscar isso e encontrei em um site a explicação sobre um suposto Bug no Bloco de Notas (na Internet também cheguei a ver isso como um Ovo de Páscoa ou Easter Egg, aquelas mensagens escondidas no meio do código-fonte dos programas pelos próprios programadores). O site explica, dentre outras coisas, que não se trata de uma falha no Bloco de Notas, mas sim um detalhes (daqueles que você lê na seção Remarks da documentação) sobre uma função da Win32 API, que descobre qual a codificação de um arquivo texto. Esse detalhe faz com que o Bloco de Notas se engane ao tentar abrir um arquivo "pensa" que é Unicode e mostra caracteres errados. A propósito: a "falha" no Bloco de Notas funciona assim: 1. Abra o Bloco de Notas. 2. Digite "This app can break", sem aspas. Na verdade, vale qualquer texto de exatas 4 palavras, sendo cada uma delas com 4, 3, 3 e 5 caracteres, respectivamente. Vale "This API can break" ou "AAAA BBB CCC DDDDD"... qualquer coisa nesse padrão. 3. Salve o arquivo e feche o bloco de notas. 4. Abra o arquivo novamente. Você vai ver vários caracteres estranhos (quadradinhos, nesse caso) ao invés do texto digitado. Aí você se pergunta: e o WSH? E os scripts? Isso aqui não era um blog sobre scripting? É simples. Da mesma forma que o Bloco de Notas se engana ao abrir arquivos, acredito que o WSH também se enrole. Isso explica o fato dele abrir arquivos Unicode e ANSI, mas não os UTF-8. Procurei por documentos oficiais na MS e nos Newsgroups e não encontrei nada especificamente sobre esse problema do WSH x UTF-8. Continuo procurando a resposta pra isso... e aparentemente, esta é a que mais se parece com a verdadeira. Até mais e bom 2007! Vinicius