前の10件 | -
Windows PowerShell in Action, Second Edition がとうとう出ました [PowerShell]
Manning Early Access Program で買っていたので
小出しに読めてはいましたが、
やっと完成とのメールが来ました。
さっそくダウンロードしました。
かなり内容充実している気がします。
http://www.manning.com/payette2/
小出しに読めてはいましたが、
やっと完成とのメールが来ました。
さっそくダウンロードしました。
かなり内容充実している気がします。
http://www.manning.com/payette2/
WCF を PowerShell から使う [PowerShell]
PowerShell から WCF Service に接続する方法ってどうするのかなと思って調べたので、忘れないようにメモしておきます。
PowerShell 1.0 の場合はいろいろ面倒だったようなのですが、
PowerShell 2.0 なら
New-WebServiceProxy
を使ってとても簡単に接続できるようになっていました。
ありがたい。
PowerShell 1.0 の場合はいろいろ面倒だったようなのですが、
PowerShell 2.0 なら
New-WebServiceProxy
を使ってとても簡単に接続できるようになっていました。
ありがたい。
タグ:WCF
PowerBoots を試してみる [PowerShell]
PowerBoots を試しに使ってみようと思い、
PowerShell From Japan!!の記事「PowerBootsをインストールする」
http://blog.powershell-from.jp/?p=148
を参考にインストールしてみたのですが
Import-Moduleのところで署名関連のエラーが出て、
そのままではうまくいきませんでした。
この記事の対象はVer0.1で今はVer0.2だからでしょうか。
そこで、ダウンロードしたファイルについている署名部分は
全部削除してやるとうまくいきました。
ただし(私の環境での通常設定である)ExecutionPolicyがRemoteSignedのままで面倒なく使うには、
リモートからダウンロードしたファイルだという情報を消さなくてはいけません。
いろいろ方法はあるのでしょうが、
notepad でファイル名に :Zone.Identifier を付けて開くとファイルをどのゾーンからダウンロードしたかの情報を編集できるというのも知りました。
notepad ".\WpfTypes.format.ps1xml:Zone.Identifier" のようにです。
これでゾーンの種類を2以下にすればリモート扱いされないようになります。
もちろんこの書き換えは自己責任で。。。
PowerShell From Japan!!の記事「PowerBootsをインストールする」
http://blog.powershell-from.jp/?p=148
を参考にインストールしてみたのですが
Import-Moduleのところで署名関連のエラーが出て、
そのままではうまくいきませんでした。
この記事の対象はVer0.1で今はVer0.2だからでしょうか。
そこで、ダウンロードしたファイルについている署名部分は
全部削除してやるとうまくいきました。
ただし(私の環境での通常設定である)ExecutionPolicyがRemoteSignedのままで面倒なく使うには、
リモートからダウンロードしたファイルだという情報を消さなくてはいけません。
いろいろ方法はあるのでしょうが、
notepad でファイル名に :Zone.Identifier を付けて開くとファイルをどのゾーンからダウンロードしたかの情報を編集できるというのも知りました。
notepad ".\WpfTypes.format.ps1xml:Zone.Identifier" のようにです。
これでゾーンの種類を2以下にすればリモート扱いされないようになります。
もちろんこの書き換えは自己責任で。。。
ToCharArray で文字列を配列に [PowerShell]
テキスト中の、いわゆる全角英数文字を半角英数文字に変換するフィルタを試しに書いてみました。
入力チェックとか何もない手抜きですが、とりあえず動きます。
入力はパイプラインから与えることを想定しています。
たとえば、どこがとりあえずかというと、
このままだと出力の文字コードがUTF16固定になってしまいます。
そこで、使うときには Out-File の Encoding 指定を使います。たとえば、
でもこれだとなんとなく for のあたりが PowerShell っぽくありません。
いかにもCとかC++プログラマが書いた感じです。
Length で長さを明示的に取るあたりが無駄な気がします。
ToCharArray をつかって入力の文字列を文字の配列にばらして処理してみましょう。
まだ、無駄がある気がします。
foreachをつかわずそのままパイプに流せそうな。。。
ずいぶん、すっきりした気がします。
最初からこういうように書けるようになりたいものです。
ちなみに、実行速度はどれが早いか比較していません。(^_^;
どうなんだろう。。
process {
$ol=""
for ($ix=0; $ix -lt $_.Length; $ix++)
{
$cc=[int]($_[$ix])
if ($cc -ge 0xFEE0) { $cc -= 0xFEE0 }
$ol += [char]$cc
}
$ol
}
入力チェックとか何もない手抜きですが、とりあえず動きます。
入力はパイプラインから与えることを想定しています。
たとえば、どこがとりあえずかというと、
このままだと出力の文字コードがUTF16固定になってしまいます。
そこで、使うときには Out-File の Encoding 指定を使います。たとえば、
Get-Content .\sample.txt | .\Convert-Z2A-.ps1 | Out-File -Encoding OEM
でもこれだとなんとなく for のあたりが PowerShell っぽくありません。
いかにもCとかC++プログラマが書いた感じです。
Length で長さを明示的に取るあたりが無駄な気がします。
ToCharArray をつかって入力の文字列を文字の配列にばらして処理してみましょう。
process {
$o = ""
foreach ($c in $_.ToCharArray()) {
if ($c -ge '!') { $c = [char]($c-0xFEE0) }
$o += $c
}
$o
}
まだ、無駄がある気がします。
foreachをつかわずそのままパイプに流せそうな。。。
process {
$o = ""
$_.ToCharArray() | % { if ($_ -ge '!') { $_ = [char]($_-0xFEE0) }; $o += $_ }
$o
}
ずいぶん、すっきりした気がします。
最初からこういうように書けるようになりたいものです。
ちなみに、実行速度はどれが早いか比較していません。(^_^;
どうなんだろう。。
iPowerShell --- iPhone で PowerShell ヘルプを [PowerShell]
PowerShellのヘルプテキストを見ることができる
iPowerShellというiPhoneアプリがあるのを知りました。
PCの画面上で見ればすむ話ではあるのですが、
手元でサブ画面的に見られるとなんとなく使いやすい気がします。
なかなか便利です。
Cmdlets, Aliases, Providers, About Help を見ることができます。
Select Libs 設定で見たいライブラリを絞り込み、
例えば VMware.VimAutomation.dll のみを選択して見るというようなことも可能です。
http://blog.sapien.com/index.php/2010/01/05/ipowershell-2-0/
iPowerShellというiPhoneアプリがあるのを知りました。
PCの画面上で見ればすむ話ではあるのですが、
手元でサブ画面的に見られるとなんとなく使いやすい気がします。
なかなか便利です。
Cmdlets, Aliases, Providers, About Help を見ることができます。
Select Libs 設定で見たいライブラリを絞り込み、
例えば VMware.VimAutomation.dll のみを選択して見るというようなことも可能です。
http://blog.sapien.com/index.php/2010/01/05/ipowershell-2-0/
タグ:iPhone
Windows 7 RTM の PowerShell のバージョン [PowerShell]
TechNet で入手した Windows 7 RTM 版でPowerShell のバージョンを確認しました。
内容に変化があるのかは未確認です。
普通に自作スクリプトを少し試す限りでは問題ありません。
CLRVersionとBuildVersionは3レベル目以下の変更ですが、
PSRemotingProtocolVersion は 2.0 から 2.1 になっているのは少し気になります。
$PSVersiontable の値は
Windows 7 RC では
Name Value
---- -----
CLRVersion 2.0.50727.4918
BuildVersion 6.1.7100.0
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
SerializationVersion 1.1.0.1
PSRemotingProtocolVersion 2.0
Windows 7 RTM では
Name Value
---- -----
CLRVersion 2.0.50727.4927
BuildVersion 6.1.7600.16385
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
SerializationVersion 1.1.0.1
PSRemotingProtocolVersion 2.1
内容に変化があるのかは未確認です。
普通に自作スクリプトを少し試す限りでは問題ありません。
CLRVersionとBuildVersionは3レベル目以下の変更ですが、
PSRemotingProtocolVersion は 2.0 から 2.1 になっているのは少し気になります。
$PSVersiontable の値は
Windows 7 RC では
Name Value
---- -----
CLRVersion 2.0.50727.4918
BuildVersion 6.1.7100.0
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
SerializationVersion 1.1.0.1
PSRemotingProtocolVersion 2.0
Windows 7 RTM では
Name Value
---- -----
CLRVersion 2.0.50727.4927
BuildVersion 6.1.7600.16385
PSVersion 2.0
WSManStackVersion 2.0
PSCompatibleVersions {1.0, 2.0}
SerializationVersion 1.1.0.1
PSRemotingProtocolVersion 2.1
CTP3 と Windows 7 RC 版の違い [PowerShell]
そういえばNivot Inkに
PowerShell v2.0 – Differences Between CTP3/Win7Beta and Win7RC
と題する記事が出ています。
これは見やすくてありがたい・・・
こうやってみるとCTP3とWindows 7版で結構な違いがありますね。
PowerShell v2.0 – Differences Between CTP3/Win7Beta and Win7RC
と題する記事が出ています。
これは見やすくてありがたい・・・
こうやってみるとCTP3とWindows 7版で結構な違いがありますね。
Ctrl-C を受けとりたい(キー入力でループ脱出の続き ) [PowerShell]
昨年12月26日に書いた話(キー入力でループ脱出)の続きがあるのを忘れていました。
「また Ctrl-c, Ctrl-s などは対象にできません。素直にここまで情報が届くキーのみが使えます。(ReadKeyで AllowCtrlC を指定すれば Ctrl-c は使えるのかな?)」
と書いていたのですが、
としただけではCtrl-cはここまでやってきてくれません。
事前に
と指定しておく必要があります。
二重の関門ですね。。。
.Net Framework の Console クラス について知らないと書けないところになります。
Ctrl-s は無理なのかな。
「また Ctrl-c, Ctrl-s などは対象にできません。素直にここまで情報が届くキーのみが使えます。(ReadKeyで AllowCtrlC を指定すれば Ctrl-c は使えるのかな?)」
と書いていたのですが、
$keyinput = $rawui.Readkey("NoEcho,IncludeKeyUp,IncludeKeyDown,AllowCtrlC")
としただけではCtrl-cはここまでやってきてくれません。
事前に
[Console]::TreatControlCAsInput = $true
と指定しておく必要があります。
二重の関門ですね。。。
.Net Framework の Console クラス について知らないと書けないところになります。
Ctrl-s は無理なのかな。
New-ItemProperty でレジストリキーを作成 [PowerShell]
PowerShell でレジストリ キー を作成するためには
New-ItemProperty コマンドレットが使えます。
レジストリ キーの種類を指定しないと文字列型となります。
DWORD など他の型のキーを作りたいと思ったのですが、
ヘルプもMSDN(http://technet.microsoft.com/en-us/library/dd347732.aspx)も不親切で
-PropertyType パラメターにどういう指定をすればいいのか明記されていません。
しかたがないので適当な文字列を書いて試してみると、
のようにエラーが表示されるのでわかりました。
うーん、親切なんだか、不親切なんだか。(笑)
.NET Framework クラス ライブラリ の RegistryValueKind 列挙体 の記述でいいようですね。
http://msdn.microsoft.com/ja-jp/library/microsoft.win32.registryvaluekind.aspx
たとえば
New-ItemProperty コマンドレットが使えます。
レジストリ キーの種類を指定しないと文字列型となります。
DWORD など他の型のキーを作りたいと思ったのですが、
ヘルプもMSDN(http://technet.microsoft.com/en-us/library/dd347732.aspx)も不親切で
-PropertyType パラメターにどういう指定をすればいいのか明記されていません。
しかたがないので適当な文字列を書いて試してみると、
New-ItemProperty : パラメータ 'Type' をバインドできませんでした。"SZ" を "Microsoft.Win32.RegistryValueKind" に変換できませんでした。考えられる列挙値は、"String、ExpandString、Binary、DWord、MultiString、QWord、および Unknown" です。
のようにエラーが表示されるのでわかりました。
うーん、親切なんだか、不親切なんだか。(笑)
.NET Framework クラス ライブラリ の RegistryValueKind 列挙体 の記述でいいようですね。
http://msdn.microsoft.com/ja-jp/library/microsoft.win32.registryvaluekind.aspx
たとえば
New-ItemProperty <レジストリパス> -name test2 -propertytype Binary -value 123のように。
$PSBoundParameters によるパラメターチェック [PowerShell]
Windows PowerShell Blog の下記リンクの記事を見て
Version 2 から追加された $PSBoundParameters の使い方を知りました。
便利そうなので書き残しておきます。
http://blogs.msdn.com/powershell/archive/2009/04/06/checking-for-bound-parameters.aspx
パラメターがどのように引き渡されたかを関数などの内部で確認できます。
出力はこうなります。
そこにパラメター名のキーがあるかどうかで判別可能です。
従来だと param ($x = $null) のようにたとえば$nullをデフォルト値としておき、
$x が $null かどうかで判別したりしていました。
しかしこの方法だとデフォルト値はパラメターの正当な値の範囲に含められません。
つまり $null が渡されたのか x が渡されなかったのかが見分けられないのです。
$PSBoundParameters をつかった方法だとこのような問題はありません。
そういえば、次のように
でもこれは面白いけどちょっと使いにくいかな、と思います。
Version 2 から追加された $PSBoundParameters の使い方を知りました。
便利そうなので書き残しておきます。
http://blogs.msdn.com/powershell/archive/2009/04/06/checking-for-bound-parameters.aspx
パラメターがどのように引き渡されたかを関数などの内部で確認できます。
function fooのように使えます。
{
param($x, $y)
if (-not $PSBoundParameters.ContainsKey('x'))
{
Write-host 'x not Bound!'
}
Write-Host "x is ($x)"
Write-Host $PSBoundParameters
}
foo -y 2 $null
出力はこうなります。
x is ()$PSBoundParameters はパラメターを含んだハッシュテーブルになっているので、
[y, 2] [x, ]
そこにパラメター名のキーがあるかどうかで判別可能です。
従来だと param ($x = $null) のようにたとえば$nullをデフォルト値としておき、
$x が $null かどうかで判別したりしていました。
しかしこの方法だとデフォルト値はパラメターの正当な値の範囲に含められません。
つまり $null が渡されたのか x が渡されなかったのかが見分けられないのです。
$PSBoundParameters をつかった方法だとこのような問題はありません。
そういえば、次のように
function booデフォルト値として Throw を含む文を書くという方法を見かけたこともあります。
{
param($x = $(Throw "x required"))
Write-Host "x is ($x)"
}
でもこれは面白いけどちょっと使いにくいかな、と思います。
前の10件 | -