パスワードを忘れた？ アカウント作成
Close
13942 story

マイクロソフト、「Windows PowerShell」v1.0を公開 86

ストーリー by mhatta
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などと比べ貧弱だと感じていた方は是非一度試してみてはいかがでしょう?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

マイクロソフト、「Windows PowerShell」v1.0を公開 More

  • UNIX での代替品 (スコア:5, 興味深い)

    by oltio (3848) on 2006年11月16日 9時59分 (#1059097) 日記
    @IT の記事をざっと読みましたが、面白いですねこれ。.NET のクラスライブラリと直結していることと、オブジェクトを扱えること、コマンドレット+エイリアスという仕組みは強力そうだ。.NET を中心に据えたことのうまみが生きてきているように感じます。

    UNIX だと、同様のことはテキストベースでコマンド+sh スクリプトということになりますが、もういい加減標準 sh 用シェルスクリプトを書きたいとは思えないとか、テキストのパーズで思いもよらぬバグに直面したりとか、とても21世紀の環境とは思えない。

    一方で、例えば常に irb (Ruby の対話シェルみたいなの) の中で生きていく、というような手法もあるかもしれません。irb のコマンドプロンプトを普通のシェルのようにして、一通りのコマンドを用意すれば、多分生活に充分なシェル環境が作れるし、スクリプトを書く上では sh よりはるかに優れた言語を使うことができます。問題は他のアプリケーションとの連携ですが、bonobo との通信をサポートするといった、かなり面倒そうな解決方法しか思いつきません…。

    • Re:UNIX での代替品 (スコア:5, 参考になる)

      by Anonymous Coward on 2006年11月16日 10時47分 (#1059147)
      >一方で、例えば常に irb (Ruby の対話シェルみたいなの) の中で生きていく、というような手法もあるかもしれません。

      オライリーのPython本の中で、そのような使い方が提示されてた記憶があります。
      Pythonは、引数なしで起動すると、対話シェルなので。

      Monad改めWPSが、従来のUNIXシェル＋パイプと大きく違うのは、MSのドキュメントにある
      > Windows PowerShell では、パイプラインのコマンド間でデータを受け渡すのに、テキストではなくオブジェクトが使用されています。
      ってところだと思います。

      UNIXシェルだと、パイプはバイトストリームなので、上流のプロセスが、出力をバイトストリームに
      マーシャリングし、下流のプロセスがそれをアンマーシャリングする必要がある。その際、
      取捨選択するのは下流プロセスなので、マーシャリングされたすべてのバイトがパイプを流れる。

      対して、WPSだと、パイプを流れるのはオブジェクトなので、下流のコマンドレットがプロパティを
      要求し、要求されたものだけが、パイプを通して下流コマンドレットに渡される。その際、
      バイトストリームにマーシャリング、アンマーシャリングする必要も無い。

      パイプの段数が深くなるほど、後者の方がパフォーマンス的に優位だと思います。

      後は、コマンドラインで、emacsキーバインドさえ使えれば…
      シェア
      親コメント
      • > バイトストリームにマーシャリング、アンマーシャリングする必要も無い。
        >
        > パイプの段数が深くなるほど、後者の方がパフォーマンス的に優位だと思います。

        そのかわり、バイトストリームなら簡単に実現できた可用性
        （ファイルに保存して別ホストに転送とか）や互換性（.NET 以外のフレームワーク、
        たとえば ruby とか java とか）がなくなるんじゃない？

        それに、 OS と違って、VM ってまだまだ安定しているとは言いがたい。
        一つの VM にあんまり依存しちゃうのは、信頼性の面から見てちょっと心配なところがある。

        大抵の場合は、単純なシステムを高並列化して性能を上げる方が
        簡単だし障害が少ない。
        ほんとに、そんなパフォーマンスが重要な局面ってあるのかなぁ？

        かえって保守不能な複雑化を抱えこんじゃう気がしないでもない。

        ＃でも保守不可能な難解プログラム書くの好きな人多いんだよなー
        --
        # mishimaは本田透先生を熱烈に応援しています
        シェア
        親コメント

        • それはKISSではない (スコア:1, 興味深い)

          by Anonymous Coward on 2006年11月18日 0時37分 (#1060273)
          「必ず」マーシャル＆アンマーシャル処理が挟まるアーキテクチャは、
          挟まる必要がなく「素通し」することが出来るアーキテクチャより、
          フクザツなんじゃないでしょうか？

          むしろ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っぽくありませんかね？
          シェア
          親コメント
          • その単純さは、アプリケーション開発に限った話に聞こえちゃうなぁ。

            プログラムが暴走したとき最小限の被害で止める方法が
            確立されてなかったり、バージョンごとで違ったり、
            VM ごとで違ったり、被害がでかかったり。そういうのを管理するのはつらい。

            C 言語やシェルスクリプトは、そこで悩む必要がない。

            > >そんなパフォーマンスが重要な局面ってあるのかなぁ？
            > うん。それは確かに少ないです。
            > ただし、そのトレードオフを悩むべきなのは、「パフォーマンスのために扱いやすさが犠牲になる」場合ですよね。

            いやいや、システム管理のことも、さらに上流のことも考えてほしい。
            システム管理ではまだ枯れてない .NET を扱うのに手間がかかる。
            システム設計では、複数のアーキテクチャを同時に扱う状況がよくある。
            この状況は 10 年経ってもあまり変わらないんじゃないだろうか。

            そういう状況の中での、VM への集中を促す、この Windows Power Shell の試み。
            こりゃ、Windows 全体を、OS ではなく VM と考えて、
            TCP/IP というストリーム経由で入出力を行え、ということなんじゃないだろうか。
            Windows そのものが、一個のプログラムという考え方。
            Xen とかの仮想環境で、プロセスを起動するように Windows を立ち上げる。

            そこまで含めての「標準入出力2.0」なのかも知れない。

            問題は OS のライセンスかな…
            --
            # mishimaは本田透先生を熱烈に応援しています
            シェア
            親コメント

      • Re:UNIX での代替品 (スコア:1)

        by gnaka (17369) on 2006年11月16日 11時15分 (#1059173) 日記
        　シリアライズといわずマーシャリングという用語を使われるあたり、マイクロソフトの方でしょうか? いや、別にいいんですが

        　確かに面白そうな技術ですが、.NETの手のひらの上でしか動かないであろうことが残念ですね。Windowsはオブジェクト指向環境というわけでないので仕方ないのですが。ただ、位置づけとしてはWSHの後継ということでしょうから、対話シェルというより、システムの運用に関連したちょっとしたスクリプトの実行用ということでしょうね。それならば差し当たり問題ないと思います。ただ既に指摘されているように標準で載ってこないのは残念。

        　要求したプロパティだけが渡されるとのことですが、@ITの記事を見る限りではオブジェクト全体が渡されていそうにも見えます。ただ、実際にはオブジェクトへの参照が渡されているだけかもしれないので、効率がどうなっているかはわかりませんが。もしプロセス境界をまたいでいるなら、なんらかの(若干別の意味の)マーシャリングは行われそうですな。
        シェア
        親コメント

        • Re:UNIX での代替品 (スコア:2, 参考になる)

          by Ryo.F (3896) on 2006年11月16日 12時00分 (#1059219) 日記
          > シリアライズといわずマーシャリングという用語を使われるあたり、マイクロソフトの方でしょうか?

          Ruby関係の方々もマーシャリングって言うんじゃなかろうか(Marshal [ruby-lang.org])。
          シェア
          親コメント

          • Re:UNIX での代替品 (スコア:2, 参考になる)

            by Anonymous Coward on 2006年11月16日 17時37分 (#1059455)
            マーシャリング／アンマーシャリングというのは、別に Microsoft 用語では
            なく、非常に古くからある用語です。Java の誕生より前から。
            個人的には、むしろなぜ Java が既存の術語を使わなかったのかの方を、
            かねがね疑問に思ってます。
            シェア
            親コメント

      • Re:UNIX での代替品 (スコア:1, 興味深い)

        by Anonymous Coward on 2006年11月17日 9時29分 (#1059771)
        >パイプを流れるのはオブジェクトなので、下流のコマンドレットがプロパティを
        要求し、要求されたものだけが、パイプを通して下流コマンドレットに渡される。

        他の人も指摘していますが、そう読める箇所が見当たりません。
        しかし一方で、それを否定する箇所も見つからないですね。

        ソレを実現するためには、「オブジェクトなので」は十分条件ではありません。
        「オブジェクトなので」出来ることは、オブジェクトのプロパティだけ触るから、「全てのオブジェクトを渡されても全てのデータを触る必要は無い」という点だけです。オブジェクトそのものが下流に渡されないことまでは(工夫しないと)実現できませんね。
        (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, 参考になる)

      by yasushi (789) on 2006年11月16日 10時45分 (#1059143)
      irbsh [rubyist.net]とか？
      シェア
      親コメント

  • PowerGadgets (スコア:5, 参考になる)

    by Anonymous Coward on 2006年11月16日 11時30分 (#1059191)
    こういうのがあります。
    PowerGadgets [powergadgets.com]

    要はGUIの汎用表示モジュールをパイプの最終段にもってくると便利だよね、というものですが、まあFlashのチュートリアルムービー [powergadgets.com]見てもらうのが早いかな。

  • ふしぎなじゅもんさトントカイモ (スコア:4, おもしろおかしい)

    by chronatog (8479) on 2006年11月16日 11時25分 (#1059187) 日記
    なにこれちょうべんり

    set-alias ｼﾆｽ get-childitem
    set-alias ﾊﾆﾘｲﾄ get-childitem

    さすが２１せいきだな！

    # やってることがパピコンレベル

  • ヒョオォォォ (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2006年11月16日 10時36分 (#1059132)
    ＞ファイルへのアクセスと同様の操作でレジストリなどのシステムデータを扱えるほか……
    こいつはくせえッー！
    脆弱性のにおいがプンプンするぜッーーーーッ!!
  • RC1 の時は Microsoft Command Shell って呼んでたのに、正式では Windows PowerShell になったんですね。

    古いバージョンが入ったままで PowerShell を入れようとしたら既に RC1 が入ってるから削除してください、と言われ、
    プログラムの追加と削除から PowerShell を探したんだが見つからなくて困ってたのは秘密です(^^;
    （古いバージョンではプログラムの追加と削除に表示されてる名前も Microsoft Command Shell だったので）
  • 最近CPUの種類も増えてきて Windows でも自分の環境に合わせたバイナリを落とさせることをときどき見ますが、ダウンロードの時に一考しなきゃいけないのが面倒で、結局入れてみることをしない、ということがあります(^^;

    今回の PowerShell なんか特に .NET を前提としてるんだから .NET のインストーラを1個用意して勝手にCPU判別とかてくれれば良いのになぁ、とか思います。
    詳しくないのでアレなんですが、そういうことって難しいんでしょうかね？

    • Re:CPU毎にアーカイブが違うのって不便 (スコア:2, 参考になる)

      by Anonymous Coward on 2006年11月16日 10時40分 (#1059135)
      .Netアプリケーションであれば、プラットフォームを制限してコンパイルしなければ
      同じバイナリでx86Windowsでもx64Windowsでも動くような。
      # VS2005とかだとコンパイルオプションにAnyCpuやらなんやらを指定できたハズ。
      そのために中間言語->ネイティブコード生成を.NetFrameworkがやってくれてるのかと。

      ・・WindowsPowerShellがどうなのかは知りませんけど。
      シェア
      親コメント
    • ＞詳しくないのでアレなんですが、そういうことって難しいんでしょうかね？
      ダウンロードサイズがアーキテクチャの種類分だけ大きくなります。
      トラフィックも同様。
      FTTHとかに慣れるとダウンロードで待つなんて感覚が薄れるかもしれませんが・・・

      配布容量を気にしない環境ならたぶん既にどっかで実装されてると思います。

      # 久々に500Kbpsを体験して遅いと思ってしまったのでID
      シェア
      親コメント

  • Linuxにもこんなのがほしい (スコア:2, すばらしい洞察)

    by greentea (17971) on 2006年11月16日 10時46分 (#1059145) 日記
    素直にそう思います。
    bashを完全に置きかえるほどとは思いませんが、
    強力なツールであるのは間違いないですし。

    悔しいのでけなしてみる。

    ・.NET対応したところで、その形式で出力するソフトが少ないと意味がない。
    　テキスト形式の方が歴史があるから数もあるし、実際にソフトを作るときの敷居もテキストにかなうとは思えない。
    ・高度過ぎて野性的な部分が足りない。bashがシンプルなソフトと言うつもりは全くないが、
    　かなり無理矢理で、よくバグ出ないなぁってほど苦しいシェルスクリプトが書けてしまうのも事実。
    　そんな要素も必要だと思う。

    思ったよりけなせない。ああ悔しい。
    --
    1を聞いて0を知れ!

    • Re:Linuxにもこんなのがほしい (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2006年11月16日 11時01分 (#1059162)
      いや。これは、単にテキストベースか、オブジェクトベースかという話でしかない。
      テキストベースで事足りる世界なら、UNIXで十分強力。
      テキストベースで足りる作業というのもことのほか多いというのもまた事実。
      用途に応じて住み分けでいいんじゃね？と思うが。
      シェア
      親コメント

    • Re:Linuxにもこんなのがほしい (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2006年11月16日 11時20分 (#1059179)
      あら、そろそろ OpenPowerShell っての誰か計画して参加募りそうね?
      シェア
      親コメント

  • UI(特に入力補助)が大事だよね (スコア:2, 興味深い)

    by Anonymous Coward on 2006年11月16日 13時05分 (#1059278)
    インテリセンスとタブ補完の中間なのが惜しい。
    どうせならVisual C#くらいのインテリセンスが欲しかった。
    あと、キーバインドも。

    例えば、オブジェクト名.で[TAB]だとアクセスできるプロパティが選べる。
    これはインテリセンスに近くていいんだけど、順番にしか選べなくてチョット不満。

    引数に取れるオブジェクト型が決まってるなら、それが出てきて欲しいんだけど、空白で[TAB]だと常にタブ補完。

    Ctrl-系のラインエディット機能が全然使えないとか。

    あと、マウスによる領域の選択が例のごとく箱型のみとか。

    フロントエンド自体は見た目以外は従来のcmdと同じみたいだけど、実はここらへんをもっと充実させて欲しい。
    そうしないと、.NETオブジェクトをハンドルできる機能を乗っけてても、実際に使うのが面倒だ。
  • Windows PowerShellはSQLとかでテーブルをいじってる感じがします。いや、まだ実際には触ってませんが。

    あと、参考になりそうなリソース置いておきますね。Blog of Windows PowerShell team. [msdn.com]。
  • 先に言うとUnix like shellは好きなほうなので、
    その方向で歓迎している前提で見てください。

    まず、コマンド書式 動詞-名詞が決まっているのはうれしいです。
    それに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, おもしろおかしい)

    by Anonymous Coward on 2006年11月16日 10時04分 (#1059102)
    こうした方が手っ取り早いし、Unix と Windows が同時に使えて便利。

    • Re:Windows を Unix で作り直し (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2006年11月16日 10時14分 (#1059112)
      ＞こうした方が手っ取り早いし

      何を根拠に手っ取り早いとうのか。
      実際 Windows を作り直して、と言われたら手っ取り早く作れますか？
      シェア
      親コメント

    • Macはそうしたんだっけ？ (スコア:1, 興味深い)

      by Anonymous Coward on 2006年11月16日 10時23分 (#1059117)
      Macももともとは独自カーネルだったそうですね。
      シェア
      親コメント
      • 移行にはめちゃめちゃ苦労したし、最初の頃のOSXはぼろくそに言われましたがね。
    • Windows95=Mac89などと揶揄されたことを考えると、MacOSX が出たのは2001年だから
      WindowsX が出るのは2007年頃でしょうか?
  • GUI抜きで、このshellだけでOS起動できるの?
    あと、リモート操作できるの?
    --

    /* Kachou Utumi
    I'm Not Rich... */

  • この記事を読んで改めて思う。 (スコア:0, すばらしい洞察)

    by Anonymous Coward on 2006年11月16日 9時44分 (#1059084)
    MSって簡単な事を、複雑に実現する会社。

    って、感じがする。

  • Windows Vista (スコア:0)

    by Anonymous Coward on 2006年11月16日 9時48分 (#1059087)
    管理者向けとはいえ、Windows Vistaのベーシックな方にも搭載して欲しいな。

    会社じゃなくても、家でちょいちょいやるには、ぜひ欲しいです。

    どのバージョンに収録されるか明らかになってないようですね。

    • Re:Windows Vista (スコア:3, すばらしい洞察)

      by ciina (26410) on 2006年11月16日 10時41分 (#1059136) 日記
      cmd.exeはインストール無しに客先でも何処でもスクリプト組めるのが魅力なわけで、標準搭載される(だろう)次期Windows Serverはいつになるのでしょうか？
      レジストリ操作できるのは期待してます。
      シェア
      親コメント

    • Re:Windows Vista (スコア:1, 参考になる)

      by Anonymous Coward on 2006年11月16日 10時32分 (#1059129)
      面倒なことしないで、Unix向けのシェルソフトを移植しちゃえばいい（bash、tcsh、zshの3つくらいあればほとんどの人は満足するような気がする）のに、と思わなくもないですが、本家から高性能なシェルが出ること自体は歓迎したいですね。

      サードパーティーのものでは、tcsh for Win32 [wbs.ne.jp]とかNYAOS [nyaos.org]などがあります。
      シェア
      親コメント

      • Re:Windows Vista (スコア:2, 参考になる)

        by Ryo.F (3896) on 2006年11月16日 10時54分 (#1059157) 日記
        SFU: Services for UNIX [microsoft.com]なら昔からMicrosoftが出してるぞ。

        ＃私はもっぱらCygwin [cygwin.com]だけど。
        シェア
        親コメント

      • Re:Windows Vista (スコア:1)

        by gesaku (7381) on 2006年11月16日 11時19分 (#1059177)
        cygwin [cygwin.com]でいいじゃん、と思ったけど環境まで変えてしまうからちょっと方向性が違うか。
        ただ、Linuxで使っていたスクリプトがほとんど修正なしで使えてしまうのは恐ろしく便利ですが。

        シェア
        親コメント

      • Re:Windows Vista (スコア:1)

        by bero (5057) on 2006年11月17日 16時56分 (#1060032) 日記
        んなわけねー
        シェルはぶっちゃけ外部コマンド起動するだけだから
        外部コマンドを全部移植しないと、シェルだけ移植しても全く使い物にならない

        たとえばshのif はコマンドのexit値しか判断できないので
          if [ ... ] ;then
        これは [ という外部コマンド呼んでる

        シェア
        親コメント
        • たとえばshのif はコマンドのexit値しか判断できないので
              if [ ... ] ;then
          これは [ という外部コマンド呼んでる

          古典的な Bourne Shell ではその通りでしたが、後期の Bourne Shell とか、その後に出たbashなどの互換シェルは、[/test とか echo とかのよく使うコマンドを内部に持ってますよ。 [annodex.net]
          まあ、ある程度の外部コマンドが無いと使い物にならないのは確かだと思いますが。

          プロセスが溢れて新規プロセスを起こせなくなったときなどに、内部コマンドだけでがんばることが時折あります。
          echo * でファイル一覧を取り、while と read でファイル内容を表示とか。
          シェア
          親コメント
typodupeerror

にわかな奴ほど語りたがる -- あるハッカー