ふたたび Live Mesh Remote Desktop の話 [PowerShell]
また PowerShell 以外の話になってしまうのですが、
昨日書いた Live Mesh Remote Desktop がつながるかどうかの話。
やはりだめだったマシンはだめでした。
Live Mesh Remote Desktop の proxy 経由での利用 (2)
http://kawasaki-shingo-ps.blog.so-net.ne.jp/2009-01-10
では、切り分けできないと書きましたが、
今のところわかる範囲では、おそらく・・・
OSの種類には関係なく(XPだからだめというわけではない)
プロキシー経由で接続しなければいけない環境の問題です。
そのようなマシンだと、そこから他につなぎに行くのはできますが、
つながれるのはだめなようです。
昨日書いた Live Mesh Remote Desktop がつながるかどうかの話。
やはりだめだったマシンはだめでした。
Live Mesh Remote Desktop の proxy 経由での利用 (2)
http://kawasaki-shingo-ps.blog.so-net.ne.jp/2009-01-10
では、切り分けできないと書きましたが、
今のところわかる範囲では、おそらく・・・
OSの種類には関係なく(XPだからだめというわけではない)
プロキシー経由で接続しなければいけない環境の問題です。
そのようなマシンだと、そこから他につなぎに行くのはできますが、
つながれるのはだめなようです。
Live Mesh Remote Desktop でのマウス ポインタ設定 [Windows Live]
ひさびさにPowerShellからはずれてLive Meshの話。
Versionがあがって
Live Mesh for Windows: 0.9.3424.31
になったのでリモートデスクトップ接続を試してみました。
描画速度は結構上がっている気がします。
でも XP から Vista に接続したときにマウスカーソルが見えない状態でした。
動作はしているけどカーソルが見えない。
もしやと考えデスクトップを右ボタンクリックして個人設定を呼び出し、
手探りとかキーボード操作で、マウス ポインタの設定を、
Windows Aero (システム設定)
になっている状態から他のものたとえば
3D ブロンズ (システム設定)
に変更して適用すれば見えるようになりました。
以前試したときにつながらなかったマシンに対する接続は
まだ試していません。
忘れていなければ、明日にでも試してみよう。
Versionがあがって
Live Mesh for Windows: 0.9.3424.31
になったのでリモートデスクトップ接続を試してみました。
描画速度は結構上がっている気がします。
でも XP から Vista に接続したときにマウスカーソルが見えない状態でした。
動作はしているけどカーソルが見えない。
もしやと考えデスクトップを右ボタンクリックして個人設定を呼び出し、
手探りとかキーボード操作で、マウス ポインタの設定を、
Windows Aero (システム設定)
になっている状態から他のものたとえば
3D ブロンズ (システム設定)
に変更して適用すれば見えるようになりました。
以前試したときにつながらなかったマシンに対する接続は
まだ試していません。
忘れていなければ、明日にでも試してみよう。
式モードとコマンドモード [PowerShell]
式モード(expression mode)とコマンドモード(command mode)の違いに注意せず失敗したので、まとめておきます。
まず基本の確認から。
PowerShellでの構文解析には式モードとコマンドモードの二種類があります。おおざっぱに言うと、
式モード: (PowerShell での通常の解釈を行うモード)
数字は数字、文字列には引用符が必要、など
コマンドモード:(コマンドにそのままパラメターとして引き渡すためのモード)
数字は数字、引用符なしでも文字列は文字列。
ただし $ と @ と ' と " ( で始める場合は別。
行頭からいきなり書き始めると式モードで解析されるので、
数字の場合には、
代入の右辺でもやはり式モードであり、おなじく、
これがコマンドレットのパラメターとして扱われる場所ではコマンドモードとなります。
さてここで私が起こしたミスの話です。
New-Object コマンドレットで .NET Framework のオブジェクトを作成するときに、そのコンストラクターに引数を渡す場面です。
望ましい書き方は次のようになります。
二つのパラメターは () で囲まれているので式モードで解釈され、要素数2の配列が渡されることになります。
そのようすはたとえば次のように確認できます。
さらに次のように $false の $ を書き洩らしていました。
まず $ を書き洩らしていない場合を考えます。
先ほどと同じように確認すると次のようになります。
今度は$を抜かしてしまった場合の動作です。
今度は最初の要素は論理値ではなく文字列になっています。
これがSystem.Threading.Mutexのコンストラクターに渡された時に、型の違いでエラーが出たりするわけではなく、最初のパラメターが論理値の真と解釈されて動作してしまいます。
書いたつもりと反対になってしまうわけですね。
このような場所では () で囲ってPowerShellの式モードでの構文チェックを通して、エラーを見つけて貰った方が安心であるという教訓を得たのでした。
囲っておけば次のようにエラーになります。
どこがコマンドモードとして扱われるのか、にも注意が必要ですね。
それをわかりやすくまとめたところはどこかに無いかなあ。。。
まず基本の確認から。
PowerShellでの構文解析には式モードとコマンドモードの二種類があります。おおざっぱに言うと、
式モード: (PowerShell での通常の解釈を行うモード)
数字は数字、文字列には引用符が必要、など
コマンドモード:(コマンドにそのままパラメターとして引き渡すためのモード)
数字は数字、引用符なしでも文字列は文字列。
ただし $ と @ と ' と " ( で始める場合は別。
行頭からいきなり書き始めると式モードで解析されるので、
PS> abcのように引用符のない文字列は単なる文字列ではなく、何か呼び出し可能なものの名前として探されます。
用語 'abc' は、コマンドレット、関数、操作可能なプログラム、またはスクリプト ファイルとして認識されません。用語を確認し
、再試行してください。
発生場所 行:1 文字:3
+ abc <<<<
PS> 'abc'引用符をつければ文字列と扱われます。
abc
数字の場合には、
PS> 11+22のように式モードで数値として評価されます。
33
代入の右辺でもやはり式モードであり、おなじく、
PS> $str = abcのようになります。
用語 'abc' は、コマンドレット、関数、操作可能なプログラム、またはスクリプト ファイルとして認識されません。用語を確認し
、再試行してください。
発生場所 行:1 文字:10
+ $str = abc <<<<
PS> $str = 'abc'
PS> $str
abc
これがコマンドレットのパラメターとして扱われる場所ではコマンドモードとなります。
PS> $y = Write-Output abc ; $y引用符をつけなくても文字列と解釈され、数字も数値として計算されません。
abc
PS> $y = Write-Output 11+22 ; $y
11+22
さてここで私が起こしたミスの話です。
New-Object コマンドレットで .NET Framework のオブジェクトを作成するときに、そのコンストラクターに引数を渡す場面です。
望ましい書き方は次のようになります。
$m = New-Object System.Threading.Mutex ($false, "MyMutex")ミューテックスのコンストラクターに論理値の偽と名前の文字列を渡しています。
二つのパラメターは () で囲まれているので式モードで解釈され、要素数2の配列が渡されることになります。
そのようすはたとえば次のように確認できます。
PS> $x = Write-Output ($false, "MyMutex")ところが、私はこれを最初 () なしで書いていました。
PS> $x
False
MyMutex
PS> $x.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Object[] System.Array
PS> $x[0].gettype()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Boolean System.ValueType
PS> $x[1].gettype()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object
さらに次のように $false の $ を書き洩らしていました。
$m = New-Object System.Threading.Mutex false, "MyMutex"するとどうなるでしょう。
まず $ を書き洩らしていない場合を考えます。
$m = New-Object System.Threading.Mutex $false, "MyMutex"実はこの場合には問題なく動作するのです。
先ほどと同じように確認すると次のようになります。
PS> $x = Write-Output $false, "MyMutex"おなじように論理値と文字列の配列が渡されているのがわかります。
PS> $x
False
MyMutex
PS> $x.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Object[] System.Array
PS> $x[0].gettype()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Boolean System.ValueType
PS> $x[1].gettype()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object
今度は$を抜かしてしまった場合の動作です。
PS> $x = Write-Output false, "MyMutex"
PS> $x
false
MyMutex
PS> $x.GetType()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True Object[] System.Array
PS> $x[0].gettype()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object
PS> $x[1].gettype()
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object
今度は最初の要素は論理値ではなく文字列になっています。
これがSystem.Threading.Mutexのコンストラクターに渡された時に、型の違いでエラーが出たりするわけではなく、最初のパラメターが論理値の真と解釈されて動作してしまいます。
書いたつもりと反対になってしまうわけですね。
このような場所では () で囲ってPowerShellの式モードでの構文チェックを通して、エラーを見つけて貰った方が安心であるという教訓を得たのでした。
囲っておけば次のようにエラーになります。
PS> $x = Write-Output (false, "MyMutex")
用語 'false' は、コマンドレット、関数、操作可能なプログラム、またはスクリプト ファイルとして認
識されません。用語を確認
し、再試行してください。
発生場所 行:1 文字:25
+ $x = Write-Output (false, <<<< "MyMutex")
PS>
どこがコマンドモードとして扱われるのか、にも注意が必要ですね。
それをわかりやすくまとめたところはどこかに無いかなあ。。。
タグ:powershell
Windows Server 2008 SP2 での PowerShell のバージョン [PowerShell]
Windows Server 2008 SP2 の RC 版に入っている
PowerShell のバージョンを確認してみました。
インストールして機能を有効にしただけの状態です。
R2 ではなく Service Pack なので機能追加を伴うような更新はないと
思っていましたが、バージョン番号から見て細かな修正・変更などもないようです。
PowerShell のバージョンを確認してみました。
インストールして機能を有効にしただけの状態です。
Get-ItemProperty HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngineで調べたら、今までの1.0と変わっていないようです。
PowerShellVersion : 1.0
RuntimeVersion : v2.0.50727
R2 ではなく Service Pack なので機能追加を伴うような更新はないと
思っていましたが、バージョン番号から見て細かな修正・変更などもないようです。
PowerShell のバージョン判別方法 [PowerShell]
忘れそうなので PowerShell のバージョン判別方法を整理しておくことにします。
(以下 Version 2 と書いてますが現時点では CTP 3 での確認のみ)
Version 2 からは PSVersionTable という変数が追加されており、
Version 1 にはこの変数は存在していなかったので、
Get-Variable で変数の存在を見分ければ Version 1 か
それより新しいのかを判別できます。
他に、次のようにレジストリを見て PowerShellVersion の値を調べる方法もあります。
どちらの方法がいいのでしょうね?
不存在を調べるのも、レジストリパスを書くのもどちらもあまり美しくないような気はします。
なお、Get-Host で PowerShell ホストのバージョンを取得可能で、
これも参考にはなるのですが、Hostの種類・バージョンと PowerShell の
バージョンは異なるので単純に判別できるわけではありません。
たとえば、標準コンソールの場合であれば
あるいは
になるのですが、PowerGUI の中だと
(以下 Version 2 と書いてますが現時点では CTP 3 での確認のみ)
Version 2 からは PSVersionTable という変数が追加されており、
PS > $PSVersionTableのように確認可能です。
Name Value
---- -----
CLRVersion 2.0.50727.3053
BuildVersion 6.1.6949.0
PSVersion 2.0
PSCompatibleVersions {1.0, 2.0}
Version 1 にはこの変数は存在していなかったので、
Get-Variable で変数の存在を見分ければ Version 1 か
それより新しいのかを判別できます。
if (Get-Variable PSVersionTable -ErrorAction SilentlyContinue)
{
# ある時:Version 2 ~
}
else
{
# ない時:Version 1
}
他に、次のようにレジストリを見て PowerShellVersion の値を調べる方法もあります。
(Get-ItemProperty HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine).PowerShellVersion文字列として 1.0 もしくは 2.0 が戻ってきます。数値ではないので比較には注意しましょう。
どちらの方法がいいのでしょうね?
不存在を調べるのも、レジストリパスを書くのもどちらもあまり美しくないような気はします。
なお、Get-Host で PowerShell ホストのバージョンを取得可能で、
これも参考にはなるのですが、Hostの種類・バージョンと PowerShell の
バージョンは異なるので単純に判別できるわけではありません。
たとえば、標準コンソールの場合であれば
Name : ConsoleHost
Version : 1.0.0.0
あるいは
Name : ConsoleHost
Version : 2.0
になるのですが、PowerGUI の中だと
Name : PowerGUIScriptEditorHostだったりします。
Version : 1.5.2.550