Windowsがまともなシェルを持っていなかった理由は何ですか？
私はSOに関するトピックを読んでいました なぜスクリプト言語（たとえば...）がシェル言語として適していないのですか？ 。特に私は JörgW Mittagによる回答 が好きで、そこからWindows PowerShellについて興味深いことを学びました。したがって、20年以上経過したWindowsには、適切に設計されたシェルがついに登場しました（Windows 1.0-1985、PowerShell安定版リリース-2009）。一方、Unixシステムには、1978年のBourne Shell以降、さまざまなシェルがたくさんあります。 MSの就職の面接に関するいくつかの記事を読んだことがあり、非常に「マニアック」な会社の印象を持っています。コマンドラインツールが必要でなかったのは、それらのツールを使用してすべての作業を行うUnixの人々と比較してなぜだったのでしょうか。
IPod、iPhone（さらに言えばすべての電話）、iPadがそうではないのと同じ理由：コマンドラインは、Windowsでのコンピューターとのユーザー対話の主要なチャネルではありません。それはUNIXまたはGNU/Linuxにあります-そのため、それらはより成熟しています。 Linux GUIデスクトップがWindowsと比較して非常に長い間ごみだったのと同じ議論（Mac OSは、UNIXのコマンドラインを無料で入手したため、ここでのごまかし）。
多分私は単純化しすぎているかもしれませんが、私はそれを文化的なものとして考えています：
- マイクロソフトの文化では、開発者はsers向けのプログラムの作成に重点を置いています。プログラムはすべてGUIベースです。
- Unixの文化では、開発者は他のdevelopers用のプログラムを書くことに集中しています。プログラムは小さく、特定のことをうまく行うことに焦点を当てています。
Windows用のシェルを作成できるのがマイクロソフトだけである理由はありません。 bashを書く人は* nixカーネルを書く人とは異なります。 root権限も必要ありません。自分のシェルをコンパイルして、sysadminがインストールされたシェルが気に入らなかったときに使用しました。より優れたWindowsシェルに対する真の要求があった場合、誰かがそれを書いたでしょう。
十分な数の募集がなかったので、私は推測します。
Windows Scripting Hostは、Windows 98以降標準でインストールされています（その前にあったと思います）。 VBScriptは非常に優れていました。または、Windows API全体にアクセスできるコマンドラインツールを簡単に作成できます。
簡単に言うと、Powershellは同じ方向へのもう1つのステップにすぎません。 COMはもはや人気がないので、WSHはかなりの学習プロセスになっています。しかし、.NETはWindowsの世界における現在のビッグシングであり、.NETの背景からPowershellを学ぶのは比較的簡単です。
Powershellが間違っていると私が思う1つの場所は、* nixの群衆にもアピールしようとしていることです。
コマンドラインスイッチとは別に、Powershellではveryの違いがあり、実際にそれを理解するときに最初に学ぶ必要があります。
正直なところ、シェル、バッシュではなく、Perlのようなスクリプト言語に似ています。これをプライマリシェルとして使用しようとすると、いくつかの重大な問題があります。
たとえば、Powershellから簡単なSVNダンプを実行してみます。 stdoutのバイナリデータをうまく処理しません。一方、SVNログの操作は、組み込みのxmlタイプのおかげで、絶対的な夢です。
なぜなら、2番目の並列Windowsツールセットを開発する必要はほとんどなく、大きな痛みがあるからです。
シェルは、sed、find、xargsなどのGNUシステム上のヘルパープログラムの数と能力によって強力になります。これらのツールの再実装は多くの作業であり、 CygwinはそのようなPOSIXコンプライアンスレイヤーであり、シェルユーザーがWindowsを使用せざるを得ない場合に必要とするほとんどのニーズに対応します。
私は個人的に、POSIXとLinuxのバンドワゴンに飛び乗りたくない、しかもシェルプログラミングに十分に専念している開発者コミュニティは非常に小さいので、安定したシェルを開発するのに20年かかりました。
これは、陰謀論を無視して、おそらく単一の答えがない質問の1つであり、歴史家が決定的な答えを見つけることなく永遠に議論できるようなものです。
私の印象は、シェルの力はすぐには明らかではないということです。私はWindows 3.1でプログラミングを始めましたが、シェルはほとんど使用されていませんでした。すべてがVisual C++ IDEを介して行われ、 makefiles を見たことはありません。DOSバッチファイルは非常に制限されているため、バッチファイルを使用して基本的なバックアップよりも複雑なものを自動化することはほとんどありませんでした。 Windowsに焦点を当てたプログラミングの本はありません（私は Petzold の良い思い出があります）私は、Windowsシェルを使用して何かについて議論したときに読んでいました。 Linuxの使用とプログラミングを始めるまでは、強力なシェルがどれほど有用であるかを理解していませんでした。 Windowsが登場したとき、古いcommand.comを使う必要がなくなったので、とても興奮しました。 [〜＃〜] tsr [〜＃〜] ...を必要とせずに、複数のフォントと複数のプログラムを同時に実行するかなりのインターフェースがついに完成しました.
Windowsで始めるほとんどのプログラマーは、強力なシェルの経験がないため、Windows用に実装する差し迫った必要性を感じていないと思います。 Linuxで作業し、シェルを高く評価し、Linuxで作業することを好むプログラマーは、Windowsでの実装にあまり慣れていない環境で作業することに時間を費やす気がありません。別の質問で、シェル自体とともに必要なすべてのCLIツールを実装する必要性についても説明します。
Linuxの人気の高まりは、おそらく、Microsoftが最終的に適切なシェルを導入した主な理由です。ますます多くの人々がシェルの有用性を理解するにつれて、Windowsに重要なツールが欠けていることがますます明らかになりました。
Windowsには、スクリプトに適さない設計機能があります。これは、グラフィカルインターフェイスを主要な操作モードにした結果です。多くのツールには、機能的なコマンドラインインターフェイスがありません。適切なコマンドラインインターフェイスがないと、優れたシェルを生成することが非常に困難になります。
多くの場合、Windowsでスクリプトを作成する必要がある場合、アプリケーションウィンドウのさまざまな場所でマウスクリックとキーストロークをシミュレートする必要があります。結果のスクリプトは非常に壊れやすい場合があります。関連するジオメトリがすぐに利用できないため、コマンド言語でスクリプトの記述場所を説明することは簡単なことではありません。
また、Windowsには初期のバージョンでは機能的なパイプメカニズムがありませんでした。説明のとおり、最初のプロセスが実行され、その出力が一時ファイルに保存されます。そのファイルは、次のコマンドへの入力として使用されます。これはディスクを集中的に使用する可能性があり、十分な一時スペースが利用できない場合は失敗します。 Unixパイプはメモリ内のデータを渡し、遅延を最小限に抑える方法でプロセスをスケジュールします。
もしあなたがUnixシェルを「まとも」であると考えるなら、何十年も「まとも」であったWindows用のシェルが少なくとも1つあります。 ハミルトンCシェル は、Unix Cシェルにかなり近いです（ただし、Cシェルは、Unixで特に大きな市場への浸透がなかったことに注意してください）。かなりの数の人がJPSoftのさまざまなシェル（4DOS、4NT、現在はTake Commandと呼ばれています）をかなり長い間使用してきました。名前から推測できるように、4DOSはMS-DOS時代にさかのぼります。
15年ほど前にMicrosoftによって配布されたシェルを主張する場合、Windows NTリソースキットは PD Korn Shell のNTポートを含めるために使用されていました。1、かなりの数のUnix風のユーティリティとともに。おそらく、変更なしで多くのシェルスクリプトを実行するのに十分ではありませんでしたが、かなりの量の使用、特にかなりインタラクティブな作業を処理するには十分でした。
1正直言って、それがその正確なシェルのポートだったのか、それとも非常によく似たものだったのかはわかりません。これを十分に使用して、Unixシェルが存在することを思い出したのと同じくらい煩わしいことを確認し、そのままにしておきました。
それが発売されたとき、1993年に、Windows NTはMSによって、以前はUnixサーバーによって占められていた領域への移動であり、当時、POSIXの互換性と移植性について大きな取り決めがなされていました。しかし、それはうまく機能しませんでした。代わりに、ユーザーはより優れたハードウェアを使用するデスクトップ群衆でした（32MBの486dx 50MHz、RAMがトップエンドに近かった時代）。そして、より良いOSを望んでいました。しかし、彼らはシェルに興味がなかったため、すべてが失敗しました。この市場をクラックする2番目の深刻な試みであるWindows Server 2000までに、MSは、シェル側が弱いことに気づいたと思います-管理者はシェルスクリプトを愛しているようですが、それでも、かゆみを掻くのにしばらく時間がかかりました。