なり、なんとendブロックが実行されていません。-Firstを使っても、同様にendは実行されません。StopUpstreamCommandsExceptionというのはパイプライン処理を打ち切って、そこまでの出力値を正しくパイプライン出力として出してくれますが、やってくれるのはそこまでで、最後のendブロック処理はしてくれません。これは十分注意が必要な点で、自作関数内でbeginブロックで確保したリソースをprocessブロックで利用して、endブロックで解放する...という、いかにも書いてしまいそうなパターンは、実はNGなんですね。-Firstを使うだけでアウトです。リソースの取り回しはどうするのが良いの、って話もありますが、それはまたの機会にしましょう。(1/5追記)あえとすさんの記事が参考になります。この方法ではパイプライン下流でthrowされた場合はトラップできないぽいですね。コマンドレットクラスの場合はIDisposable実装で良さそうです。ここからは私見ですが、StopUpstreamCommandsExceptionが後付けかつ非パブリックなところとか、パイプラインを合法的に脱出するステートメントが今に至るまで用意されていないところとか、パイプラインを何とかして途中で打ち切っても、endは実行されないところとかを見ていると、そもそもPowerShellではパイプライン処理の中断というのは、あまり想定してない操作なのかなぁ、という気がしてきています。上記のような裏技を使って回避するのも一案ではあるとは思いますが、そもそも「パイプライン処理の中断はイレギュラー」と考えて、そういう処理は避けて、必要に応じて別のアプローチを取ることも考えた方がいいのかもしれません。|Tweet既出ですが、まとめておきます。今回登場する関数は、elevate.ps1という名前で一つにまとめて保存しておくと便利です。).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)}スクリプト中でこのTest-Admin関数を実行してTrueが返れば、スクリプト(もしくはコンソール)は管理者権限で実行されている。実行すると、指定のスクリプトが管理者権限で実行される。ISEの場合だと単にスクリプトファイルが開かれた状態になるだけで実行まではしてくれない。管理者権限がない場合、昇格してスクリプトを再実行する管理者権限を要する処理の直前で、以下のようにStart-ScriptAsAdmin関数を実行すると、仮に管理者権限がない場合はスクリプトを再起動し、昇格して再実行する。(管理者権限がある場合は再実行せずそのまま継続する。&{$MyInvocation.ScriptName}が使える再起動するまでに実行した処理は再実行しないようにするには、以下のようにスクリプトファイルにパラメータを定義すれば良い。"昇格不要な処理2"}UACダイアログを出さずに管理者権限でスクリプトを実行する一般的な方法と同様、タスクスケジューラを利用する。PowerShellからタスクスケジューラにスクリプトを登録するには、PowerShell3.0以上に同梱されているPSScheduledJobモジュールが必要。"スクリプトのフルパス"としてタスクスケジューラに登録。この操作には当然ながら管理者権限を要するので、もし登録用スクリプトから登録をするには前述のStart-ScriptAsAdminを併用しても良い。"スクリプトのフルパス"とすれば、UACダイアログを表示させずに管理者権限でスクリプトを実行できる。"スクリプトのフルパス"を実行する。(この操作には管理者権限不要)管理者権限がない場合はスクリプトを実行しない逆に、管理者権限がない時は、一切処理を実施させたくない場合。v4以上の場合は、以下をスクリプトの一行目に定義しておくだけでOK。管理者権限がない場合はエラーになってそのままスクリプトは終了する。-RunAsAdministratorv4未満の場合は、前掲のTest-Admin関数を以下のようにスクリプト先頭で呼び出せば良い。|TweetJScriptは言語単体ではSafeArrayを作ることができません。そこでJScriptでSafeArrayが必要な場合、VBScriptを併用しVBScriptの配列(これはSafeArrayです)をJScriptに取り込む方法や、Scripting.DictionaryのItems()メソッドを使う方法などが使われているようです。これらの方法で多次元のSafeArrayを作るサンプルをあまり見かけませんでした。Dictionaryの方法ではそもそも1次元しか無理ですしね。プログラマとSEのあいだこの記事の二つ目の例ではExcelを使用しRegionオブジェクトが二次元配列を返す点を利用しています。これはなかなか盲点というかアイデアものではありますが、実行速度にやや難があるかな?と思いました。この記事の方法は、もともとExcelで二次元配列が必要な場合があったから考案されたもののようで、その用途においてはExcelを起動するコストは考慮しなくてよいのかもしれません。一つ目の方法ではVBScriptを併用していますが、.wsfファイルを使用してJScriptとVBScriptを混在させる形式をとっています。この方法はWSHでは問題ありませんが、複数のスクリプトエンジンを混在できないホスト環境では問題があります。ASPなどほとんどの環境では大丈夫そうです。私が最近はまっているJScript実行環境であるところのAzureaでは無理ですね。WSHでも.jsファイルにこだわるのであれば。そこで考えたのが、ScriptControlを使用してJScriptのコードの中でVBScriptのコードを実行させる方法です。以下のような感じになります。sc.Run("ConvertArray",jsArray2d);}まあやっていることは本当にJScriptの配列をバラしてVBScriptの二次元配列に詰め直しているだけです。いくつかポイントがあって、まずVBScriptからはJScriptのオブジェクトメンバーにドット演算子でアクセスができます。JScriptの配列はオブジェクトと同一であり、配列はオブジェクトに0,1,2...という名前のプロパティが存在することになります。VBScriptで数字のメンバ名はそのままではドット演算子でアクセスできないので、[]でくくる必要があります(これ、予約語なんかもそうですね。あとVB6でもVB.NETでも同じなので覚えておくといいかも)。次元数2の配列の長さを調べるのにjsArray.[0]でまず内側の配列オブジェクトを取得しているわけです。Next構文が使えます。Nextを使ってインデックスアクセスはできません。いうのもjsArray.[3]とかはあくまでjsArrayオブジェクトの3プロパティの値を参照しているにすぎず、jsArray.[I]という書き方ができないからです(これだと単にIプロパティの値を見てることになる)。Eval関数を併用すれば可能ではありますが、コードの中にコードを含ませさらにその中にまたコードを含ませるのも微妙なのでここでは使ってません。あとは紹介した記事の関数部分だけ置き換えればJScriptのVBArrayオブジェクトを用いたテストもできるかと思います。注意点はExcelオブジェクトは配列添え字が1から始まるのに対し、VBScriptの配列は0から始まる点です。LBound関数を使えばその差違は吸収できるかな、と思います。最初は多次元配列というかn次元配列に拡張した関数を書いてやろうと企んでましたが挫折しました。ネストしたループではなく再帰呼び出しである必要がありますし、ReDimは次元数を動的に指定することができないので実行するVBScript自体を動的生成しなければいけません。興味がある方はチャレンジしてみてください。|Tweetご無沙汰してます。mixiついったーブログその他などを。最近、spamコメントが鬱陶しくて色々対策を考えてるんですが、手っ取り早く効果的なのはBBQを使うことですね。某巨大掲示板群サイトで荒らしに使われた、おもに公開プロキシのリストをDNSを引いて持ってくるというものです。Perlの実装はこのページにあります。PHPの実装も見かけました。意外と.NET,C#な実装を見かけないので、最近覚えたC#でさくっとかいてみました。}}使い方はコードを見てください。これは単に引数のホストをBBQにかけ、結果を標準出力に出すコンソールアプリですが、メソッド化してもaspxに組み込んでもWebサービスにしてもまぁ好きなように使ってくださいませ。BBQは万能選手じゃありません。本来書き込めるべき人が書き込めないことも多々あります。BBQをまず通してOKならOK、NGならCAPTCHA認証をやってもらう、とかがいいと思います。トラックバックspam対策もいろいろ考えたんですが、まだ国産のは少ないので、送信データが英字のみをはじく、でも効果は結構あります。このへんmixiでメモったのでコピペ。トラックバックって2008年10月11日20:04黒歴史になるんだろうかオートディスカバリーはないと微妙だしあるとspamの温床になるし。20:18excerpt,titleなどの文字列で弾くのはよくある対策だけど根治法じゃないいたちごっこだーBBQは使えない。理由は少し考えれば分かりますので略。urlの先をまず見に行って、そこにこちらへのリンクがなければまず速効NG。あとはお好みで、引用がなければNGとか。これって莫大なコストがかかるし送り元を見に行くというのがそもそもなんか根本的にどうなんっておもう。21:08送り元を見に行く方式の問題はまだあって、A→Bにトラックバックを送信された場合、B→Aに「AにBのURLが存在するか」を確認しに行く。合理的だけど、このトラックバックって誰でも送れるんだよねー。Aを書いた人じゃなくても。AともBとも関係ない悪意を持つxがいて、A→Bへのトラックバックを乱射した場合どうなるか。B→AのDoS攻撃みたいなんが成立しちゃう。同ドメインへの確認間隔を制御する必要がでてくる。それはもちろん正しくサービスを利用する人にとっては不便になるわけで。21:28送信元を見に行く方式で、トラックバックを送った人のリモートホストと、urlに指定されたWebサイトのドメインが一致するかまず調べるという方法もあるけど(たぶんはてなではこれをやっている)、これは正しい使い方をしていても一致しないことも当然あるわけで(手動でトラックバック打つときとかね)。この辺が確かに手の打ちどころではあるようには思う。手動で打つ時はオートディスカバリー関係ないしな。私のようにDNSの逆引きができないというか正逆で結果が異なるようなサーバーの場合は泣いてもらうしかないかなー。前者は、トラックバックを送った人のリモートホストと、urlに指定されたWebサイトのドメインが一致するかまず調べ、一致しない場合ははじく。一致した場合は送信元を見に行って、こちらへのリンクがある場合は通す。URLを用意するがあるところまではコピペできるが、それに数文字、画像にかかれた文字をつけたすようにする(認証の代わり)。この辺が落としどころかなー。21:35追加文字列は定期的に変わるようにする。21:37オートディスカバリーのほうはチェック間隔に制限を設ける。22:38SPAM温床はメールと同じようなもんじゃないだろか。Server側とClient側で共通のアドレス作れるけど、直接ファイル読み込んでJavaScript実行してないと正しいURLがない。22:54いえねー、トラックバックってわりと新しい規格なのになんでspam温床になることを考えて規格作らなかったのかと。eメールは昔々作られたものだから仕方ないとして。JavaScriptいいですねー。22:55BBQについてはこちらhttp://bbq.uso800.net/JZ5さん事後承諾でごめんなさいだけどコピペさせていただきました。あと、BBXを使うのも一つの案かな。こっちは広告爆撃ブラックリストなので近いものがあるかと。http://blogs.technet.com/stanabe/archive/2007/11/06/windows-powershell-2-0-ctp-released.aspxMSエバンジェリスト田辺さん(この前のイベントでお会いしましたーv)のブログ記事も参考になります。すごい変わってますねー。スクリプトコマンドレットやリモーティング、デバッグなんかは要望が多かったところです。私も仮想環境に入れて検証しなきゃいけないですがうう、時間が・・・ぼちぼちやっていきますね。@mutaguchiBooks書籍版。