PowerShellは、WindowsでCygwin Shellを置き換える準備ができていますか？
PowerShellを学ぶべきか、それとも Cygwin /Perlスクリプト/ Unix Shellスクリプトなどに固執するべきかを議論しています。
PowerShellの利点は、Cygwinを持たないチームメイトがスクリプトをより簡単に使用できることです。しかし、私が本当にそんなに多くの汎用スクリプトを書いているのか、それとも人々がそれを使うのかさえわかりません。
Unixスクリプティングは非常に強力ですが、PowerShellは切り替えを保証するのに十分近いのでしょうか？
PowerShellで探している特定のもの（または同等のもの）の一部を次に示します。
ツールは単なるツールです。
彼らは助けても助けなくても。
助けが必要かどうか。
Unixを知っていて、それらのツールがWindowsで必要なことをしているなら、あなたは幸せな人であり、PowerShellを学ぶ必要はありません（探索したい場合を除く）。
私の当初の意図は、一連のUnixツールをWindowsに組み込み、それを実行することでした（チームの多くの人々はUnixの深いバックグラウンドを持ち、そのコミュニティに敬意を払っています）。本当に役立ちます。その理由は、awk/grep/sedがCOM、WMI、ADSI、レジストリ、証明書ストアなどに対して機能しないためです。言い換えると、UNIXはテキストファイルを中心に自己調整されたエコシステム全体です。そのため、テキスト処理ツールは効果的な管理ツールです。 Windowsは、APIとオブジェクトを中心に自己調整されたまったく異なるエコシステムです。それが、PowerShellを発明した理由です。
あなたが見つけるだろうと思うことは、テキスト処理がWindowsであなたが望むものをあなたに届けない場合がたくさんあるということです。その時点で、PowerShellを取得する必要があります。注-それは、すべてまたは何も契約ではありません。 PowerShell内で、Unixツールを呼び出すことができます（そして、それらのテキストプロセスまたはPowerShellのテキスト処理を使用します）。また、UnixツールからPowerShellを呼び出してテキストを取得することもできます。
繰り返しますが、ここには宗教はありません。私たちの焦点は、成功するために必要なツールを提供することです。それが私たちがフィードバックにとても情熱を傾けている理由です。私たちが仕事のどこに落ちているのか、あなたが必要なツールを持っていない場所を教えてください。私たちはそれをリストに載せてそこに行きます。正直なところ、私たちは30年の穴から自分を掘り出しているので、しばらく時間がかかります。つまり、 Windows Server 2008 /R2のベータ版および/またはサーバー製品のベータ版を選択すると、その穴がすぐに埋められることにショックを受けると思います。
使用に関しては、これまでに350万件以上のダウンロードがありました。オプションのコンポーネントとして含まれており、ダウンロードする必要がないため、Windows Server 2008で使用する人は含まれません。 V2は、Windowsのすべてのバージョンで出荷されます。オプションコンポーネントであるサーバーコアを除くすべてのエディションでデフォルトでオンになります。 Windows 7/Windows Server 2008 R2の出荷後まもなく、すべてのプラットフォームXP以上でV2を利用できるようにします。つまり、学習への投資は非常に多くのマシン/環境に適用されます。
最後のコメント。 PowerShellを学習し始めたら、あなたはかなり幸せになると思います。デザインの多くはUnixの背景に大きく影響されているので、私たちはかなり異なっていますが、すぐに理解できます（Unixではないことを理解してから:-)）。学習のための予算が非常に限られていることを知っています。だからこそ、私たちは一貫性について非常にハードコアです。あなたは何かを学び、それを何度も何度も使います。
実験！楽しい！エンゲージ！
grep
Select-Stringコマンドレットと-match演算子は正規表現で機能します。また、より高度な機能のために.NETの正規表現サポートを直接利用することもできます。
ソート
Sort-Objectはより強力です（* nixのsortを覚えているよりも）。任意の式でマルチレベルのソートを許可します。ここでは、PowerShellの基本型のメンテナンスが役立ちます。例えばDateTimeプロパティは、DateTimeとして並べ替えられます。並べ替え可能な形式にフォーマットする必要はありません。
ユニック
Select-Object -Unique
Perl（PowerShellはPerlの機能にどの程度近づいていますか？）
Perlのドメイン固有のサポートライブラリの広さの点では、まだ（まだ）近づいていません。
一般的なプログラミングの場合、PowerShellは確かにまとまりがあり、一貫性があり、拡張が容易です。テキスト変更の1つのギャップは、Perlの..演算子に相当するものです。
AWK
AWKを使用してから十分に長いので（後でPerlを使用したので18年以上必要です）、実際にコメントすることはできません。
sed
[上記を参照]
ファイル（ファイル情報を提供するコマンド）
ここでのPowerShellの強みは、ファイルシステムオブジェクトでできることではありません（そして、ここでdirが適切にFileInfoまたはFolderInfoオブジェクトを返します）、それがプロバイダーモデル全体です。
レジストリ、証明書ストア、SQL Server、Internet ExplorerのRSSキャッシュなどを、ファイルシステムと同じコマンドレットでナビゲート可能なオブジェクトスペースとして扱うことができます。
PowerShellは間違いなくWindows上で前進する方法です。マイクロソフトは、将来の非ホーム製品の要件の一部にしました。したがって、Exchangeでの豊富なサポート、SQL Serverでのサポート。これは拡大するだけです。
この最近の例は、TFS PowerToysです。多くのTFSクライアント操作は、毎回tf.exeを起動することなく行われ（新しいTFSサーバー接続などが必要）、データをさらに処理するのが非常に簡単です。また、TF.exeのチームエクスプローラーで公開されているよりも詳細なTFSクライアントAPI全体への幅広いアクセスを許可します。
1997年から2010年のWindowsエンタープライズ開発に焦点を当てたキャリアとして、明白な答えは、以前に挙げたすべての正当な理由によるPowerShellです（たとえば、Microsoftのエンタープライズ戦略の一部であり、Windows/COM/.NETとうまく統合できます）。ファイルの代わりにオブジェクトを使用すると、「リッチな」コーディングモデルが提供されます）。そのため、私はここ2年ほどPowerShellを使用および宣伝しており、「ビルオブワード」に従っているという明確な信念を持っていました。
しかし、プラグマティストとして、PowerShellがこれほどすばらしい答えであるかどうかはわかりません。優れたWindowsツールであり、Windowコマンドラインである歴史的な穴を埋めるために非常に必要なステップを提供しますが、私たち全員がコンシューマコンピューティングスリップに対するマイクロソフトのグリップを見て、MicrosoftがOSを維持するために大規模な戦いをする可能性がますます高まっているようです将来の企業にとって重要です。
実際、作業が異種環境でますます増えていることを考えると、現時点ではBashスクリプトを使用する方がはるかに便利であることがわかります。Linux、Solaris、およびMac OS Xで動作するだけでなく、 WindowsでのCygwinのヘルプ。
したがって、OSの未来は独占ではなくコモディティ化されているという信念に賛成するなら、可能であればプロプライエタリなツールから遠ざかるアジャイル開発ツール戦略を選ぶことは理にかなっているようです。しかし、あなたの未来がRedmondだけに支配されているのを見るなら、PowerShellに行きましょう。
スクリプトの自動化にPowerShellを少し使用しました。環境がUnixシェルよりもずっと考え抜かれているように思えるのは非常に素晴らしいことですが、実際には、テキストストリームの代わりにオブジェクトを使用する方がはるかに不格好であり、過去30年がまだ不足しています。
Cygwinは、Windowsホストに最適なスクリプト環境です。それは確かに物事を成し遂げるという点で代替案を打ち負かします。
ここには多くの素晴らしい答えがあります、そして、ここに私の見解があります。 PowerShellの準備ができたら...例：
grep = " Select-String -Pattern "
sort = "Sort-Object"
uniq = " Get-Unique "
ファイル= " Get-Item "
cat = " Get-Content "
Perl/AWK/Sedはコマンドではありませんが、ユーティリティは比較が難しいため、PowerShellでほとんどすべてを実行できます。
PowerShellを少しでも真剣に使用し始めたのはごく最近のことです。過去7年間、私はほぼ独占的にWindowsベースの環境で働いてきましたが、私はUnixのバックグラウンドから来ており、Windowsでのインタラクションエクスペリエンスを「Unix-fy」しようと常に試みています。控えめに言ってもイライラする。
PowerShellを Bash 、 tcsh 、または zsh のようなものと比較するのは公平です。grep、sed、awk、findなどは、厳密に言えば、シェルの一部ではありません。ただし、常にUnix環境の一部になります。つまり、 Select-String のようなPowerShellコマンドには、grepおよびisと非常によく似た機能があります= PowerShellのコアモジュールとしてバンドルされているため、行が少しぼやけている場合があります。
重要なことはcultureであり、それぞれのツールセットがそれぞれの文化を具体化するという事実です。
- Unixはファイルベース、（一般的にはUnicode以外）テキストベース文化です。構成ファイルは、ほぼ排他的にtextファイルです。一方、Windowsは、構成形式に関して常にはるかに構造化されています。構成は、一般に、管理に専用のツールを必要とする独自のデータベース（Windowsレジストリなど）に保持されます。
Unix管理（および長年の開発）インターフェイスは、伝統的にコマンドラインと仮想端末でした。 WindowsはGUIとして始まり、管理機能はごく最近exclusively GUIベースから離れ始めました。コマンドラインでのUnixエクスペリエンスは、PowerShellでの重要なリードを考えると、よりリッチで成熟したものになると期待できます。私の経験はこれに匹敵します。これに関して、私の経験では：
Unixの管理経験は、最小限のキーストロークで簡単にできるようになっています。これはおそらく、遅い9600ボーダイヤルアップ接続でサーバーを管理しなければならないという歴史的な状況の結果です。 PowerShellにはエイリアスがあり、かなり冗長なVerb-Noun標準を回避するのに大いに役立ちますが、それらのエイリアスを知ることは少しです痛み（誰かが
alias | where {$_.ResolvedCommandName -eq "<command>"}より良いことを知っていますか？）。履歴を操作できる豊富な方法の例：
iptablesコマンドは、多くの場合長い時間を要します。Bashしたがって、次のようなiptablesルールを挿入します。iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT別のカメラ（ "
camera-2"）の2回目は、次を発行する場合です。!!:s/-1-/-2-/:s/50/51つまり、「前のコマンドを実行しますが、
-1-を-2-に、50を51に置き換えます。Unixエクスペリエンスは、タッチタイピスト向けに最適化されています。 「ホーム」ポジションを離れることなく、ほとんどすべてを行うことができます。たとえば、Bashで、Emacsキーバインディング（はい、 Bashはviバインディングもサポートしています）、履歴の循環は以下を使用して行われます Ctrl-P そして Ctrl-N 行の先頭と末尾に移動しながら、を使用して行われます Ctrl-A そして Ctrl-E それぞれ...そして、それは間違いなくそこで終わりません。 PowerShellコンソールで、ホームポジションから移動せずに最も簡単なナビゲーションを試しても、問題が発生します。
- Unixの多目的ページング（a less ）のような単純なものは、PowerShellですぐに使用できるようではなく、少しイライラし、豊富なエディターエクスペリエンスは存在しませんどちらか。もちろん、これらのギャップを埋めるサードパーティのツールをいつでもダウンロードできますが、これらがすべてのUnixのフレーバーのように「そこに」あるだけでいいのは確かです。
少なくともシステムAPIの観点から見ると、Windowsカルチャは、主にサポートフレームワーク、つまりCOMおよび。NET、両方とも高度に構造化され、オブジェクトベースです。一方、Unix APIへのアクセスは、従来、ファイルインターフェイス（
/devおよび/proc）または（オブジェクト指向ではない）Cスタイルライブラリ呼び出しを介して行われていました。その場合、スクリプト作成のエクスペリエンスがそれぞれのOSパラダイムと一致することは驚くことではありません。 PowerShellは本質的に構造化され（すべてがオブジェクト）、Bash-and-friendsファイルベースです。 PowerShellプログラマーが自由に使用できる構造化APIは膨大です（基本的に既存の標準の COM および.NETインターフェイスの広大さに一致します）。
要するに、PowerShellのスクリプト機能はBashよりも間違いなく強力ですが（特に.NETの可用性を考慮する場合 BCL ）、interactiveエクスペリエンスは、特に多くのUnixヘッドがそうであるように、完全にキーボード駆動のコンソールベースの観点から来ている場合は、著しく弱くなっています。
私は決して経験豊富なPowerShellユーザーではありませんが、少し触れただけで、非常に感銘を受けました。組み込みのコマンドレットを連結して、Unixプロンプトでできることはほぼ何でも実行できます。CSV、HTMLテーブルへのエクスポート、およびより詳細なsys-adminタイプジョブ。また、sedのようなものが本当に必要な場合は、常に nixUtils または GnuWin32 があり、Powershellとかなり簡単に統合できます。
しかし、長年のUnixユーザーとして、コマンドの命名スキームに慣れるのに少し苦労しました。NETをもっと知っていれば、その恩恵を受けることは間違いありませんでした。
したがって、本質的には、Windowsのみが問題にならなければ、学ぶ価値は十分にあると言います。
シェルスクリプトが好きなら、PowerShellが大好きです！
Microsoftコマンドシェルのガイドツアー（Ars Technica）から開始します。
PowerShellをCygwin/Perl/Shellの組み合わせと比較する場合、PowerShellはその組み合わせの「シェル」部分のみを表すことに注意してください。
ただし、cmd.exeまたはCygwinから実行するのと同じように、PowerShellからコマンドを呼び出すことができます。指定された関数をnot再実装しますが、Perlに匹敵するものではありません。
これは「単なる」シェルですが、プログラミングが容易になり、.Netユニバースへの快適なインターフェイスを提供します。
また、PowerShellにはWinXP、Srv2003以降が必要であり、ITインフラストラクチャによっては問題が発生する可能性があることに注意してください。
更新：
私の答えがどのような哲学的議論に火をつけるのか、私には全く分かりませんでした。
「PowerShellをCygwinおよびPerlおよびbashと比較する」という質問のコンテキストで回答を投稿しました。
PowerShellは、組み込みコマンド、コマンドレット、ユーザー関数、外部コマンド（.exe、.bat、.cmd）の構文に違いがないため、シェルです。 .Netメソッドの呼び出しのみが、呼び出しに名前空間またはオブジェクトを追加することで異なります。
そのプログラム可能性は、PowerShell「言語」に固有のものからではなく、.Netフレームワークから派生しています。
PowerShellがWebサーバーで実行されるPowerShellスクリプトとしてBugzillaまたはMediaWikiが実装されるとすぐに、PowerShellは「スクリプト言語」であると思うと思います。
それまでは、 比較 をお楽しみください。
最近の実験により、PowerShellと.NET呼び出しの詳細に導かれたので、CygwinとUnix ShellをPowerShell canに置き換えなければなりません。
Perlについては確信がありませんが、PowerShellとPerlはどちらもプログラミング言語として完全なチューリングであるため、Perlの置き換えにも賛成です。
PowerShellがCygwinおよび* nixの下の通常のBashの上にあることの1つは、サンドボックス化されたDLL呼び出しを実行し、直接API呼び出し、WMIメソッド、さらにはCOMオブジェクトを介してオペレーティングシステムを操作する能力です。コードを使用してInternet Explorerを起動し、表示されたドキュメントで必要な処理を実行して、Webサーバーのバックエンドを効果的にエミュレートしますか？
SQLサーバーやその他のデータプロバイダーからデータを収集し、それらを解析して、CSV、メールメッセージ、テキスト、および実際には既存および存在しないあらゆるファイル形式としてエクスポートするのはどうですか？ （もちろん、受信したデータから有効なファイルを作成する適切なスキルがあれば、CSVはすぐに利用できます）。
また、署名されたコマンドレットとスクリプト、グループポリシー、および実行ポリシーを介して利用できる追加のセキュリティがあり、管理者として実行した場合でも悪意のあるコードがシステムで実行されるのを防ぎます。
どのコマンドが実装されているかについて-リチャードによる答えは、それらの機能と、それらの機能を既にエミュレートするPowerShellの機能をリストしています。
PowerShellが切り替えを保証するのに強いかどうか-これは個人的な好みの問題ですが、ますます多くのWindowsサービスがそれらを制御するPowerShellコマンドレットを提供しているので、これらのサービスが存在する状態でPowerShellを使用しないことは障害と見なされます。 （Hyper-Vサーバーはこのような主要なサービスであり、GUIよりもPowerShellコマンドレットでより多くの機能を提供します！）
おそらくこの答えは5年遅れですが、それでも、誰かがWindowsで管理タスクやさまざまなものの一般的なスクリプトを実行する場合、PowerShellを目的に利用してみてください。
TL; DR-私はWindowsやPowerShellを嫌いではありません。ただ、できませんdo WindowsでもPowerShellでも。
個人的には、PowerShellのせいで圧倒的だと感じています。
- ディレクトリパスのタブ補完は複合的ではなく、ユーザーが名前を補完するたびにパス区切り文字を入力する必要があります。
- 私はまだ、ウィンドウにはパスやパスの概念さえも含まれていないように感じています。アクセス可能なユーザーホームインジケータはありません
~/@environment://somejibberish/%user_home% NTFSはいまだに混乱しており、常にそうであるように思われます。
cmd-esqueインターフェイス、dinosaur cmd.exeはPowerShellで引き続き表示されます。
edit->markが情報をコピーする唯一の方法であり、表示可能なターミナルスペースの長方形ブロックの形でのみコピーします。また、edit->pasteは、文字列を端末に貼り付ける唯一の方法です。それを青く塗ってもそれ以上魅力的ではありません。しかし、MS開発者が色の好みを持っていることは気にしません。
ウィンドウは常に画面の左上隅で開きます。垂直タスクバーを使用する人にとっては、これは非常に迷惑です。特に、ウィンドウタスクバーがコピー/貼り付け機能にアクセスできるウィンドウの唯一の隅をカバーすることを考えると。
私は、ウィンドウに含まれているツールの理由についてあまり話すことができません。オープンソースの無料ライセンスのCLIツールのセットがすべてあり、PowerShellには、私の知る限り、どれもがっかりするものではありません。
- PowerShell
wgetは、GNU wgetとは一見比較できない引数を取ります。 - PowerShell POSIXはBash互換ではありません。特に
&&演算子は処理されないため、次のものではない最も単純な条件付きコマンドが作成されます。
私は人を知りません。試してみました、本当にやりました。私は今度、それを次に開くときにそれが役に立たなくなることを期待してショットを与えようとします。 PowerShellでは何もできません。また、GNUツールをWindowsに導入するための実際のプロジェクトではほとんど何もできません。
MySysGitは、いくつかのGNUツールを備えた恐竜cmd.exeプロンプトを提供しますが、それでも非常に圧倒的ですが、最終的にはパス補完が機能します。また、GitコマンドはGit Bashで実行されます。
MySysGitのMinttyは、mysysgitの環境上でCygwinインターフェースを提供し、物をコピーして貼り付けます（選択してコピー（マウス）、 shift+ins 貼り付けるには、どのようにモダン...）。ただし、git PushのようなものはMinttyで壊れています。
私は暴言するつもりはありませんが、Cygwinのようなツールを与えられたとしても、Windowsでのコマンドラインの操作性に大きな問題があります。
追伸：PowerShellでcanを実行したからといって、それをsableにしたわけではありません。使いやすさは能力よりも深く、製品を消費者として使用しようとするとき、私は焦点を当てる傾向があります。
PowerShellのコマンドレットは非常に優れており、確実に動作します。私はJava/C＃開発者であるため、オブジェクト指向性は非常に魅力的ですが、完全なセットではありません。オブジェクト指向なので、POSIXツールセットの多くの テキストストリーム 成熟度（awkおよびsedをいくつか挙げれば）を見逃しています。
OOテクニックを愛し、POSIXツールの成熟度を愛するというジレンマに対して私が見つけた最良の答えは、両方を使用することです！ PowerShellの優れた点の1つは、オブジェクトを標準ストリームにパイプする優れたジョブを行うことです。 PowerShellは、デフォルトでオブジェクトパイプラインを使用してオブジェクトを転送します。これらは標準ストリームではありません（標準出力、標準エラー、標準入力）。 PowerShellは、オブジェクトパイプラインを持たない標準プロセスに出力を渡す必要がある場合、最初にオブジェクトをテキストストリームに変換します。 PowerShellは非常に優れているため、POSIXツールをホストするのに最適な場所です。
最適なPOSIXツールセットは GnuWin32 です。インストールには5秒以上かかりますが、トラブルに見合うだけの価値があり、私が知る限り、指定したディレクトリにファイルをコピーする以外はシステム（レジストリ、c:\windows\*フォルダなど）を変更しません。ツールを共有ディレクトリに配置すると、多くの人が同時にツールにアクセスできるため、これは非常に便利です。
GnuWin32インストール手順
exe （ SourceForgeサイト から）をダウンロードして実行し、適切なディレクトリを指定します（C:\binを使用します）。そこにGetGnuWin32ディレクトリを作成し、そこでdownload.batを実行し、その後install.bat（パラメーターなし）を実行します。その後、C:\bin\GetGnuWin32\gnuwin32\binディレクトリが存在します。そのディレクトリをパスに追加すれば、準備は完了です。
両方を使用しないのはなぜですか？ Perlなどのその他の解釈されたスクリプトと同様に、CygwinでPowerShellスクリプトを呼び出します。
Cygwinでpowershell.exeを呼び出すBashラッパーの https://bitbucket.org/jbianchi/powershell を作成したので、これを十分に行います。 powershell.exe .ps1スクリプトの最初の行として Shebang として使用できます（PowerShellはコメントとして「＃」も使用するため）。 https://bitbucket.org/jbianchi/powershell/wiki/Home を参照してください
少なくともまだまだ、PowerShellが本当に離陸したとは見ていません。そのため、チームの他のメンバーが既に知っている場合を除き、学習する努力に値しないかもしれません。
あなたの苦境のために、他の人が遅れをとることができるスクリプト言語、あなたが言及したようなPerl、またはRubyやPythonのような他の人の方が良いかもしれません。
その多くは、あなたが何をする必要があるかにかかっていると思います。個人的にPythonを自分の個人的なスクリプトに使用していましたが、何かを書き始めたとき、それを決して渡すことができないことを知っています。
2、3行では、CygwinとPowerShellは異なるツールですが、Cygwinをインストールしている場合は、PowerShellセッション内でCygwin実行可能ファイルを実行できます。 PowerShellに慣れてきたので、grep、sort、awkなどはもう使用していません。PowerShellには組み込みの代替機能がほとんどありますが、そうでない場合はコマンドレットを見つけることができます。
私が使用していると思う主なツールはssh.exeですが、PowerShellセッション内にあります。
それは素晴らしく機能します。
PowerShellは非常に強力で、Unixシェルの標準ビルトインよりも強力です（ただし、通常、サブプログラムにシェルアウトされる機能の多くが含まれているためです）。また、IronPython、IronRuby、PerlNetなどを含む任意の.NET言語でアプレットを記述できること、またはすべての追加機能を無視してPowerShellからcygwinコマンドを呼び出すことができ、bash、korn、または何でも...
PowerShellプログラミングは努力する価値がないことがわかりました。
Unixでのシェルスクリプトの使用には数年の経験がありますが、PowerShellで多くのことを行うことは非常に難しいことがわかりました。
多くの機能では、Windows管理インターフェイスに問い合わせて、SQLに似たコマンドを発行して必要な情報を取得する必要があるようです。
たとえば、ディレクトリツリーから特定の接尾辞を持つすべてのファイルを削除するスクリプトを作成したかったです。Unixでは、これは簡単です...
find . -name \*.xyz -exec rm {} \;
Scripting.FileSystemObjectとWScript.Shellを数時間探し回って「SELECT * FROM Win32_ShortcutFile WHERE Drive = '」＆drive＆ "' AND Path = '"＆searchFolder＆ "'"を発行すると、ようやくあきらめて、WindowsエクスプローラーのSearchコマンドを受け入れて、手動で実行します。おそらく、私が望んでいたことを行う方法はいくつかありますが、明らかなものは何も見られず、MSDNサイトのすべての例は価値のないほど些細なものでした。
編集もちろん、これを書いてすぐに、私はもう少し調べて、欠けているものを見つけました：remove-itemの-recurseオプションコマンドに問題があります（get-help remove-item -detailedを使用すると表示されます）。
私は「remove-item -filter '* .xyz' -recurse」を試していましたが、機能していなかったため、あきらめました。
get-childitem -filter '*.xyz' -recurse | remove-itemを使用する必要があることがわかりました