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に比べて長い間ゴミだった理由と同じ議論（Unixコマンドラインを無料で入手できたため、ここではMac OSのチート）。

多分私は単純化しすぎているかもしれませんが、私はそれを文化的なものだと考えています。

1. マイクロソフトの文化では、開発者はユーザー向けのプログラムの作成に重点を置いています。プログラムはすべてGUIベースです。
2. Unix文化では、開発者は他の開発者向けのプログラムの作成に集中しています。プログラムは小さく、特定のことをうまく行うことに焦点を合わせています。

MicrosoftがWindows用のシェルを作成できる唯一の人になることができる理由はないことに注意してください。bashを書く人は、* nixカーネルを書く人とは異なります。ルート権限さえ必要ありません。sysadminがインストールしたシェルが気に入らなかったときに使用する独自のシェルをコンパイルしました。より優れたWindowsシェルに対する真の要求があった場合、誰かがそれを書いていただろう。

十分な電話がなかったので、私は推測します。

Windows Scripting Hostは、Windows 98以降に標準としてインストールされています（その前にあったと思われます）。VBScriptは非常に有能でした。または、Windows API全体にアクセスできるコマンドラインツールを簡単に作成できます。

簡単に言えば、Powershellは同じ方向へのもう1つのステップです。COMはもはや人気がないため、WSHは非常に学習プロセスになりました。しかし、.NETはWindowsの世界における現在のビッグシングであり、.NETの背景からPowershellを学ぶのは比較的簡単です。

Powershellが間違っていると思う場所の1つは、* nixの群衆にもアピールしようとしていることです。エイリアスはすべて、明らかにそうではないがBashのように見えます。

コマンドラインスイッチとは別に、Powershellではパイピングが非常に異なるため、実際にそれを拾うときに学ぶべき最初のことです。

そして、正直なところ、シェル、la Bashというよりも、スクリプト言語、la Perlによく似ています。プライマリシェルとして使用しようとすると、いくつかの重大な落とし穴があります。

たとえば、Powershellから簡単なSVNダンプを実行してみてください。stdoutのバイナリデータをうまく処理しません。一方、SVNログの操作は、組み込みのxml型のおかげで絶対的な夢です。

2番目の並列Windowsツールセットを開発する必要はほとんどなく、多くの苦痛があるためです。

シェルは、sed、find、xargsなどのGNUシステム上のヘルパープログラムの数と力によって強力になります。これらのツールを再実装するのは大変な作業であり、Windows上にPOSIX準拠レイヤーを構築するだけではるかに簡単になりました。CygwinはこのようなPOSIX準拠レイヤーであり、シェルユーザーがWindowsの使用を余儀なくされた場合のほとんどのニーズに対応します。

私は個人的に、POSIXとLinuxの時流を飛び越えたくない、シェルプログラミングに十分に専念している開発者コミュニティは非常に小さく、安定したシェルを開発するのに20年かかったと思います。

これは、陰謀理論を無視して、おそらく単一の答えを持たず、決定的な答えを見つけることなく、歴史家が永遠に議論することができる種類の質問の1つです。

私の印象では、シェルの威力はすぐにはわかりません。私はWindows 3.1でプログラミングを始めましたが、シェルの使用はほとんどありませんでした。すべてがVisual C ++ IDEを介して行われ、メイクファイルを確認したことはなく、DOSバッチファイルが非常に制限されていたため、バッチファイルを使用して基本的なバックアップより複雑なものを自動化することはほとんどありませんでした。Windowsに焦点を当てたプログラミングの本はどれもありません（私はPetzoldの好きな思い出があります）。強力なシェルがどれほど便利かを理解したのは、Linuxの使用とプログラミングを始めてからです。Windowsがリリースされたとき、古いものを使う必要がなかったので、とてもエキサイティングだったのを覚えていますcommand.comもう。最終的に、TSRを必要とせずに、複数のフォントと複数のプログラムを同時に実行できるきれいなインターフェイスができました ...

Windowsで始めたプログラマーのほとんどは、強力なシェルの経験がないため、Windows用のシェルを実装する緊急の必要性を感じないと思います。Linuxで作業し、シェルを評価し、Linuxで作業することを好むプログラマーは、Windows向けの環境を実装するのに慣れていない環境で作業することに時間を費やす傾向はありません。別の質問で）シェル自体とともに必要なすべてのCLIツールも実装する必要があります。

Linuxの人気の高まりは、おそらく、Microsoftが最終的に適切なシェルを導入した主な理由です。Windowsが重要なツールを欠いていることは、シェルが有用であることをますます認識するようになりました。

場合あなたが「まともな」Unixシェルを検討し、その後、何十年もの間、「まとも」をされているWindowsのための少なくとも1つのシェルが存在しています。ハミルトンCシェルはかなり近いUnixのCシェル（CシェルはUnix上で、特に巨大な市場への浸透がなかったことに注意してくださいが）にあります。かなりの数の人々がかなり長い間JPSoftのさまざまなシェル（4DOS、4NT、現在はTake Commandと呼ばれています）を使用しています-名前から推測できるように、4DOSはMS-DOS時代に遡ります。

15年ほど前にMicrosoftによって配布されたシェルに固執する場合、Windows NTリソースキットには、PD Kornシェル^1の NTポートと、かなりの数のUnix系ユーティリティが含まれていました。おそらく、修正せずに多くのシェルスクリプトを実行するのに十分ではありませんでしたが、かなりの量の使用、特にかなりのインタラクティブな作業を処理するには十分でした。

¹正直なところ、それがその正確なシェルのポートであるか、まったく同じようなものであることはわかりません。 。

Windowsには、スクリプトには向かない設計機能があります。これは、グラフィカルインターフェイスを主要な動作モードにした結果です。多くのツールには、機能的なコマンドラインインターフェイスがありません。適切なコマンドラインインターフェイスがないと、適切なシェルを生成することは非常に困難です。

多くの場合、Windowsでスクリプトを作成する必要がある場合、アプリケーションウィンドウのさまざまな場所でマウスクリックとキーストロークをシミュレートする必要があります。結果のスクリプトは非常に壊れやすい可能性があります。関連するジオメトリがすぐに利用できないため、コマンド言語でスクリプトを記述する場所を説明するのは簡単な作業ではありません。

Windowsには、初期バージョンでは機能的なパイピングメカニズムもありませんでした。記載されているとおり、最初のプロセスが実行され、その出力は一時ファイルに保存されます。そのファイルは、次のコマンドへの入力として使用されます。これはディスクを集中的に使用する可能性があり、十分な一時スペースが利用できない場合は失敗します。Unixパイプはメモリ内のデータを渡し、遅延を最小限に抑える方法でプロセスをスケジュールします。

1993年に発売されたWindows NTは、MSによって以前はUnixサーバーが占有していたスペースへの移動であり、当時はPOSIXの互換性と移植性について大きな問題がありました。しかし、それはまったく役に立たなかった-その代わり、ユーザーはより良いハードウェアを使用するデスクトップ群衆であり（32MBのRAMを備えた486dx 50MHzがトップエンドに近かった時代でした）、より良いOSを望んでいました。しかし、彼らは貝に興味がなかったので、すべてが滑りました。この市場をクラックするための2番目の重大な試みであったWindows Server 2000の頃には、管理者はシェルスクリプトが大好きであるため、MSがシェル側で弱いことに気付いていたと思いますが、それでもかゆみを掻くには時間がかかりました。