BSD の CLI で1週間暮らしてみよう 160
ストーリー by yoosee
CLIは慣れや使い込みが必要 部門より
CLIは慣れや使い込みが必要 部門より
BSD 曰く、 "OSnewsに 「A week in the BSD CLI」 という記事が紹介されている。猫も杓子もマウスを握り締めている昨今、Jem Matzan は便利な GUI 環境から1週間離れて見ることにした。FTP もチャットもメールもウェブもすべてコマンドラインで操作することに決心し、ラップトップで動く OpenBSD 3.5 だけで暮らしてみたとのことだ。結局、彼は元の環境に戻った時にはほっとしたと言っているが、このような試みは無駄ではないのでたまにはやってみるのも良いと思う。さて、読者の皆さんならどう感じるだろうか。"
実例からこじつけ (スコア:3, すばらしい洞察)
CUI(bash)の場合
$mpg321 music/Hoge/Fuga/*.mp3
で一発。
GUI(Winエクスプローラ)の場合
My Documentをクリック
→musicフォルダを目と手で探す。
→ダブルクリックでmusicフォルダ開き、今度はHogeフォルダを目と手で、、、
→Hogeフォルダをダブルクリックして、、、、
明らかにCUIの方が楽。でっかいプレイヤー起動して検索掛けるのなんかはもっと面倒。
けど「さあて、音楽でも聴くか」という時、
CUIの場合
$mpg321 music/ でTABを押す
ずらずらと並ぶアーティスト名見ながら「どれ聴こうかなー」
GUIの場合
musicフォルダ見ながら「どれ聴こうかなー」
さすがにCUIでやる気になれん。
決まった動作をする時が便利なんだよね。CUIは。個人的には、GUIを
「CUIに取って代わるもの」として扱うことは、今現在のどのデスクトップ環境見てもないと思う。
GUIがいま、あくまでUIとしてどれだけ便利かというと、
上に挙げた意味ではまだまだ物足りない部分が多く、
例えばうちは、CD資産すべてMP3化していて、ディスク自体にはほとんど触っていないにもかかわらず
CDラックはいつも目の届くところにおいてある。
「何聴こうかなー」な時の、人間の「物色する視線」には、
フォルダがどれだけスタイリッシュにデザインされていてもPC内では味気ないから。
GUIのよさとして「わかりやすい」というのがよく挙げられるが、
「わかりやすい」と「使いやすい」が、こういう局面ではまるっきり別物になるわけで。
「分かりにくくてもいいから使いやすい」GUIってないもんかね?
と常々思うのでありました。
Re:実例からこじつけ (スコア:2, おもしろおかしい)
CLIとGUI (スコア:2, 興味深い)
CLIには、入力は文字、出力も文字という特徴があります。このためにある操作の結果を別の操作の入力として再利用することができます。
簡単な操作から始めて途中経過を確認しつつ、段々複雑な操作を追加していき、最終的に目的とする結果を得ることができます。そのときのコマンドラインをファイルに保存しておけば、コマンド(スクリプト)としてその手順をいつでも再生することができます。
つまり、定型作業にコマンドという名前をつけることで、作業手順を圧縮することができます。この作業は何回でも積み重ねることができますから、ちょこっとしたスクリプトを貯めていくと日常の作業はどんどん簡単になっていきます。大げさにいえばノウハウの固定化といえます。
unixなどではcronなど自動実行の支援機能も充実していますから、コマンドを作った本人がいなくなっても機械はずっと動き続けるということもよくあります。
日常の作業はほとんど定型作業で占められていますから、これをどんどん圧縮していくことで、そのうちルーチンワークにはほとんど頭を使わずに、今やりたいことに集中することのできる環境ができてきます。
GUIだと入力はGUIのイベント(クリックした座標、押されたキーなど)、出力→それぞれのコマンドによって異なる、というように入出力が異なっているため、人間が行なっている作業を固定化していく能力に劣ります。HyperCardのHyperTalkから発展したApple Scriptなどはその点を補おうとした試みです。
HyperCardはもう10年以上前のソフトですが、ハイパーリンク機能およびオブジェクトプログラミング環境付のペイントソフトです。UIに興味のある人にはぜひ触って欲しいと思います。
※今だにこの域に達していないWWWベースの学習ツールに辟易中。
Re:CLIとGUI (スコア:1)
取っ付きさすがは無いですが、慣れれば最低限の動作で自由にブラウザを制御でき、非常に便利です。主にマウスを使うアプリケーションだから、マウスだけで操作が完結するべき、という思想が、emacsのそれに近いものを感じます。複雑なキーバインドで取っ付きにくいけど、文字を扱うソフトだから、ホームポジションで操作が完結すると便利。
プログラミング可能かどうか、という一番重要な点については、触れていませんが…。
#HyperCard触ってみたいと思った。
Re:実例からこじつけ (スコア:2, 興味深い)
メニューから選択しても、コンソール画面に打ちこんだのと同じ結果になるような奴です。
例えば、アプリを起動してから
音楽の再生→フォルダの選択→フォルダ選択ダイアログが開く→
「music」フォルダ選択→「Hoge」フォルダ選択→「Fuga」フォルダの選択
のような処理を
アプリを起動してから
>play music/Hoge/Fuga/
のようにする感じで、実行できるようなものです。
すでに、GUIとは呼べなくなっているかもしれませんが、GUI+CUIは便利です。
結局は現状のOSではアプリが自前で対応するしかないと思いますよ。
キーボードメインで操作した場合@WinGUI環境下 (スコア:2, 参考になる)
田ミ>M>H(oge)>Enter>F(uga)>Alt>F>Q
最短8ストロークで完了
再生するために開いたフォルダも閉じるなら、+2~+3
# Alt>F>Cか、Alt+F4(Alt+Fキーは面倒なので大抵前者を使う)
WMPがアクティブにもしもなったら+3
# Alt+Space>N
以下詳細
・Windowsキー(スタートメニュー表示)
・M (Musicの頭/スタートメニューのマイ ミュージックはMusicにリネームされている)
・H (Hogeフォルダへフォーカス移動)
・エンター (Hogeフォルダ内へ移動)
・F (Fugaフォルダへフォーカス移動、Fooがあるなら"FU"みたいに途中まで打てばOK)
・Alt>F>Q(メディアプレイヤーの再生キューに追加)
※別に左に出てる「選択して再生する」をクリックでもOKか。
ちなみにフォルダ選択ってどちらも日本語になると致命的に面倒だよね
場合によっては日本語が入る場合もGUIのほうが断然楽かもしれませんね。
# ノートが原因でこんな操作を普段からする癖になったのは秘密
Re:キーボードメインで操作した場合@WinGUI環境下 (スコア:1)
スタートメニューはWin2k look and feelが前提ですな。WinXP look and feel使用時に[すべてのプログラム]などから名前がMで始まる項目を選択すると、それがメニュー左側の一覧に加わり、Mが「一字決まり」でなくなりますから。
今Mが一字決まりかどうか目視確認しながらタイプするのでは利便性が半減なので。
#私も同じようにして生活しているのでID
名物に旨いものなし!
Re:キーボードメインで操作した場合@WinGUI環境下 (スコア:1)
ということはkei100さんはWinXP look and feelですか?
WinXPが勝手にメニューをどんどん変更してしまう点、その結果画面を見ながらでないとキーボードでも操作できない点について、kei100さんのご意見をいただきたいんですが。
私ですか? 私はWin2k look and feelで、スタートメニューの下はよく使うものが一字決まりになるように編成してあります。
#Windowsが勝手にメニューをいじくることが「むしろ、不愉快」と思っているorangeful
名物に旨いものなし!
Re:実例からこじつけ (スコア:2)
将来脳にPCが直付けになったとしてその時に用いられるインターフェイスはGUIかCUIかってのを考えると
結構興味深い感じがします。
人間の思考形態も相まってかなり深そうな気がするようなしないような。
ボイスオンリーなオペレーションの場合はCUIの仲間にはいるのかな?
他の方のご意見を伺いたいのでボーナスを消費してみました。
(これって使いまくるとなくなるのかな?)
GUI的対応 (スコア:1)
こじつけにマジレスカコワルイ (スコア:1)
[Windows]キーと矢印キーでMy Documentを選択し[Enter]で開く
→[m]を何回か打つとmusicフォルダが選択される
(mからはじまるフォルダがmusicだけなら一発でmusicフォルダが選択される。
また、すばやく[m][u]と打つことでmusicフォルダにあたる可能性を高めることもできる)
→[Enter]でmusicフォルダ開き、今度はHogeフォルダを[h]を何回か打って選択、、、
→[Enter]でHogeフォルダを開き
私はCUIのGUIに勝る点は操作説明のしやすさだと思います。
初心者に電話越しに操作を説明することを想像すればおわかりいただけるかと。
また、操作方法のドキュメントをつくる容易さも、画像をふんだんに使わなくてはわかりにくいGUIアプリに対して、CUIアプリはテキストだけでつくれます。
(これも若干こじつけですが)
無駄だと感じます。 (スコア:1, すばらしい洞察)
Re:無駄だと感じます。 (スコア:2, 興味深い)
まぁ、1週間CUIだけで暮らすことに意味はないにせよ、GUI・CUI共に一長一短あるわけで、GUI一辺倒のこの時代ですが、CUIの良さを知る機会はあっても良いかと。
Re:無駄だと感じます。 (スコア:1)
「おお,これ,GUIよりもCUIでやった方が楽ジャン.」
ということがあるかもしれません
旅に出ます.(バグを)探さないで下さい.
ふつうかなぁ...と思いつつ... (スコア:1)
Re:ふつうかなぁ...と思いつつ... (スコア:3, すばらしい洞察)
ウィンドウシステムは必須だと感じてますけど。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
仮想ターミナル(*BSDならALT+F?)やscreenを使えばいらないです.
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Alt+Fn1-8の切り替えはどうでしょう
And now for something completely different...
Re:ふつうかなぁ...と思いつつ... (スコア:1)
ホットキーで全画面を切り替えるってのは勘弁。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:ふつうかなぁ...と思いつつ... (スコア:1)
screen は window manager なんだけどね。
ところで、screen なら split できるので、同時に 2 つ以上の端末見られますね。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Emacsで画面分割して M-x shell とかはいかがでしょ?
Re:ふつうかなぁ...と思いつつ... (スコア:1)
つうことで、Ctrl-Alt-F? の画面切り替えだけの暮らしにはちと耐えらないかな。emacs と vi は、同じ画面で同時に使いたいし。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Re:ふつうかなぁ...と思いつつ... (スコア:2, 興味深い)
cliのRSSリーダさえあれば今でも結構生きていけそうな気がします...
Re:ふつうかなぁ...と思いつつ... (スコア:1)
Visual Editor も使って良さそうな感じだし。
# 最初、termcap 系も使わない環境なのかと思ったバカ者。
Re:ふつうかなぁ...と思いつつ... (スコア:1)
catでアセンブラコーディングが書ければグルで,
catでデバイスドライバ書けるようになればウィザードだっけか?
Re:ふつうかなぁ...と思いつつ... (スコア:1)
w3mならウェブでも耐えられるんじゃないかと。
Re:ふつうかなぁ...と思いつつ... (スコア:2)
例えば
Ctrl+F → 検索ダイアログ表示 → キーワード入力 → Enter
でテキストを検索を行うソフトは多くあります。
しかしそれらのソフトのほとんどがCtrl+Fを押してから検索ダイアログが出る前にキーワードを入力してしまうと上手く動きません。
伝統的なCUIソフトの場合どんなに速く入力してもそれは1つのキューに溜められて1つの集中管理されたイベント処理ルーチンが1つずつ逐次処理していきますので正常に動作します。
しかし現状のたいていのウインドウシステムではイベント処理は分散され、各ウィジェットに割り当てられたイベントハンドラが処理を行います。
別にイベント処理を分散することは自体は問題ありません。オブジェクト指向としても自然です。
問題はイベントのディスパッチがウィジェットが表示されているかどうかに依存していて、しかもイベントのディスパッチを行うスレッドとウィジェットの表示を行うスレッドが非同期に動いている別のスレッドだという点です。
これは単純に2つのスレッドを同期させれば(細かい問題はいろいろありますが)解決できます。そうすれば伝統的なCUIのソフトのようにウィジェットを表示するのに時間がかかっても入力は遅れながらも正しく処理されます。
しかし、本当にこれでいいのでしょうか。
こうしてしまうと今度は逆に、ウインドウを表示した後、元のウインドウを操作しようとしても新しいウインドウが表示されるまで操作ができません。そもそもGUIでは操作対象はすべて目に見えるものであるべきです。見えないものが入力を受けとれる状態はセキュリティーの問題にも繋がります。
ではどうしたらいいのでしょうか。
どちらのイベントディスパッチ方法も一長一短なのであればディスパッチ方法をユーザーが明示的に指定してやればいいのです。
そしてGUIの枠組み内でそれを自然に行うにはコマンドをオブジェクト化すればいいのです。
つまりユーザーの操作はこうなります。
Ctrl+F → コマンドオブジェクト作成開始コマンド入力 → 検索キーワード入力 → Enter → コマンドオブジェクト作成終了コマンド入力 → 検索ダイアログが表示されたところでコマンドオブジェクトを検索ダイアログに適用
こうすればウインドウの表示されるタイミングに影響されずに入力を行うことができます。
また、この方法ではコマンドオブジェクトを使わない場合操作は従来のままとなり、初心者や既存の操作方法に慣れたユーザーを惑わせません。
もし、この方法でも検索ダイアログが表示されるのさえ待てないと感じるならば、それは検索という操作を検索ダイアログに対して行うものではなく文章そのものに対して行うものと考えているからです。よって検索ダイアログを使わずに検索コマンドを直接文章へのコマンドとして実装するべきです。
#イベントディスパッチをどのレベルで止めるのかとかいろいろ考える必要があります。
むしろ逆で (スコア:1, おもしろおかしい)
WindowsのGUIで1週間暮らしてみよう (スコア:1)
#いや、気軽にアップデートとかしたらリカバリーとかで大変でしたよ。
僕の環境 (スコア:1)
Re:僕の環境 (スコア:1)
OS: ウィンドウズ
電源オンしてすぐ起動するツール:
コマンドプロンプト×2(tcsh使用)
teraterm×2(2台の FreeBSD PCにそれぞれログインして、screen 起動)
(以上はスタートアップに入れてます)
という環境な私は時代に逆行してるんですかねぇ。
メールはmnewsだとか、たいていの操作はCUIでやってます。
新着メールを読む時は less /var/mail/hoge することも。
WEBブラウズだけは、w3mじゃなくて IE 使ってますけど…
Re:僕の環境 (スコア:1)
バージョン2のこと?
TTSSH [zip.com.au]もメンテナンスされていなくて、いまだバージョン1のみです。
Re:僕の環境 (スコア:2, 参考になる)
UTF-8対応TeraTermPro [vector.co.jp]
SSH2対応TTSSH [vector.co.jp]
2000以降しか確認してないみたいですが。
# ssh2 対応が alpha なので人柱の増員を期待
ありがたみを感じる意味では (スコア:1, 興味深い)
以前、仕事(職場)の関係で1年ほどメール環境のみですがCLIになった事が
ありました。関連会社の端末から、直接入れないので別のサーバを経由して
所属部署のサーバに入って、メールの送信は、SubjectをMIMEエンコードし
本文をJISにしてmailコマンドに流し込んでというのを手作業でやり、メール
を読む時はメールボックスを直接lessで。
#何年も前の話なので、作業手順に間違いがあるかも知れず。
mailコマンドを詳しく調べたり、ターミナルで使えるメーラを探したり設定
したり覚えたりすればもっと楽にはなったのでしょうけど。ヘタレというか
面倒臭がりというか、ほんとはもっと早く帰れるはずだったし。
元の職場に戻りGUIでメールの読み書きが出来る様になって、そりゃもう
有り難かったです。
#ヘタレなのでAC
携帯はCLI? (スコア:1, 興味深い)
Re:携帯はCLI? (スコア:1)
※viを覚えてからはその辺の性能は私の中では意味がなくなりました。
Re:スレタイを見た瞬間 (スコア:1)
…てかセクション名を見た瞬間に思ったのは
「あれ、もうFreeBSD 5.3-RELEASEができたのかな?」
でした。
#今週末くらい?
FreeBSD 5.3-RELEASE (スコア:2, 参考になる)
参考リンク
Re:FreeBSD 5.3-RELEASE (スコア:1)
参考リンク
Re:スレタイを見た瞬間 (スコア:1)
CLIってCommand Line Interfaceでいいのよね?
GUIに対応する言葉ってCUIだと思ってたから、.NET環境かーすげー、
って見てみたらちょっと的はずれでしたかな。
# screen・nvi・w3m・cueってあたりはよく使ってますが…
Re:逆に (スコア:1)
普段、FreeBSD だけど、メールとか Web とかユーザ状態で使うだけならコマンドラインはいらない状態です。
まあ、GUI でもできるけど、コマンドラインの方が楽で選ぶことが多い方なので、あえて使わないなんてことはしませんが。
の
Re:逆に (スコア:1, すばらしい洞察)
> まあ、GUI でもできるけど、コマンドラインの方が楽で選ぶことが多い方なので、あえて使わないなんてことはしませんが。
それは、その部分のGUIに改良の余地があるという兆候かもしれませんよ。
Re:逆に (スコア:1)
という問題提起からはずれるんですが、CLIとGUIの間とでも言うようなSUI(Screen User Interface)なんてのは考えられないでしょうかね。
#SUIは今作った造語。
極端な話「CLIサイコー」って言うんだったらエディタはedじゃなきゃいけないと思うんですが、そういう人でも多分vi/emacsを使ってますよね。これらのエディタが「コマンドライン」にはとても見えない。
だったら、シェル操作もコマンドラインじゃなくてスクリーン指向のfdのようなものを使うのもアリだと思います。出力はある程度視覚的に訴えるようになっていて、しかも操作にはキーボードのみを使用するのでホームポジションを崩さない。結構優れものではないでしょうか。
Re:逆に (スコア:1)
CLI Command Line Interface [google.co.jp] : 約 204,000 件
CLI Character Line Interface [google.co.jp] : 約 48,100 件
Character Line Interfaceで引っかかってる上位のページも Command Line Interface と表記されているし、少なくとも Command の方が主流ではあるようですね。
戦わずして人の兵を屈するは、善の善なるものなり
Re:逆に、 (スコア:2, 興味深い)
>過ごしてみた
今日のノートはペン操作だけでしてみました。当方タブレットPCなんで、キーボードなし、ペンのみの操作した日には。。。まだまだ難ありですが、結構便利なんです。授業中に百科事典を参照する時など、マウス・キーボードのみより直感的で、結構楽です。(直テキスト入力で、oneNote 2003, MS Encarta 2001)今後は、文字認識機能充実と、他にも色々な操作がジェスチャーで出来るようにならないかな、と。
*GUI系インターフェースで、いつも気になること
++スクロール用のウインドウのバーで、文書の上下スクロールがし難い。
++場合によっては、ファイル操作はGUIよりコマンドラインの方が早かったりします。ここあたりもタブレットPCの直感的なインターフェースに期待です。
++OSXの場合、警告ウインドウが邪魔に感じる、ドックが使いにくい。なんとなく、XPよりボタン・窓操作が、難しい気がする。(漢字トークの頃ほど軽快でシンプルではなくなったような気がする。)
Re:逆に、 (スコア:1)
コマンドや単語を入力するときに、文字が抜けると激しくウザイです。
特にEnterキーが死んでいるのが・・・
ということで、入力できない文字は、表示されているところから、コピペで入れたり、仮想キーボードで入力することになります。
最初から仮想キーボードで入れた方が早かったり。
結局キーボードなしでもなんとかなるもんです。
#「キーボードくらいちゃんとしたのを使え」が正解。
Re:emacs (スコア:1)
vi もすでに CLI なのかどうか疑問が (^^;;
最近のシェル(端末)はバックスペースなどのコントロールコードが
効いてくれるから、ウハウハな私。
ある意味、進化が止まっている悲しい私。
# それ以前に、CLI って言葉が良く分からない (^^;;
Re:とても驚いたこと (スコア:1)
自分が知ったのは PHP でモジュール版と CLI 版が分離、って辺りだからつい最近。
CUI の方が通りがいいと思ってたけど違うの?