コマンドライン版ソフトの意義

このQ&Aのポイント
  • コマンドライン版のソフトの意義とは何かについて教えてください。
  • GUI版と比較してコマンドライン版のソフトの利点は何でしょうか?
  • コマンドプロンプトだけで終始することで処理が高速になるため、コマンドライン版を選択する人もいるのでしょうか?
回答を見る
  • ベストアンサー

コマンドライン版ソフトの意義

avidemux、handbrake、winrarなど いくつかのソフトで、GUI版だけでなく コマンドライン版のソフトがアップされているものがあります。 これの意義を教えてください。 これは、シェルスクリプトやそのほかプログラミング言語を使って 自分の好きなようにファイルやフォルダーを読み込んで処理を施せるようにするためかと思っていたのですが 例えば、avidemuxの場合だと GUI版が avidemux コマンドプロンプト版が avidemux_cl なのですが、 avidemux_clを指定せず、avidemuxを指定しても シェルスクリプトで、プログラムを実行することができます。 GUI版の方が処理の進行などをグラフィカルで確認できるため、利点があります。 それだとコマンドプロンプト版の存在意義がないように思うのですが。 GUI版を使わずに コマンドプロンプトだけで終始していたほうが処理が高速になるから こちらを使う人がいるのでしょうか?

質問者が選んだベストアンサー

  • ベストアンサー
回答No.5

お、おう… > XP用に作られているGUIアプリは、多くの場合、VISTA、Win7、Win8では動作しません > VISTA用に作られているGUIアプリは、多くの場合、Win7、Win8では動作しません > Win7用に作られているGUIアプリは、多くの場合、Win8では動作しません > 「DOS互換アプリケーション」 >「DOS互換アプリケーション」にする事により「どのバージョンのWindowsでも動作可能」 ここはひどいインタネットですね! > コマンドプロンプト版の存在意義 ・昔からのパソコンユーザーのジジイがなんとなく安心する ・標準入出力を使った結果の取得を含む操作が可能になる   →作業の自動化とか、自分のアプリケーションから利用するなどがGUI版に比べ容易になる     標準入力・標準出力いうのはほとんどの言語・OSで使え、一度覚えてしまうと学習コストがGUIに比べて低い(と年寄りが感じている) ・文字を打ち込むだけなので正しいコマンドを提示してあげればアホでも操作できる   →テレホンセンターでの問い合わせやメールでの問い合わせに対し、操作法を指示しやすい    おそらく、ここのような図よりも文字ベースでコミュニケーションを取る事が多い所でもコマンド操作の方が指示しやすい(と年寄りが思っている) > 処理が高速になる 今時そんなことは無いと思います。

その他の回答 (4)

noname#208507
noname#208507
回答No.6

デバッグするときは肝心な部分に集中したい。 たいていの場合、話がより単純です。 デバッグでも、テストでも、開発でも、GUIよりコマンドライン・プログラムの方が。 機能をライブラリ化しておけば、なおさら。 コマンドライン版を直せば済む話ですし、GUIの処理はあちこちに跳び回るので。 ユーザは、自分の好きな方を使えばいいと思います。

  • Gotthold
  • ベストアンサー率47% (396/832)
回答No.3

GUIとかどう考えても邪魔でしょう。 バックグラウンドでバッチ処理しなからブラウザとか使ってるときに 見る必要が無いウィンドウがたびたび出てくるとか、絶対いらいらする。 ツールによっては、そのウィンドウにキャンセルボタンとかうっかり押したらまずいボタンまであるし。 > GUI版の方が処理の進行などをグラフィカルで確認できるため、利点があります。 それは人間が確認できるわけであって、 ウィンドウなんか出されても他のプログラムからそれを監視するのは難しくて 全然利点にならない、というか人間用のウィンドウなんて邪魔。 処理結果は標準出力とかに出してくれれば、 ログとして残すとかがやりやすい。

  • chie65535
  • ベストアンサー率43% (8512/19352)
回答No.2

>GUI版の方が処理の進行などをグラフィカルで確認できるため、利点があります。 だけど、GUI版には「Windowsのバージョンが変わると起動さえしなくなる場合がある」と言う欠点があります。 XP用に作られているGUIアプリは、多くの場合、VISTA、Win7、Win8では動作しません(セキュリティ強化により起動できなかったり、DLLやAPIの仕様変更で起動できなかったりする) VISTA用に作られているGUIアプリは、多くの場合、Win7、Win8では動作しません(セキュリティ強化により起動できなかったり、DLLやAPIの仕様変更で起動できなかったりする) Win7用に作られているGUIアプリは、多くの場合、Win8では動作しません(セキュリティ強化により起動できなかったり、DLLやAPIの仕様変更で起動できなかったりする) しかし「ファイルを読んで、ファイルに書き出す」のが処理のメインになるアプリケーションであれば「どのWindowsにも必ず備わっている、必要最低限の、ファイルアクセス機能のみ」さえ動けば良いです。 つまり、コマンドプロンプトで動く「DOS互換アプリケーション」にする事により「どのバージョンのWindowsでも動作可能」にする事が出来ます。 簡単に言うと「DOS互換アプリケーション(コマンドプロンプト版)は、Windowsのバージョンに依存しないで動作可能」なのです。 GUI版しか存在しないアプリを使っていて、新しいWindowsが出回り始めてから、アプリの開発者が「新しく出たWindowsには対応しません。対応するつもりはありません」って言ったらどうします? そうなったら、そのアプリの為だけに、古いWindowsを使い続けるハメになります。 もし、その古いWindowsが、XPみたいに「MSはサポート終了します。脆弱性には対処しません」って事になったら? パソコンが壊れて新しいパソコンにしてみたら、その新しいパソコンに使える「古いWindows用のデバイスドライバが提供されてない」って状態になって、古いWindowsがインストール出来ないって事が発覚したら? このように「GUIに頼ったもの」ってのは「誰かが、どこかで、何かのサポートを打ち切った瞬間、使い物にならなくなる」のです。 「グラフィカル」は確かに「視認性が良い」ですが、グラフィカル自体が「足かせ」になることもあるのです。 「ファイルを読んで、ファイルを書き出す」と言うのがメインのソフトでは「グラフィカルもGUIも無い方が、汎用性が高くなる」のです。

  • t_ohta
  • ベストアンサー率38% (5067/13241)
回答No.1

画面の描画が無い分高速に処理できるという意味もあるでしょうが、沢山のファイルをバッチ処理で勝手に変換して欲しいときなどはコマンドプロンプト版を使わないと自動化がしにくいからでしょう。

関連するQ&A

  • Visual StudioのGUIとコマンドラインによるコンパイル

    Visual Studio .NET2003を使ってます. 普段GUIでビルドしているのですが, それをコマンドプロンプトからclとlinkコマンドでやろうと思いました. プロジェクトのプロパティの 「C/C++」と「リンク」それぞれの「コマンドライン」というところで確認できるオプションを それぞれそのままclとlinkの後ろにコピペして実行しました. (clの方はソースファイルも最後に追加して.) ところが,出来上がったDLLの挙動が, GUIでビルドした場合と違っています. (JNIでJavaから呼び出しているのですが, コマンドプロンプトから実行した方は呼び出すときにエラーを出します.) GUIでやろうがコマンドラインからやろうが 同じ挙動になると思っていたのですが, 必ずしもそうではないのでしょうか. 用意した環境の不備など何かの見落としによりありえるのでしょうか. アドバイス頂ける方いらっしゃいましたら,お願い致します.

  • コマンドプロンプト(2000)で入力値によって処理を変えたい

    コマンドプロンプト(bat)プログラムの途中で ユーザからの入力を促して入力された値を 変数としてセットし、その値をif文などで 評価することにより分岐させて入力された値によって 様々な処理を行わすことは可能でしょうか。 シェルスクリプトであればreadコマンドのような ものに変わるコマンドを期待しています。 宜しくお願いいたします。

  • unixのreadコマンドで入力を指定時間待つというオプションはある?

    unix系のreadコマンドでプロンプトからの入力を待つ際に、 指定時間入力を待って、入力が無ければreadコマンド失敗、 となるようなオプションはあるのでしょうか? solarisのBシェルでスクリプトを書きます。 以上、よろしくお願いします。

  • GUIアプリスタート後コマンドプロンプトのウィンドウを隠したい

    コマンドプロンプトから次のようなコマンドを入力して、 GUIアプリ(スクリプト)をスタートさせています。 (Perl/TkによるGUIアプリが起動します)    perl hoge.pl ここでhoge.plが立ち上がった後はコマンドプロンプトの 黒いウィンドウは目障りで出来れば消したいのですが そんなことはできるのでしょうか? どなたかお分かりになる方いらっしゃいましたら お教え願えませんでしょうか? どうぞよろしくお願いします。

  • top などのプロンプトに戻らないコマンドの終了

    例えば、top コマンドは画面上に内容を表示し続けます。 ユーザが Ctrl-C をキータイプしない限り、プロンプトには戻りません(他のコマンドをタイプしたりはできません)。 そのようなコマンドを使った、次のようなシェルスクリプトの作成を考えています: (1) top コマンドの結果をファイル等にリダイレクトやパイプで渡す (2) (1) のコマンドは終了させ、 (3) 次の処理へ続く... [Q1] もちろん、top & とやればプロンプトにはすぐ戻りますが、別途 kill してやる必要があります。    面倒な気がするので、他に方法があればご教示ください。 [Q2] 面倒でない方法があればお教えください(もしくはこれを調べろ/参照しろ、などでも助かります)。 [Q3] また、このようなタイプのコマンドに呼び方があればお教えください。 ※ とくに top コマンドを使う必要があるのではなく、   他の同様のプロンプトに戻らないコマンドでも通用することを知りたいと思っています ※ 可能であればシェルに依存しないものが望ましいと考えています。   現在は ksh を使用していますが、bash/tcsh でも解決方法があればお教えください。 説明が下手くそで恐縮ですが、よろしくお願いします。

  • コマンドプロンプトからGUIフォルダを開く方法

    CUIとGUIを行き来する作業が多いため、効率向上を考えています。 「窓の手」を使うとGUIフォルダからコマンドプロンプトが開けるので便利に愛用しています。 それと正反対の動きをしてくれるコマンドソフトを探しています。 (任意のCUIから、GUIフォルダを開いてくれるもの) startコマンドでは新たなCUI窓しか開かないので悩んでいます。 昔のOS/2でopenコマンドというのがあったのを思い出したのですが、Windows版がなかなかみつかりません。 何かいいものがありましたら教えてください。

  • シェルスクリプトでバックグラウンドで実行したコマンドの実行結果を取得するには

    OS redhat linux シェル bornシェル シェルスクリプトでバックグラウンドで複数のコマンドを実行し、 すべてのコマンドが正常に終了したら次の処理へ進むみたいな事をしたいのですが、可能でしょうか? 直列にすればよいのですが、処理時間短縮の為、並列に処理したいのです。 宜しくお願いします。

  • コマンドの戻り値リファレンス

    シェルスクリプト内でコマンドの戻り値によって 処理を振り分けたいのですが、それぞれのコマンドが どのような場合にどのような戻り値を返すのか、 一個一個検証する時間がなく、非常に困っています。 そこで、コマンドの戻り値リファレンスのような ものがあれば参考にしたいのですが、 WEBをざっと検索しても出てこず、コマンドのヘルプも オプションの説明ばかりで戻り値について 説明がありません。 皆様どのように戻り値を調べていらっしゃいますか? 一つ一つテストするしかないのでしょうか?

  • コマンドラインのログファイルの作成

    Linuxで次のようなプログラムを実現したいのですが どのようにしたらよいでしょうか? (1) シェル起動後、自動的に起動し (2) シェルで入出力されるコマンドラインを指定したファイルに自動的に追加書込みされ * 書込みについては、一行毎に入出力された時刻も同時に書込むものとします 詰まり、次のような記述で、書込みたいのです 入力 時刻 出力 時刻 ・・・ 入力 時刻 出力 時刻 といった感じの書式です (3) 追加書込みされるファイルが一定容量以上になると自動的に別ファイルを生成して、そのファイルに書込まれる これは、Perlなどのスクリプト言語で作るべきでしょうか? それとも、( 例えば、コマンドやリダイレクトだけで作ると言ったような ) もっと簡単な方法がありますでしょうか?

  • ファイルのコピー(コマンドプロンプト・シェル

    Windows10で、ファイルABC001.txtがあり、 ABC002.txt ABC003.txt ~ ABC100.txt とコピーしたいです。 手作業では時間がかかるので、コマンドプロンプト・パワーシェル からコマンドで処理する方法はありますか? よろしくお願いします。

専門家に質問してみよう