マイクロソフト、「Windows PowerShell」v1.0を公開 86
ストーリー by mhatta
Unixユーザを狙い撃ち 部門より
Unixユーザを狙い撃ち 部門より
Cappuccino 曰く、
窓の杜の記事によると、マイクロソフトは“Monad”のコードネームで呼ばれていたシステム管理者向け次世代Windowsシェル、「Windows PowerShell」v1.0を公開した。
.NET Framework 2.0が必要で、Windows XP/2003/XP x64/Server 2003 x64/Server 2003 IA64で動作する。@ITの7月の特集記事でRC1をもとにした試用記事も出ているので参考にしてください。
今までWindowsのシェルであったコマンド・プロンプト(cmd.exe)がUNIXなどと比べ貧弱だと感じていた方は是非一度試してみてはいかがでしょう?
UNIX での代替品 (スコア:5, 興味深い)
UNIX だと、同様のことはテキストベースでコマンド+sh スクリプトということになりますが、もういい加減標準 sh 用シェルスクリプトを書きたいとは思えないとか、テキストのパーズで思いもよらぬバグに直面したりとか、とても21世紀の環境とは思えない。
一方で、例えば常に irb (Ruby の対話シェルみたいなの) の中で生きていく、というような手法もあるかもしれません。irb のコマンドプロンプトを普通のシェルのようにして、一通りのコマンドを用意すれば、多分生活に充分なシェル環境が作れるし、スクリプトを書く上では sh よりはるかに優れた言語を使うことができます。問題は他のアプリケーションとの連携ですが、bonobo との通信をサポートするといった、かなり面倒そうな解決方法しか思いつきません…。
Re:UNIX での代替品 (スコア:5, 参考になる)
オライリーのPython本の中で、そのような使い方が提示されてた記憶があります。
Pythonは、引数なしで起動すると、対話シェルなので。
Monad改めWPSが、従来のUNIXシェル+パイプと大きく違うのは、MSのドキュメントにある
> Windows PowerShell では、パイプラインのコマンド間でデータを受け渡すのに、テキストではなくオブジェクトが使用されています。
ってところだと思います。
UNIXシェルだと、パイプはバイトストリームなので、上流のプロセスが、出力をバイトストリームに
マーシャリングし、下流のプロセスがそれをアンマーシャリングする必要がある。その際、
取捨選択するのは下流プロセスなので、マーシャリングされたすべてのバイトがパイプを流れる。
対して、WPSだと、パイプを流れるのはオブジェクトなので、下流のコマンドレットがプロパティを
要求し、要求されたものだけが、パイプを通して下流コマンドレットに渡される。その際、
バイトストリームにマーシャリング、アンマーシャリングする必要も無い。
パイプの段数が深くなるほど、後者の方がパフォーマンス的に優位だと思います。
後は、コマンドラインで、emacsキーバインドさえ使えれば…
KISS という言葉がありますが (スコア:2, 興味深い)
>
> パイプの段数が深くなるほど、後者の方がパフォーマンス的に優位だと思います。
そのかわり、バイトストリームなら簡単に実現できた可用性
(ファイルに保存して別ホストに転送とか)や互換性(.NET 以外のフレームワーク、
たとえば ruby とか java とか)がなくなるんじゃない?
それに、 OS と違って、VM ってまだまだ安定しているとは言いがたい。
一つの VM にあんまり依存しちゃうのは、信頼性の面から見てちょっと心配なところがある。
大抵の場合は、単純なシステムを高並列化して性能を上げる方が
簡単だし障害が少ない。
ほんとに、そんなパフォーマンスが重要な局面ってあるのかなぁ?
かえって保守不能な複雑化を抱えこんじゃう気がしないでもない。
#でも保守不可能な難解プログラム書くの好きな人多いんだよなー
# mishimaは本田透先生を熱烈に応援しています
それはKISSではない (スコア:1, 興味深い)
挟まる必要がなく「素通し」することが出来るアーキテクチャより、
フクザツなんじゃないでしょうか?
むしろUNIXが、プロセスという考えかたに拘泥した副作用ですよね、伝統シェルのマーシャリング必須性(という複雑さ)は。
その縛りをなくしてあげよう、というわけなんじゃないでしょうか?>PowerShell
既存のシェルのやりかたを「単純で愚直」だと思うのは、単なる刷り込みじゃないでしょうか?
>単純なシステムを高並列化して性能を上げる方が簡単だし障害が少ない。
というわけで、UNIX shのほうがやってることは複雑なので、
仮に他の条件が全部同じなら、PowerShell方式のほうが勝つんじゃないでしょうか?
これは予想というよりは経験的事実ですね。
当たり前といえば当たり前なのですが、おおむね同じ処理を
Rubyなどの高機能Script言語で書くと
結構高速に処理できるんだけど、
sh(とコマンドPipeline)で書くと
やっぱりいちいち文字列にしてIOを通すせいか、
凄く処理に時間がかかる、
っていうものは多いです。
grepもsed(gsub)もbasename/dirnameも
何から何まで子プロセスに振ってたら、
そりゃやっぱり重いわけですよ。
>そんなパフォーマンスが重要な局面ってあるのかなぁ?
うん。それは確かに少ないです。
ただし、そのトレードオフを悩むべきなのは、「パフォーマンスのために扱いやすさが犠牲になる」場合ですよね。
軽い奴が扱いも別に全然難しくないなら、諸手を挙げてソッチを使えばいいんです。
PowerShellの考え方、なにか難しいですか?
私もshにはすっかり馴染んでる人間ですが、それでも、
sort の引数で
「ええとソートさせたい部分は何カラム目だっけな」
と文字数を数えたり、
ls -lの出力から
「ファイル名とサイズだけを抽出するのは、ええとどういうgrepやsedをすればいいんだっけ?」
と正規表現を思い出す(正規表現も私は馴染んでいますが、それでもね)
っていう手間を考えると、
ソート要素やファイルサイズをカラム名で一撃で選択できるPowerShellのほうが遥かに理解容易だと思えます。
いやほんと、生Objectをやり取りするというドラスティックな変化は我慢するとしても、
やり取りするデータにカラム名がついてるっていう点だけでいいから、
今すぐに見習いたい!と思いました。
だって、データにカラム名もついてないということは、
我々のshのコードの中身はマジックナンバーだらけだった、
ということなのですから…。
>バイトストリームなら簡単に実現できた可用性(ファイルに保存して別ホストに転送とか)
きっとVistaではObjectがファイルにも
そのまま保存できるようになるのですよ!(違
別ホストですか。気にしてないんじゃないですか?
MSはPowerShell(.NET)で地続きにならないOSなんか
OSに非ずと思っているでしょうし、
そういう必要な場合だけマーシャリングする
(しかも何時必要なのかの判断は隠蔽されて自動化される)
というようなCmdletを作れば済むことでしょうし。
>ruby とか java
前述のように外部コマンドのラッパーは
マーシャリングで解決してもいいですし、
あるいは逆にRubyやJava側に拡張を突っ込んで
PowerShellのオブジェクトを直接食べれるようにしてあげる
っていう手もありそうですよね。
DotNetSystem.out.print(object1);
なんて書けるようにクラスDotNetSystemを書けばいいんです。
便宜というか慣れにあわせてprintと書きましたが、
実際にtoStringする必要があるかどうかは
このoutオブジェクトが知っている、ってわけです。
ああ。あれですよ。
標準入出力2.0
とでも呼べばいいんじゃないでしょうか?
出力するときに何でもかんでもtoStringするという
画一方式から脱却するのですから、
なんか本当に2.0っぽくありませんかね?
開発者と管理者、設計者の視点の違い (スコア:1)
プログラムが暴走したとき最小限の被害で止める方法が
確立されてなかったり、バージョンごとで違ったり、
VM ごとで違ったり、被害がでかかったり。そういうのを管理するのはつらい。
C 言語やシェルスクリプトは、そこで悩む必要がない。
> >そんなパフォーマンスが重要な局面ってあるのかなぁ?
> うん。それは確かに少ないです。
> ただし、そのトレードオフを悩むべきなのは、「パフォーマンスのために扱いやすさが犠牲になる」場合ですよね。
いやいや、システム管理のことも、さらに上流のことも考えてほしい。
システム管理ではまだ枯れてない .NET を扱うのに手間がかかる。
システム設計では、複数のアーキテクチャを同時に扱う状況がよくある。
この状況は 10 年経ってもあまり変わらないんじゃないだろうか。
そういう状況の中での、VM への集中を促す、この Windows Power Shell の試み。
こりゃ、Windows 全体を、OS ではなく VM と考えて、
TCP/IP というストリーム経由で入出力を行え、ということなんじゃないだろうか。
Windows そのものが、一個のプログラムという考え方。
Xen とかの仮想環境で、プロセスを起動するように Windows を立ち上げる。
そこまで含めての「標準入出力2.0」なのかも知れない。
問題は OS のライセンスかな…
# mishimaは本田透先生を熱烈に応援しています
Re:UNIX での代替品 (スコア:1)
確かに面白そうな技術ですが、.NETの手のひらの上でしか動かないであろうことが残念ですね。Windowsはオブジェクト指向環境というわけでないので仕方ないのですが。ただ、位置づけとしてはWSHの後継ということでしょうから、対話シェルというより、システムの運用に関連したちょっとしたスクリプトの実行用ということでしょうね。それならば差し当たり問題ないと思います。ただ既に指摘されているように標準で載ってこないのは残念。
要求したプロパティだけが渡されるとのことですが、@ITの記事を見る限りではオブジェクト全体が渡されていそうにも見えます。ただ、実際にはオブジェクトへの参照が渡されているだけかもしれないので、効率がどうなっているかはわかりませんが。もしプロセス境界をまたいでいるなら、なんらかの(若干別の意味の)マーシャリングは行われそうですな。
Re:UNIX での代替品 (スコア:2, 参考になる)
Ruby関係の方々もマーシャリングって言うんじゃなかろうか(Marshal [ruby-lang.org])。
Re:UNIX での代替品 (スコア:2, 参考になる)
なく、非常に古くからある用語です。Java の誕生より前から。
個人的には、むしろなぜ Java が既存の術語を使わなかったのかの方を、
かねがね疑問に思ってます。
Re:UNIX での代替品 (スコア:1, 興味深い)
要求し、要求されたものだけが、パイプを通して下流コマンドレットに渡される。
他の人も指摘していますが、そう読める箇所が見当たりません。
しかし一方で、それを否定する箇所も見つからないですね。
ソレを実現するためには、「オブジェクトなので」は十分条件ではありません。
「オブジェクトなので」出来ることは、オブジェクトのプロパティだけ触るから、「全てのオブジェクトを渡されても全てのデータを触る必要は無い」という点だけです。オブジェクトそのものが下流に渡されないことまでは(工夫しないと)実現できませんね。
(RubyにもLazyEnumerableクラスが欲しいなあ。)
Monadという旧称が暗示しているように、PowerShellって一種の関数型言語なんですよね。Haskellみたいに。
(OSのリソースまで「操作」できる以上、純粋関数型ではないわけだが)
(あ。関数型言語に似てるのは伝統的シェルもです。Pipelineはもともと関数型言語と同根です。)
で、Haskellがやっているように、システムがデフォで「遅延評価」をやれば、
ほんとに仰せの通りのことが出来るようになる。
それをやっているのかいないのか、は取り合えず@ITの記事からは読み取れませんね。
でも、やってくてたらいいですね。なんせ処理が軽くなる(ことがある)。
特にOSのリソースのような「重い」データを扱うのが主眼となるであろうPowerShellにとっては、
遅延評価で事実上最小限のリソースしか触らなくて済む(しかもその制御をシステムにお任せできる)のは、
かなりのパフォーマンス貢献が有ると思います。
「そこまでやってるんだぜ」という奥ゆかしい消極的な主張をも視野に入れて、旧称をMonadとしたのだとしたら、MSは相当なものです。
ーーー
他にもPowerShellは、
●既存のメジャー関数型言語であるSQL(^^;と似させてる点が多い。
SelectとかWhereとかを使えるのは、そういう意図でしょう。
(これはLINQもだが)
●http://www.atmarkit.co.jp/fdotnet/special/powershell02/powershell02_02.html
「alias | group Definition | ? { $_.Count -ge 2 }」
という式を見ると判るが、SQLより素直なモデルである。
group関数が返す値が「要素のリスト(のリスト)」である。つまり二次元配列。
いっぽうSQLは返し値が常に一次元配列であることに拘ってしまったため、
group byで素直に「該当する行を束ねたリスト(のリスト)」を返すというモデルを採用できなかった。
(group byで明示的に同一視されるカラムか、集計関数(平均など)で1つの値にまとめたカラムか、しか通せない。)
おかげでかなり面倒な思いをすることが多い。
●Rubyまんせーな人は
「dir *.cs | foreach { $_.Name.ToLower() }」
という記述を見て萌えることでしょう。
こりゃRuby風に書き直せば
「dir("*.cs") . each {|x| x.Name.ToLower() }」
です。
OOP言語のメソッドチェインと、シェルのパイプの
類似性(というか本質同じ)に注目して設計されてるわけですね。
と、かなーり玄人好みになってるし、
モデルが素直じゃないわけではないので、むしろ既存シェルを知らない素人に教えるのも
苦労しないと想像します。
そんな感じで、かなりアレゲだと思っています。
Re:UNIX での代替品 (スコア:3, 参考になる)
PowerGadgets (スコア:5, 参考になる)
PowerGadgets [powergadgets.com]
要はGUIの汎用表示モジュールをパイプの最終段にもってくると便利だよね、というものですが、まあFlashのチュートリアルムービー [powergadgets.com]見てもらうのが早いかな。
ふしぎなじゅもんさトントカイモ (スコア:4, おもしろおかしい)
set-alias シニス get-childitem
set-alias ハニリイト get-childitem
さすが21せいきだな!
# やってることがパピコンレベル
Re:ふしぎなじゅもんさトントカイモ (スコア:1)
/* Kachou Utumi
I'm Not Rich... */
ヒョオォォォ (スコア:3, すばらしい洞察)
こいつはくせえッー!
脆弱性のにおいがプンプンするぜッーーーーッ!!
あれ、正式で名前が変わったのか (スコア:3, 参考になる)
古いバージョンが入ったままで PowerShell を入れようとしたら既に RC1 が入ってるから削除してください、と言われ、
プログラムの追加と削除から PowerShell を探したんだが見つからなくて困ってたのは秘密です(^^;
(古いバージョンではプログラムの追加と削除に表示されてる名前も Microsoft Command Shell だったので)
CPU毎にアーカイブが違うのって不便 (スコア:2, 興味深い)
今回の PowerShell なんか特に .NET を前提としてるんだから .NET のインストーラを1個用意して勝手にCPU判別とかてくれれば良いのになぁ、とか思います。
詳しくないのでアレなんですが、そういうことって難しいんでしょうかね?
Re:CPU毎にアーカイブが違うのって不便 (スコア:2, 参考になる)
同じバイナリでx86Windowsでもx64Windowsでも動くような。
# VS2005とかだとコンパイルオプションにAnyCpuやらなんやらを指定できたハズ。
そのために中間言語->ネイティブコード生成を.NetFrameworkがやってくれてるのかと。
・・WindowsPowerShellがどうなのかは知りませんけど。
Re:CPU毎にアーカイブが違うのって不便 (スコア:1)
ダウンロードサイズがアーキテクチャの種類分だけ大きくなります。
トラフィックも同様。
FTTHとかに慣れるとダウンロードで待つなんて感覚が薄れるかもしれませんが・・・
配布容量を気にしない環境ならたぶん既にどっかで実装されてると思います。
# 久々に500Kbpsを体験して遅いと思ってしまったのでID
Re:CPU毎にアーカイブが違うのって不便 (スコア:1)
・・・複数台にインストールする必要がある環境では時間がかかってしょうがないわけですがw
#そして、たぶんMSはソース公開したくないだろうから実現しない。
Re:CPU毎にアーカイブが違うのって不便 (スコア:2, 興味深い)
> #そして、たぶんMSはソース公開したくないだろうから実現しない。
そういう方向性でのMS的解決法が .NET でしょう。
CPU非依存なバイトコードでプログラムを保持し、実行時にコンパイル。
Linuxにもこんなのがほしい (スコア:2, すばらしい洞察)
bashを完全に置きかえるほどとは思いませんが、
強力なツールであるのは間違いないですし。
悔しいのでけなしてみる。
・.NET対応したところで、その形式で出力するソフトが少ないと意味がない。
テキスト形式の方が歴史があるから数もあるし、実際にソフトを作るときの敷居もテキストにかなうとは思えない。
・高度過ぎて野性的な部分が足りない。bashがシンプルなソフトと言うつもりは全くないが、
かなり無理矢理で、よくバグ出ないなぁってほど苦しいシェルスクリプトが書けてしまうのも事実。
そんな要素も必要だと思う。
思ったよりけなせない。ああ悔しい。
1を聞いて0を知れ!
Re:Linuxにもこんなのがほしい (スコア:1, すばらしい洞察)
テキストベースで事足りる世界なら、UNIXで十分強力。
テキストベースで足りる作業というのもことのほか多いというのもまた事実。
用途に応じて住み分けでいいんじゃね?と思うが。
Re:Linuxにもこんなのがほしい (スコア:1, おもしろおかしい)
UI(特に入力補助)が大事だよね (スコア:2, 興味深い)
どうせならVisual C#くらいのインテリセンスが欲しかった。
あと、キーバインドも。
例えば、オブジェクト名.で[TAB]だとアクセスできるプロパティが選べる。
これはインテリセンスに近くていいんだけど、順番にしか選べなくてチョット不満。
引数に取れるオブジェクト型が決まってるなら、それが出てきて欲しいんだけど、空白で[TAB]だと常にタブ補完。
Ctrl-系のラインエディット機能が全然使えないとか。
あと、マウスによる領域の選択が例のごとく箱型のみとか。
フロントエンド自体は見た目以外は従来のcmdと同じみたいだけど、実はここらへんをもっと充実させて欲しい。
そうしないと、.NETオブジェクトをハンドルできる機能を乗っけてても、実際に使うのが面倒だ。
SQLとかでテーブルいじくってる感じがする。 (スコア:2, 参考になる)
あと、参考になりそうなリソース置いておきますね。Blog of Windows PowerShell team. [msdn.com]。
PowerShellを使ってみました。(おそまきながら+長文) (スコア:2, 参考になる)
その方向で歓迎している前提で見てください。
まず、コマンド書式 動詞-名詞が決まっているのはうれしいです。
それにhelpがman形式的でありながら、統合されているのもいいです。
# Unixコマンド ccがコンパイラでddがダンプで...って簡単には
# あと、manが別になっていて、なかったりとか管理もめんどうだった
## help日本語になってますねー
細かいですが、オプションが-だったり、\がパス区切に使えるのもいいです。
カンタンなスクリプトとかだったら、移植しやすそうです。
いっぽう、NGなのはshell自体としてはbash/zshにくらべ貧弱なのはどうかとおもいます。
ただ、機能自体は.NETのライブラリの集合体なので、Poderosaにでも統合されると便利か
もしれません。
# だれかプラグイン書く?
なんとなくですが、目標が Unix shell(いちおう標準規格はあったよ
ね)+alphaのようで、その目的は達成していると思います。
他に期待や誤解の元など
1.プロバイダが期待大
これがけっこう便利で、オブジェクト操作さえ行えるならなんでもアリっ
ぽいです。
SQL:やFTP:やWebDAV:やWebAPI:やFILE:(Unix風のmountとか)や...と期待
は大きいなーと。
2.パイプ
各cmdlet間はオブジェクトですが、通常コマンド間や通常コマンド-
cmdlet間はテキストなので、今迄の使い方もできます。(Write-outなどの
テキスト化もできるし)
むしろプロパティで付随情報をやりとりできるのがやっぱり便利ですね。
3.VMとリモート処理
VMがMS謹製なのが気掛りとの意見があったけど、MonoプロジェクトのVMで
もいいんだし、へたにコマンドごとに別だったとしても、どこかにバグが
あるほうがやっかいな気がする...メモリも食うし
あと、リモート処理や既存のコマンドとの連携ですが、データにもよりま
すが、ラッパcmdletやxml化/オブジェクト化cmdletを用意するなりすれば
簡単に解決すると思います。
# もっとも、そこまでして別マシンにデータを送付する必要はないように
も思いますが。
4.利用感
最後にフィーリングですが、スクリプトに強い系(Perlとか)とシェル操作
に強い系がよい感じで一体になっているので、.NETのオブジェクトが操作
できるようになった版のPerl/Ruby/Pytonがあると連携できるようになったりとか、
オブジェクト操作が公開されていればどの.NETアプリでもマクロ的操作が
OKになるんじゃないかなとか、(WSHで果せなかった)夢は見れそうです。
いい意味でMSに頑張ってほしいですね。
M-FalconSky (暑いか寒い)
Windows を Unix で作り直し (スコア:1, おもしろおかしい)
Re:Windows を Unix で作り直し (スコア:1, すばらしい洞察)
何を根拠に手っ取り早いとうのか。
実際 Windows を作り直して、と言われたら手っ取り早く作れますか?
Macはそうしたんだっけ? (スコア:1, 興味深い)
Re:Macはそうしたんだっけ? (スコア:0)
Re:Macはそうしたんだっけ? (スコア:2, すばらしい洞察)
レジストリがもしもテキストベースになっても同じだと思います。
一番の違いはUNIXよりも更に細分化された徹底的とも言えるモジュール化(COMとか)でしょう。
あと、書き換え失敗したら起動しなくなる危険性ってinittabとかlilo.conf、fstab書き換え失敗したら同じことよね。
# 別に各アプリの設定代えたいだけならHKLM\Software\とHKCU\Software\だけで事足りるかと。
Re:Macはそうしたんだっけ? (スコア:2, すばらしい洞察)
いいえ。
一番の違いはオンラインマニュアル(というかヘルプ)にレジストリの情報が載っていないことでしょう。
> # 別に各アプリの設定代えたいだけならHKLM\Software\とHKCU\Software\だけで事足りるかと。
本当に変更したいのは、アプリが利用している Windows のコンポーネントの挙動だったりする罠。
Re:Windows を Unix で作り直し (スコア:0)
WindowsX が出るのは2007年頃でしょうか?
Re:Windows を Unix で作り直し (スコア:1)
で、個人的に思うことは… (スコア:1)
あと、リモート操作できるの?
/* Kachou Utumi
I'm Not Rich... */
この記事を読んで改めて思う。 (スコア:0, すばらしい洞察)
って、感じがする。
Re:この記事を読んで改めて思う。 (スコア:1, 興味深い)
ほとんどのビジネスの本質であり、最大の褒め言葉だろうな。
Re:この記事を読んで改めて思う。 (スコア:0)
Re:この記事を読んで改めて思う。 (スコア:0)
Re:この記事を読んで改めて思う。 (スコア:0)
Windows Vista (スコア:0)
会社じゃなくても、家でちょいちょいやるには、ぜひ欲しいです。
どのバージョンに収録されるか明らかになってないようですね。
Re:Windows Vista (スコア:3, すばらしい洞察)
レジストリ操作できるのは期待してます。
Re:Windows Vista (スコア:1, 参考になる)
サードパーティーのものでは、tcsh for Win32 [wbs.ne.jp]とかNYAOS [nyaos.org]などがあります。
Re:Windows Vista (スコア:2, 参考になる)
#私はもっぱらCygwin [cygwin.com]だけど。
Re:Windows Vista (スコア:1)
ただ、Linuxで使っていたスクリプトがほとんど修正なしで使えてしまうのは恐ろしく便利ですが。
Re:Windows Vista (スコア:1)
シェルはぶっちゃけ外部コマンド起動するだけだから
外部コマンドを全部移植しないと、シェルだけ移植しても全く使い物にならない
たとえばshのif はコマンドのexit値しか判断できないので
if [ ... ] ;then
これは [ という外部コマンド呼んでる
Re:Windows Vista (スコア:1)
古典的な Bourne Shell ではその通りでしたが、後期の Bourne Shell とか、その後に出たbashなどの互換シェルは、[/test とか echo とかのよく使うコマンドを内部に持ってますよ。 [annodex.net]
まあ、ある程度の外部コマンドが無いと使い物にならないのは確かだと思いますが。
プロセスが溢れて新規プロセスを起こせなくなったときなどに、内部コマンドだけでがんばることが時折あります。
echo * でファイル一覧を取り、while と read でファイル内容を表示とか。
Re:XP以上か (スコア:3, 参考になる)
Re:XP以上か (スコア:2, 興味深い)
そんなに、2000(Server)を捨てさせたいのだろうか。
/* Kachou Utumi
I'm Not Rich... */
Re:補完とかも強力にしてほしかったかも!? (スコア:1, 参考になる)