端末コンソールがまだ使用されているのはなぜですか？
誰もが知っているように、ターミナルコンソールはグラフィカルインターフェイスの機会がなかった時代から来ているため、それらの必要性は明白です。
グラフィカルインターフェイスの出現により、多くの新しいアプリケーションが可能になりましたが、それらのほとんどのテキストのみのプログラムも、対応するグラフィカルアプリケーションに移行しました。
ただし、端末は永続し、それだけではありません。これを機能として通常言及するサービスがあります。手持ちの最も一般的な例は、ホスティングサービスです。
もちろん、これはボタンをクリックしてファイルを編集するの代わりに、ユーザーは数百または数千のコマンドを記憶してから次のようなことを行う必要があることを意味します
Sudo nano /www/var/html/myfile.html
グラフィカルカーソルで移動して何かを編集し、次にctrl+XおよびYをクリックし、保存先のファイルを選択します。言い換えれば、最高の状態での使いやすさ（最悪）
同じことが他の多くのコマンドでも見られ、上記は単なる例です。非常に簡単な方法：WordPress 1-クリックインストールvsインストールWordPressコマンドラインから
だから私の質問は：端末がまだ使用されている論理的な理由はありますか（基本的に、技術的な理由、またはセキュリティ上の理由）またはこれは単に文化的なものですそのすべての問題にもかかわらずいくつかの方法？
編集：別のケースを追加：git。私はgitのGUIがあることを知っており、それらは端末のgitよりもはるかにユーザーフレンドリーです。では、なぜ端末バージョンが存在するのですか？
UXの観点から見ると、ターミナルコンソールにはGUIに比べていくつかの重要な利点があります。これらの利点がエンドユーザーに関係することはめったにありません。そのため、CLIはほとんどテクニカルユーザーと「パワーユーザー」だけが最近使用しているのです。
ターミナルで行われることは簡単に繰り返し可能です。
なんらかの目的で5台のコンピューターを構成する必要があるとします。この少数の場合、すべてを構成するための自動化ソリューションを作成することはおそらく価値がありません。それぞれの設定を微調整するだけです。
端末では、コマンドをコピーして貼り付けるのは簡単です。 GUIでは、構成の保存場所に慣れているかもしれませんが、それでもかなりのクリックが残る場合があります。間違いはよりありそうです。
これは、ドキュメントやテクニカルヘルプにも関連しています。ターミナルコンソールにコピーアンドペーストする4行を提供すると、さまざまな管理ツールをクリックする方法の説明の2、3の段落が置き換えられる場合があります（特に、GUIの指示はいくつかのインターフェイスの1つにのみ最適な場合があるため、以下の「GUIインターフェイスは無数にある」を参照してください） ）。
追跡/監査がより簡単に
コマンドラインインターフェイス（CLI）は、実行した内容の記録を保持し、簡単に抽出して保持できます。何かがうまくいかない場合、上司は「あなたはそれを正確に実行しましたか？」あなたがしたことを証明する証拠を持つことができます。間違えたとしても、それをより簡単に見て、学ぶことができます。
スクリプト作成/自動化は、コマンドの入力とほぼ同じくらい簡単です
マウスを使用してGUIでファイルを開く方法は誰もが知っています。それを自動的に行う方法を知っている人ははるかに少ない。 CLIを使用すると、手動で入力するのと同じくらい簡単にタスクを自動化できます。
技術的制約は、CLIを魅力的なものにすることができます
GUIボックスにリモートでログインするにはかなりの帯域幅が必要であり、レイテンシ（接続の遅延）によってエクスペリエンスがイライラすることがあります。 CLIリモートログインは、少しのテキストを送受信するだけなので、必要な帯域幅ははるかに低くなります。また、入力時に、アイコンの上にマウスを移動させようとするよりも、待ち時間の処理がはるかに簡単になります。
CLIは入出力に使用できます
一部の人はこれを The Age of the API と呼び、システムはシステムの上に構築されています。 CLIは同様の相互運用性を可能にします。 Gitに関する質問の例では、欠陥追跡システムなど、別の「エンタープライズシステム」をフックすることが可能です。
SOAPまたはRest APIと比較しても、CLIコマンドは簡単に開発およびテストできます。
標準のシェルはほんのわずかです。 GUIインターフェースは無数
いくつかの異なるWebホスティングサービスのGUI管理インターフェイスにログインすると、おそらくすべてが異なっていることがわかります。周りをくまなく調べて、すべてがどこにあるかを把握することは難しいではありませんが、時間がかかります。来年、ホストはソリューションをアップグレードした可能性があり、すべてがわずかに異なる場所にあります。
そのホスティングサービスはおそらく同じCLIを使用します。新しいバージョンは古いバージョンと下位互換性があります。 Bash、PowerShell、またはシステム上のCLIに精通しているユーザーは、その特定のGUIに慣れる（または再習熟する）ために費やされる時間を省くことができます。
つまり、コマンドラインはlanguage;言語は表現力を与えます。
使用するテキストインターフェースの例：Google Search。クエリをテキストとしてGoogleに入力できず、選択肢メニュー（以前のYahoo Webディレクトリなど）から必要なドキュメントを選択する必要がある場合を想像してみてください。
ユーザビリティの専門家であり、ユーザーエクスペリエンスの研究者でもあるJakob Nielsenが、ドンゲントナーに "The Anti-Mac Interface" と呼ばれる記事を書きました。
Gentner、D。、およびNielsen、J .:アンチMacインターフェイス、ACMの通信39、8（1996年8月）、70–82
その中で、著者は「GUI」インターフェースに入る多くの原則の欠陥を指摘しています。例えば、
参照してください
シーアンドポイントの原則は、ユーザーが画面上で見ることができるオブジェクトをポイントすることによってコンピューターと対話することを述べています。まるで100万年の進化を捨てて、表現力豊かな言語で施設を失い、身近な環境にあるオブジェクトを指すようになってしまったかのようです。マウスボタンと修飾キーは、いくつかの異なるうなり声と同等の語彙を提供します。言語の力をすべて失い、すぐに表示されないオブジェクトについて話すことができなくなりました（1週間以上経過したすべてのファイル）、まだ存在しないオブジェクト（上司からの今後のメッセージ）、または不明なオブジェクト（ボストンのレストランへのガイド）。
彼らは続けます：
言語がまったくわからない国で食べ物を注文したい場合は、台所に行ってシーポイントインターフェースを使用する必要があります。言語を少し理解すれば、メニューをポイントして、ダイニングルームからディナーを選択できます。しかし、言語によって、ウェイターやシェフと何を食べたいかを正確に話し合うことができます。
記事全体 は読む価値があるかもしれませんが、質問に対する多くの回答が含まれています。
したがって、言語（コマンドライン）を使用すると、より豊かな体験をすることができます。しかし、あなたが言うように、これは言語がbetterであることを意味しません。
コマンドラインインターフェイスを使用することは、マクドナルドのソウル支店で食べ物を注文するためだけに完全な韓国語を学ぶ必要があるようなものです。メニューベースのインターフェースを使用することは、必要な食べ物を指して頭をうなずいてうなずくことができるようなものです。それは、学習曲線なしで同じ情報を伝えます。
-Joel Spolsky、プログラマ向けのユーザーインターフェイス設計、p。 76
GUIまたはテキストインターフェイスのどちらが優れていますか？テキストインターフェイスは、より表現力があり強力な見返りとして、学習により多くの時間を必要とします。あなたにとってそれが価値があるかどうかは、その環境でどれくらい長く生きるつもりか、そしてどれだけ豊かな経験をしたいかによります。
現代のアプリケーションのGUIは一般に、学習を容易にするために適切に設計されていますが、一方では学習の容易さと、他方では使いやすさ、パワー、および柔軟性との間でしばしばトレードオフがあります。人々が持ち運んでいる大きなメニューの言葉やアイコンを指すことでコミュニケーションをとったため、言語が習得しやすい社会を想像することができますが、人間はその代わりに豊かで複雑な言語の習得に長年投資することを選択しました。
「コマンドライン言語」（Unixのような環境でのBashのようなシェル、またはおそらくWindowsの同等の機能）の学習は、学習者に一度に多数の潜在的な経験を提供することに注意してください。非常に多くの人がこの学習に投資することを選択しており、私はそれが見事に報われたと言えるでしょう。
最後に、サービス（ホスティングサービスなど）がテキストインターフェイスを機能としてアドバタイズする理由に関する質問に答えるには、外国語で英語を話すことがほとんどなく、ジェスチャーなどに苦労していて、サインオンが表示されている国を想像してください。 「ここでは英語を話します」と言う施設。 （同様に、あなたが住んでいる場所に応じて、「Se hablaespañol」という標識を見たかもしれません。）あなたが言及する広告は似ています：コマンドライン「言語」に習熟している人にとって、これは彼らがすでに考え抜かれて実装されているグラフィカルインターフェイスに限定されることなく、表現力豊かな豊かな経験を期待できます。
ロングバージョン
答えは基本的に質問自体に含まれています：
ユーザーは数百または数千のコマンドを記憶する必要がある
数百または数千のボタンに切り替えても、使いやすさは向上しません（テキストコマンドラインよりもはるかに制限されます）。
端末ウィンドウで実行されるすべてのタスクをカバーするのに十分な汎用のGUIを構築しようとすると、GUIはユーザーの大部分のサブセットにとって、機能が非常に複雑か、または機能が制限されます。たとえば、例を挙げましょう。「ワンクリックインストール」は、デフォルトの設定が必要な場合に最適ですが、それ以外の場合は不十分です。端末で単一のファイルを編集するのは複雑に見えるかもしれませんが、端末ユーザーは特定の目的のために複数のテキストユーティリティをつなぎ合わせます。通常、コマンドラインでの作業は、ボタンをクリックして定義済みのタスクを実行するよりも、短い単一目的のプログラムを作成することとよく似ています。
コマンドラインからGUIに移動することでできるほとんどのタスクはすでに改善されています-nanoを使用したくない場合（またはviまたはemacsなど。）たとえば、GUIベースのテキストエディターを選択するのに不足はありません。 （すでにコマンドラインを使用していて、簡単な変更を加える必要があるだけの場合は、viと入力して、マウスに手を伸ばすことなくそのクイック編集を行うだけで十分です。）
しかし、名前が特定のパターンに一致する特定のディレクトリ内のすべてのファイルを見つけ、その中で検索と置換を実行し、元のファイルをtarballにラップして別のファイルにプッシュするようなGUIを書く人は誰もいません。サーバー-それはGUIが処理するためにめちゃくちゃ過剰な特定のタスクになるからです。しかし、そのような特定のことを行う必要がある場合、いくつかのUNIXユーティリティをパイプでつなぐのは簡単です。そして、それをシェルスクリプトにキャプチャして、毎週再び実行できるようにします。
開発者はそのようなのようなめちゃくちゃな仕様を常時実行する必要があります。端末は、この種のタスクに最も効率的で使いやすいUIです。
ショートバージョン
効率と柔軟性と引き換えに、コマンドラインは発見可能性とトレードオフします。
ユーザーは事前にコマンドを学習している必要があります。メニューやツールバーを探索してGUIのように見つけることはできません。しかし、いったん学習すると、これらのツールはすべてほんの一握りのキーストロークで、必要に応じて斬新な方法で組み合わせることができます（GUIでは、すべてのタスクを事前に設計者が検討する必要がありました）。
コメントに対するフォローアップ
この質問全体のコメントスレッドは、おしゃべりのために数回間引かれましたが、同じ点が増え続けているようですので、ここでそれらに対処したいと思います。
- あなたは本当に何千ものコマンドを必要としません、20または30が必要です。
ほんとだ！ちょっと。問題は、必要な20または30のコマンドが必ずしも次の人が必要とするコマンドと同じになるとは限らないことです。日常的に使用するコマンドのサブセットのみを含む簡略化されたGUIでは、他の人には十分ではありません。そして、あなたのためにも機能しません、あなたは最初の日、あなたは日常的ではない何かをする必要があります。
（第2に、これらの各コマンドのさまざまなコマンドラインオプションすべてと、それらを効果的にパイプする方法を説明すると、実際には、20または30を超える対話がサポートされる必要があります。パーソナライズされたGUI ...）
GUIは特定の目的に合わせて設計する必要があります。対照的に、コマンドラインは汎用です。必要な機能が組み込まれていない場合は、自分で追加できるため、すべての人にとってすべてのことが可能です。
- その例では、誰かがGUIを作成することのない、非常に具体的なタスクを誰かに与えました。
ほんとだ！私はその中にまっすぐ入りました、うん。例を変更して、少しめちゃくちゃに特定しすぎた（ただし、もっともらしい）ようにしました。
GUIラッパーは多くのコマンドラインタスクのために分離されており、確かに便利です（たとえば、コマンドラインでgitを使用するよりもgithub GUIで多くの時間を費やしています）-しかし、これらのそれぞれは、コマンドラインが使用される多くのタイプのタスク。 all、またはmost、コマンドラインタスク。 （または、まあ、git自体の場合も同様です。GUIフロントエンドが処理できないもののために、コマンドラインに戻る必要があることがよくあります。）
- 発見可能性（「コマンドラインはあなたが思っているよりも発見しやすい」/「GUIは思ったほど発見できない」）
ここでは、厳密な意味で「発見可能」という用語を使用しています。新規ユーザーは、プログラムを使用するだけでプログラムの使用方法を理解できます。つまり、十分な時間だけそれを試してみると、外部リソースに頼らずにそれがどのように機能するかを理解することができます。 （私は間違いなくではありませんそれがユーザーが何かを使用する方法を学ぶための唯一または最良の方法だと言っています;それはGUIが持つ潜在的な利点であることだけですCLI経由で）。
うまく設計されていないGUIインターフェイスは必ずしも発見を容易にするわけではないことを喜んで認めます。
コマンドラインが実際の程度で発見を容易にすることを示唆しているいくつかのコメント（一部は削除済み、一部はまだ最新）に同意しません。機能の使用方法を理解するためにmanページを読む必要がある場合、それは発見不可能です。それは学んでいます。これは素晴らしいことですが、別のことです。さまざまなツールのコマンドラインオプションには、1つのツールを学ぶことで他のツールを理解するのに役立つという主張をするのに十分な一貫性がないと思います。 CLIユーザーがまだ知らないツールの存在を発見するための合理的な方法はありません（いいえ、ls /usr/binはそれを完全には切りません。これは、「アルファベット順でマニュアルに索引を付ける」に似ています。）タブ補完などのヘルパーやショートカットはいくつかありますが、何かを学んだ後は、実際よりも覚えておくと便利です。そもそもそれを学ぶ方法。
だから私の質問は：論理的な理由はありますか
マウスを使用するよりも速く入力できます。
逸話：
過去の人生では、私はニッチ市場向けのソフトウェアに取り組む小さなチームの一員でした。これは90年代のことで、市場を支配するソフトウェアはコマンドラインツールでした。この人口統計は必ずしもテクノロジーに精通しているとは限らなかったため、GUIがあれば、はるかに学習しやすいソフトウェアを作成しました。
それは適度に成功しましたが、結局、業界のリーダーを倒すことはできませんでした。それらの一部は、それらが単に埋め込みオプションであったという事実のせいである可能性があり、それは常に現職を動揺させる課題です。しかし、私たちが他のソフトウェアから顧客を獲得できないことの大きな部分は、コマンドラインツールlikedで作業していた人々でした。彼らはコマンドを知っていて、それで速く、数回のキーストロークですべてを素早く行うことができました。
したがって、学習するのはかなり面倒なツールでしたが、一度学習すると、信じられないほど強力で高速なツールでした。
私に学んだ教訓は、GUIは端末/コマンドラインよりも優れていたり、劣っていたりしないということです。それらは単に異なります。特定のタスクについては、一方が他方より優れていることもありますが、一方が他方より優れているとは言い切れません。それはすべて異なります。
私は2つの主な理由で主張しますが、どちらも普遍的ではありません。しかし、どちらの理由も、コマンドラインで少なくともいくつかのことを行うことを好む非常に良い理由です。
- プログラマビリティ。標準に対してコードを作成する方が飛躍的に簡単ですIOプログラムでGUIを操作するよりも、またはそれぞれのマクロランナーのカスタム統合を作成するより自動化または統合するアプリケーション。
- 効率。編集したい場合
myfile.html、使用するファイルとエディタの名前をすでに知っています。多くの場合、あなたが考えていることをタイプする方がそれはあなたが考えていることを階層的なGUIの一連の調整されたマウスの動きに変換するよりも速いです-見つけるためにあなたのエディタ、そしてあなたのファイルを見つけること。 （GUIの傾向はミニコンソールを提供することでした。注目すべき点は、必要なプログラムの名前を入力するだけです...）
あなたの例では：
Sudo nano /www/var/html/myfile.html
既に知っている場合は編集する必要がありますmyfile.html管理者として、UI（コンソールと通常のエディター）に慣れている場合、これを入力するのに2〜3秒かかります。
Sudo nano /w <tab> v <tab> h <tab> m <tab> <enter>
私がすでに作業ディレクトリにいるとき、最初の1文字または2文字がわかっている場合、vimでファイルを開くのに約1秒かかります私が探しているファイル。
IDE-フルパスとファイル名がわかっている場合でも、ソリューションが既に読み込まれている場合よりも高速です。GUIの場合、アルファベット順の階層を視覚的にスキャンしてfindファイルに移動する必要があります。私にとっては、ファイル階層の大きさにもよりますが、おそらく5〜15秒です。
それは多くのようには聞こえませんが、それは多くのように感じます。また、1日あたり数百または数千のファイルとそれらのファイルの操作を行っている場合、ファイルあたりの追加の4〜14秒は顕著です。 （特に上司があなたをあなたのコマンドラインウィザードの相手と比較している場合...）
コマンドラインインターフェース（CLI）は、質問の意味を理解できるほど不便ではありません。同様に、ポイントアンドクリックインターフェイスは内部を隠し、複雑なコマンドを作成するのを難しくするため、悪いと主張することもできます。
まだ話せず、物事を指さしている小さな子供を想像してみましょう。はい、テーブルでパンや飲み物を頼むなど、いくつかのタスクが完了します。しかし、子供が話すことを学ぶと、彼らはめったに戻って指さすことに戻りません。これは、話すことがポイントアンドグラントよりも強力であることを示唆しています。しかし、今後はすべてを文字で置き換えることはしません。
現在、多くのグラフィカルユーザーインターフェイスは、子の例のようにポイントアンドクリックです。コマンドラインインターフェイスは、ソフトウェアと話すことにより近いです。または、話すことよりも少し厳しい友人にテキストメッセージを送ることをより適切に考えます。
理想的な世界では、CLIはUXに対する恐ろしいアンチテーゼではなく、GUIの補完物であると考えるでしょう。どちらかまたは両方である必要はありません。ちょうど異国の大人がポインティングに戻るように。タスクに適切なものを選択できるはずです。
いくつかの誤解
コマンドラインでは、何千ものコマンドを学習する必要があります。
それどころか、効果を上げるためには、通常、多くても12を知る必要があります。グラフィカルユーザーインターフェイスと同じように、自分が何をしているかを知る必要があります。多くのアプリケーションがインストールされている多くの場所では、同じ問題が発生します。プログラムXYZの名前を知っていて、それをGUIで見つけて起動しない限り、プログラムXYZを使用することはできません。
Nanoがテキストエディタであることを知ることは、メモ帳がエディタであることを知るのと同じくらい、明らかに思い出に残ることです。
コマンドラインを学ぶのは難しい
実際はそうではありませんが、通常は非常に単純です。ただし、ある程度上級のユーザーしか使用しないため、多くの場合、ユーザー向けに設計されています。これは、コンセプトが難しいという意味ではありません。カジュアルな使用を意図したものではありません。
コマンドラインはGUIよりも発見しにくい
GUIがある場合とそうでない場合があります。コマンドラインインターフェースは発見可能ですが、少なくとも良いものは発見可能です。同様に、すべてのGUIが非常に使いやすいとは限りません。実際、非常に悪いコマンドラインインターフェイスは、悪いGUIよりも優れています。コマンドラインは実行可能です。必要に応じて、不良コマンドラインを簡単にカプセル化できます。悪いGUIは悪いGUIです-それについてできることは多くありません。
GUIの方が使いやすい
彼らがするつもりだった簡単な仕事をするとき、それは本当です。しかし、ときどき単純なことをするのは簡単なことですが、GUIではそれができません。コマンドラインでは、通常これは問題ありません。他のコマンドを実行してください。
コマンドラインはUXが悪いですか？
それがひどく設計されている場合のみ！コマンドラインとコマンドは、GUIと同じように異なるパッケージで提供されます。それらのほとんどは、特にエレガントではありません。はい、ほとんどのGUIアプリケーションも不安定です。一部のコマンドラインアプリは、驚くほど優れたデザインを備え、優れたUXを提供しますが、他のアプリにはありません。
コマンドラインに本質的に悪いことは何もありません。実際、アプリケーションには、言うべきコマンドラインインターフェースがなかったため、悪いアプリケーションとして破棄しました。また、いくつかのアプリケーションは、それらのGUIとコマンドラインインターフェイスが優れているため、GUIが不安定な場合でも何年も使用しています。 YMMV。
[〜＃〜] ps [〜＃〜]：ループで何ができるかは驚くべきことです。手作業で何日も費やしていたことを、数秒で行うことができます。自分の時間を重視する場合は、コマンドラインを使用します。
まあ、私はほとんどすべての端末を使用していますが、画像編集などのいくつかのことをしています。その理由を、ユーザーエクスペリエンスに焦点を当てて説明したいと思います。
シェルはプログラム構成のための言語です
端末（およびシェル）は、コンピューターとの会話を可能にするものです。端末を使って物事を行うことはありません。私はそれを使用して、自分の意図をシステムに伝え、それを私に代行させます。
たとえば、シェルを使用すると、徐々に複雑なタスクを実行できます。手でできることは何でも、システムにそれ自体を行うように指示できます。
# report status of service
systemctl status mariadb
# do it on foo.com
ssh foo.com "systemctl status mariadb"
# do it for bar-1.foo.com through bar-8.foo.com
for i in {1..8}; do ssh bar-$i.foo.com "systemctl status mariadb"; done
履歴のナビゲーションとコマンドラインの編集、履歴の展開、またはコピーと貼り付けのシェルキーバインドを知っている場合、これら3つのコマンドは何も再入力する必要がないことに注意してください。各コマンドの結果は、簡単に確認および比較できるようにターミナルに表示されます。絶対にすべてをコピーして、システムのどこにでも貼り付けることができます。
GUIを使用した最後のコマンドと同じように、リモートデスクトッププロトコルを介して各システムにログインし、マウスを動かしてアイコンをクリックし、マウスの座標とクリックを送信し、ビデオフィードを受信して、各サービスのステータスを手動で確認する必要があります。壁紙とウィンドウとポップアップメニュー。結果を並べて比較する簡単な方法はありません。共有クリップボードを処理してローカルコンピューターのファイルに結果をコピーするか、その多くのヘビーウェイト接続を処理してウィンドウのサイズを変更し、壁紙などを非表示にするプロトコルが必要です。
さて、それらの1つがダウンした場合は、メールで通知されます。
while true; do
for i in {1..8}; do
echo "==> bar-$i.foo.com"
ssh bar-$i.foo.com "systemctl status mariadb"
done > /tmp/services.txt
if grep '^\s*Active:' /tmp/services.txt | grep -qv running; then
mail -s "service failed!" [email protected] < /tmp/services.txt
fi
sleep 10m
done &
十分に単純です。今、私はレンダリングされたgui（OCR？）から情報を抽出する方法がわからないので、guiを使って同等のことを行うことはできません。
私がguiの方法で達成しようとしている問題は、for i in {1..8}やif grep ...などのことをguiでシステムに伝える方法がないことです。この座標にマウスを合わせてダブルクリックし、この推定時間待ってから、この新しいウィンドウをクリックしてください... "。これは、新しいウィンドウが表示される場所を推測できることを前提としています...
私はGUIで物事を行うことができますが、それは言語ではありません。何をしたいのかわからないので、自分のためにできる。自分でやらなければならない。
コミュニケーションが簡単
他の人に特定のタスクを実行するための指示をどのように与えますか？ GUIでは、キツネをクリックしてから、ハンバーガー（その用語を理解している場合）、メニュー、メニュー、メニュー、タブ、クリック、終了、クリックなどをクリックするように指示する必要があります。スクリーンショットを投稿すると役立つ場合があります。彼らが行く必要がある場所を指している大きな赤い矢印の付いたGUI。
コマンドを使用すると、...それらを記述します。アクションが複雑すぎて信頼できる場合は、コマンドをコピーして貼り付けるだけで操作を完了できます。
保存可能なアクション
これは明白かもしれませんが、複雑なコマンドのセットを組み合わせて、それらをファイルに入れて実行することができます...これは純粋な自動化です。どのようにしてguiはそれと競争できますか？
シェルのキーバインド、グロビング、ブレースの展開、履歴の展開など。
シェルについて不平を言う人のほとんどは、結局非常に繰り返し入力することになるので、それを行うと思います（それは、それがプラスであると私は主張しますが、それでもまだより多くの入力が必要なためかもしれません）。
シェルには、非常に効率的な作業を可能にする多くの機能があります。問題は、これらの機能について学ぶ必要があることです。すべてman bashとman zshallです。ここで表面を傷つけることすら多すぎます。
さて、ここでのポイントは、シェルが作業の繰り返しをカットする多くの機能を提供することです。特定のプログラムのGuiは、履歴機能などを通じて似ているかもしれませんが、シェルは事実上すべてに対して機能します。
端末のスクロールバックバッファとシェルの履歴
端末を表示用に最後の100000行を保存するように構成しました。しばらくコンピューターを離れたり、ターミナルを再訪しなかったりした場合は、いつでもスクロールして、（ターミナル）プログラムを使用して何をしたかを確認できます。コマンドを実行する前後にタイムスタンプを表示するようにシェルプロンプトを設定しました。 timeを使用して事前に実行することなく、コマンドの実行時間をいつでも知ることができます。とても簡単ですが、GUIを使用してそれをどのように実行しますか？デスクトップが常に録画されるように、ある種のビデオ再生を実装しますか？
最後の2000000コマンドを履歴ファイルに保存するシェルもあります。ファイルを見ると、コマンドがあるだけでなく、実行したときのタイムスタンプがコマンドごとにあります。数か月前、上司は私が雇われてから数か月後にやった仕事をするように頼みました。今は思い出せませんが、当時は思い出せませんでした。これは、いくつかのサーバーセットに関連する複数の複雑なコマンドでした。ありがたいことに、私はまだコマンドを履歴ファイルに保持していました。それらを見つけて再実行するのは非常に簡単でした。私はとても感銘を受け、履歴サイズの制限を2桁増やしました。もしあなたがすべてがGUIを使っていたら、この状況で何をしますか
プログラミングが簡単
プログラマーもユーザーです。端末プログラムを簡単に作成できることもユーザーエクスペリエンスの一部であり、これが非常に多くの新しいプログラムが端末で動作するように作成されている理由です。
ウィンドウやウィジェットの作成、およびいくつかのレンダリングループを処理する必要はありません。配列から引数を取得し、テキストを標準出力に出力するだけです。
GUIではなく端末のプログラミングには、別の意味もあります。手動で編集するためのテキスト構成ファイルです。最後にguiプログラムを使用したのはいつですか。ファイルを開いて編集し、プログラムを再起動して構成する必要がありましたか。 GUIプログラムのユーザーは、GUIを介して構成できることを期待しています。
プログラマーにとって、これはファイル内の設定を読み書きする必要があるだけでなく、そのためのウィジェットも実装する必要があることを意味します。
プログラマーがユーザーにウィジェットを使用することを期待するので、手作業で構成ファイルを編集することは、次善の経験になるでしょう。ユーザーにとって、これには欠点もあります。
- 彼は他のコンピューターや友達と簡単に設定を共有することができません。
- 上書きされるため、コメントを付けることはできません。
- バージョン管理の変更を追跡することは問題があるかもしれません。
単一の入力と出力
一部のプログラムで問題が発生し、エラーメッセージがあまり役に立たない場合は、straceを使用して実行します。 straceの出力とプログラムを組み合わせると、問題のメッセージが出力される直前に、エラーの原因となった動作を確認できます。最初のエラーが発生した後にプログラムが終了しない場合は、出力をsed '/message/q'などに渡して、メッセージが出力されたときにプログラムを強制終了することもできます。
GUIでデバッグしている場合、エラーはおそらくポップアップウィンドウに表示され、メッセージはいくつかのシステムコールを介して渡されません。プログラムがstraceで行ったすべてのことを出力できますが、止まらない出力でエラーを見つけると、思ったよりも多くの検索が必要になります。また、Guiプログラムは同じ仕事を実行するためにより多くのことを行う傾向があるため、エラーの原因はおそらく、私が行う必要のあるタスクにほとんど関係のないメッセージパッシングシステムコールの多くの行の中に隠されます。
つまり、ジジコニア。それは失読症にたとえれば、私自身の造語です。つまり、典型的なGUIの愚かな小さな絵が何を意味するのかを理解しようとするのは、本当に、本当に、本当に大変なことです。私はそれらが直感的であるはずだと知っていますが、私にはそうではありません。これはあなたが疑っているより多くの人に当てはまると思いますか、それともなぜGUIがアイコンの下にテキストを追加することが多いのですか？
もちろん、拡張して使用する場合、いくつかの一般的なアイコンを記憶します（ただし、なぜ「直感的」であると思われるのかはまだ理解できません）が、新しいアイコンに直面すると、再び無知になります。さらに悪いことに、写真を調べる良い方法はありません**。なじみのないコマンドを使用すると、「man strange_command」を実行したり、プログラムのマニュアルのインデックスを調べたり、Google検索を使用したりできます。
人間は自然に言葉の生き物です。結局のところ、言語は私たちを他の動物と区別するためのものですよね。アルファベット言語を使用する私たちの場合、母国語での優れたリーディングボキャブラリーは50,000ワード以上になります。 （流暢さによっては、複数の言語を使用する言語では、言語ごとに10K以上が簡単に追加される場合があります。）見慣れない単語を辞書で検索するか、文脈からその意味を推測できます。 CLIを使用するために必要な数千（数十万ではない）をこのベースに追加するのは簡単です。
これは、ほとんどの識字者*の人々にとって、ターミナル/ CLIを使用することは、すでに持っているスキルを簡単に拡張できることを意味します。慣れると、一般に、本質的にグラフィカルではないタスク（描画など）のグラフィカルメソッドよりも優れています。
PS for @nekomatic：証拠として、これはどうですか： http://www.pewresearch.org/fact-tank/2015/10/19/slightly-fewer-americans-are-reading-print-books- new-survey-finds / 文字通り、最初のリンクは「今年本を読んだことがないアメリカ人の割合」を検索して見つかりました。リンクから「大人の27％は、過去1年間に本をまったく読んだことがないと言っています...」と「女性が読んだ本の数の中央値は5でしたが、男性の中央値は3です...」それが機能的文盲ではない場合、何ですか？
* GUIの人気は、機能的読み書きの増加と密接に関係していると思います。同様に音声入力と出力。
**日本語のような表意言語（そして私は中国語を勉強したことがないのですが）でも、辞書で漢字を検索するシステムがあります。
間違ったサイトにいる可能性がありますが...
ユーザー体験は、唯一の強制運転プログラムではありません。
端末の入出力のみを処理する場合、プログラムの作成と変更ははるかに簡単です。
人間はターミナルプログラムのメインユーザーではありません
端末のコマンドは、マシンがほとんどのグラフィックの背後で使用しているものと同じです。これは、複雑なものの一部をテストするのに非常に適しています。端末を介して実行されるほとんどすべての行は、それらをリンクすることによって複数のプログラムを呼び出します。NiceGUIから取得したグラフィックは、何かについてすばやく学習するのを容易にしますが、それについてマシンに指示するのに役立ちません。
そして私はここにいるので：focus
プログラムを多く使用した後、必要な情報を探す場所を正確に知っています（ライターがジャークでない場合）。学習曲線に上がれば、テキストであることはそれほど問題ではなく、フォーカスを変更しません。おそらく別のプログラムを使用して次の変更を行うのは良いことです。
2つの単純な理由のため
- できます
- 強力です
言われたことを付け加えると、結局のところ、GUIはコマンドラインユーティリティのかなりフロントエンドに過ぎないからです。
ボタンをクリックするたびに、コマンドが発行されます。ボタンがないアクションがありますが、端末で実行できないアクションを持つボタンはありません。
例として、ウィンドウでは、デスクトップ上の任意の直接アクセスアイコンを右クリックし、ダブルクリックすると実行されるコマンドをそこに見つけることができます。これをターミナルコンソールに直接入力すると、同じアクションが実行されます。
Windowsでは、コマンドラインのシンプルさとパワーを理解するのがより困難です。これは、シェルに、たとえばLinuxシェルにあるタブ補完などの多くの便利な機能がないためです。
下位互換性と組み込みシステム
B-52でアビオニクスを実行する30年前のシステムは、引き続き維持する必要があります。給水塔に供給するポンプのマイクロコントローラーや、私の工場のコンベヤーベルトを動かすシステムも同様です。
災害からの回復
システムがコールドスタートからGUIを起動するのに時間がかかります。バックアップマシンを実行する必要がある場合今すぐ生死にかかわる状況で外部ストレージデバイスをオフにする場合、余分な60秒間座ってたくありません。
リモート監視、診断、および管理
これは、帯域幅が制限されている状況に特に当てはまります。 1次、2次、および3次の広帯域通信リンクに障害が発生したが、それでも56kモデムを使用している場合、GUIデータを送信してその回線を下にドラッグすることはしません。 CLIを使用してルーターにリモートでログインし、何が問題なのかを理解して、ルーターを再び機能させることができます。
ターミナルはパワーユーザーにとってより良いソリューションだと思います。アクションにすぐにアクセスでき、あらゆるタイプの高度なタスクを実行でき、開発も簡単です。
ターミナルは避けられないことがあります。グラフィカルインターフェイスでは実行できないこともあるので、代わりにターミナルで実行する必要があります。
私のように、一部のアプリケーションでは、グラフィカルインターフェイスよりもターミナルを好む人もいます。たとえば、ボットを実行し、ターミナルはコード化されたアプリケーションの理想的な開発環境です（GUIツールを使用してコーディングしますが、ターミナルは常にボットを実行するために必要です）。
簡潔に言えば、多くの優れた説明が提供されているため、GUIの実装が実際的ではない多くの重要なシステムがあります。これは通常、ほんの少しのことしか行わないサーバーの状況であり、それらのタスクだけに使用できるすべてのリソースがあることを確認する必要があります。これらのタスクの一部にGUIアプリケーションの提供が含まれる場合は、そのためにプロビジョニングする必要がありますが、サーバーがWebページを提供するだけの場合は、絶対に必要なプログラムのみを使用して、それらのページを提供するだけです。
GUIプログラムは、より多くの情報を必要とするという性質上、ほとんどのコマンドラインプログラムに比べて、処理量とデータストレージが常にはるかに多くなります。
Gitはもう1つの素晴らしい例です。ほとんどの場合、数百マイルから数千マイル離れたサーバーで使用します。ターミナルを介してのみ対話できるため、サーバーとの通信に最小限のリソースが割り当てられます。その時点で、GUIプログラムと同じように快適に操作できるように、コマンドラインに慣れる必要があります。
制御と精度
端末を使用するには、端末を機能させるコマンドの知識が必要です。初心者には直感的でも簡単でもありません。しかし、ユーザーがコマンドを理解すると、多くの機能は、インターフェイスで要素を見つけてマウスを操作するよりも入力する方が速くなります。
グラフィカルインターフェイスの一部の機能は、ユーザーを自分から保護するセキュリティしきい値の背後にある場合があります。 コンソールでコマンドを使用すると、ユーザーは自分の操作を完全に制御できます。
いくつかの回答は近づいていますが、どれもその基準に達しませんでした。
端末プログラムの最大の理由。ユーザーに提示する最も最初で最も簡単なことは、テキストの顔です。このテキストの顔は、ユーザーの言語です。 GUIを提示するために必要なすべてのコミュニケーションと対比できるように、最小限のコンピューティング能力とインターフェースが必要です。その上、GUIは、端末が存在するポイントに到達するためだけに、はるかに多くのメモリとコンピュータリソースと電力を必要とします。 GUIには、それを表示できるより高度なハードウェアも必要です。単純なLEDは、最も強力なサーバーを実行するために必要なすべてのテキスト情報を表示できますが、非常に単純なグラフィック以上のものを表示することはできません。
それに続いて、クリックするものに関して、チェックボックスやボタンをクリックすることで使用できる能力をはるかに超えて、人間の言語コマンドを入力する能力があります。いくつかの簡単な言葉で伝えることができる範囲と精度は、広範囲に及んでおり、制限はありません。 「chartreuse」の色がチェックボックスの1つではないが、プログラムのオプションである場合、何をしますか？