シェル環境への試みhotwire-shell 40
ストーリー by nabeshin
試食コーナー 部門より
試食コーナー 部門より
hotwire-shellをご存じでしょうか? 12月3日のOpen Tech Pressの記事で紹介していますが、その記事がちょうど開発元ページからも(「日本」という)リンクが張られたのでタレ込んでおきます。
ものはというと、開発元のスクリーンショットを見ていただくとイメージがつかみやすいと思いますが、Pythonベースのクロスプラットフォームのシェル環境で、xtermの拡張というか、CUIシェルをGUIで実現していこうというシェル環境への新しい試みとなっています。いくつかのLinuxディストリビューションにはパッケージがあり、Windowsでの導入解説もあります。月1ペースぐらいで拡張され続けているので、今後どういう実装になっていくか、ちょっと面白げです。Webブラウザ上に新しいシェルUIを設計していくモデルケースとして見ても面白いかと思います。
ものはというと、開発元のスクリーンショットを見ていただくとイメージがつかみやすいと思いますが、Pythonベースのクロスプラットフォームのシェル環境で、xtermの拡張というか、CUIシェルをGUIで実現していこうというシェル環境への新しい試みとなっています。いくつかのLinuxディストリビューションにはパッケージがあり、Windowsでの導入解説もあります。月1ペースぐらいで拡張され続けているので、今後どういう実装になっていくか、ちょっと面白げです。Webブラウザ上に新しいシェルUIを設計していくモデルケースとして見ても面白いかと思います。
入れてみた (スコア:5, おもしろおかしい)
Re:入れてみた (スコア:0)
Fedora8 の GNOME、ディレクトリ名に「デスクトップ」とか日本語使ってるのよね。時代は変わったねぇ
Re:入れてみた (スコア:0)
Firefoxなんかでも、デフォルトのダウンロード先が"~/デスクトップ"に決め打ちだったりする。
確か、元々なくてもmkdirせず、エラーも吐かなかった筈だ。
# ま、オフトピだけどさ。
超訳 (スコア:4, 参考になる)
本家を見に行ったらなんか便利そうだった。
せっかくなのでいい加減な訳。
http://code.google.com/p/hotwire-shell/wiki/Hotwire [google.com] の最初の方
http://code.google.com/p/hotwire-shell/wiki/HotwireVsBinSh [google.com] の下の方
CUI でめんどくさかったところが良くなってる感じがする。
Re:超訳 (スコア:1)
cd して ls してなんか処理して cat とかを、パイプラインでつなげて書いてやっていたような物を、GUIで簡単に自動化出来ますよってものでしょう。
まんま Automation [apple.com] なんじゃないかな。
Re:超訳 (スコア:0)
デスクトップユーザは? (スコア:0)
>開発者やシステム管理者向けの
あれ?多数派であるいわゆるライトウェイトな「デスクトップユーザ」は対象に含まれてないの?
CUIな世界をデスクトップユーザにも触りやすくしてあげる、っていう効果を彼らは狙っていないのだろうか?
課題は「グラフィカル」にすることなのか? (スコア:3, すばらしい洞察)
shell が tty 上の操作環境だというのは,歴史的経緯も勿論あるのだけど, リモートログインとかも含めてどこでも共通に使える I/F として キャラクタ端末 を越える 枠組みが存在しないというのが大きいのではないでしょうか. またキャラクタ画面(テキストデータ)中心の表示・データが渾然一体となった処理系という要素も 大きいでしょう. 改めて,shell 環境が強力だと思える要素を挙げてみると:
一方,単に見た目という次元の話でなく,処理系の枠組みを変えようという観点では, MS の PowerShell は pipe のデータ(構造?)を単純テキスト・生データから オブジェクト(?)に拡張する考え方を持ち込んでいるように見えて なかなか興味深いです(誤解かもしれないし,他にもあるのかもしれないけど). もし,テキストだけを扱うユーティリティは,従来通り単にテキストとしては処理できる枠組みを維持し, 新しいツール同士はオブジェクトをパイプで繋げる処理で属性やメソッドを自在に 活用できる世界というのは,普及してくればなかなか便利そうに思えます.
Re:課題は「グラフィカル」にすることなのか? (スコア:1, 興味深い)
Project Home読みました?
It is not a terminal emulator, nor is it something you can set as your Unix "login shell";
instead, Hotwire unifies the concepts of shell and terminal to provide a greatly improved interactive shell experience designed for a modern desktop system - for example, rm moves files to the Trash.
>shell 環境が強力だと思える要素
そこに挙げられてる要素を充分生かせる人はそもそもこのソフトのターゲットじゃない気がする。
以下はちょっと、シェルに慣れられない軟弱者の放言なんだが
>shell 環境が強力だと思える要素
単純性・効率性・柔軟性の根拠としてそこに挙げてる機能を万人が生かせるとは思えない、というかハイまさに俺にとってはそんなの恩恵でもなんでもないねッッ!!(自慢できん
pipe等で自在に処理?それができるのはその方法を知っている(例:コマンドを知っている)人だけ、思いつける(例:正規表現やオプションの組み合わせのパズルが解ける)人だけです。
マウスを使わなくてもいい?マウスを使わせてください。
ちょっとした作業をプログラミング可能?プログラミングって何 おいしいの?
(生かしたソフトを利用できる とかそんな間接的な話じゃなくて直接その機能を生かせるか という話)
#
# こういう「出来る人は出来るけど…」とかMT車とAT車の利便性の違いの喩え話とかすると絶対フレームになるからACだっ
Re:課題は「グラフィカル」にすることなのか? (スコア:2, 興味深い)
シェルが便利だと思っている人が満足するような GUI なんて 実現不可能に思えるし、シェルなんて難しくて何の役に立つのか 分からないと思う人は今まで通り GUI & 個々のアプリケーションで 頑張ったら良いのではないでしょうか。
このソフトのターゲットはあなたのような人じゃない気がする。
Re:課題は「グラフィカル」にすることなのか? (スコア:0)
気を付けていろんな人を観察してみてほしい.
ほとんどターミナルな人だって,firefox使うときはマウス使ってると思うんだ.
ターミナルな人がguiだけの人と違うのは,方法を選べるということ.guiでもcliでも速いほうで仕事できるってこと.
ただ,それだけ.特に自慢するようなことでもないささいな違い.
だけど,マニュアルみないでマスターできるguiと違って,cliをマスターするのはちょっとだけ時間がかかる.当り前のことだけど万人向けではないんだ.
だから君に使えないからってトラウマに思うことはないんだよ.今の時代,guiだけでりっぱに生きている人はたくさんいるんだから.
だから安心して,guiだけで明るく生きていってね.
じゃあね,チャオ.
Re:課題は「グラフィカル」にすることなのか? (スコア:1, 興味深い)
>オブジェクト(?)に拡張する考え方を持ち込んでいるように見えて
オブジェクトです。「?」は要らないですね。
実装面でも、PowerShellでは.NETの、HotwireではPythonの、それぞれObjectを小細工なしに使ってる。
伝統的UNIXだと「アプリごとにばらばらなフォーマット」の出力テキストをバッドノウハウ的に覚え、それに基づいて変形作業をおこなって、という手順になります。これは結構面倒だし失敗の恐れも有る。Objectとしてアクセサ経由で統一的に触れるのは魅力的ですね。
そうか。GNOMEが「UNIXをNot Suckにしよう」というスローガンだった(らしいですね)のならば、Hotwireは「コマンドラインをNot Suckにしよう」なのかも。
…どちらもMSが出してきた道具を後追いしてるってのが我々としては微妙に悔しいですがね。GNOMEはOLE/COMな世界をUNIX等へ移植するモノだった。HotwireはPowerShellを。
>GUI
ビジュアルについては、
それがGUIの本質ってわけではないだろうけど、「マウスで触れる」ってのは大きいと思います。「選択」「つかむ」「Drag」という操作が出来ることが。もっともこれもtty用マウスドライバを用意すればCUIでもやれることなんでアレですが。
マウスの真の魅力はキーボードとは違うアクセスパスが得られることかな。親子関係や位置関係に縛られずいきなりカーソルやカーソルに従属するもの(ドラッグされてるもの)を移動できるって点。ようするに不定形操作です。不定形な操作には向いてるけど、パターン化された操作をパターンに則ってこなすのは苦手。
Re:課題は「グラフィカル」にすることなのか? (スコア:1)
PowerShellに関してはかなり小細工入ってますよ。たとえばArrayのArrayが扱えない。小細工によってフラットなArrayになってしまう。.NETの知識だけでなく、PowerShellの知識が必要です。
小細工によってCUI shellとして使いやすくなっている点ももちろんあるのだけれども、UNIX shellにおける複数のコマンドを経由させるための入力文字列をどうエスケープするのかというのにも似た、shellを使うために余計に複雑になるという側面が克服されていない気がします。
つまり、PowerShellにもCUIの欠点であるとっつきにくさ、学習の難しさがもれなく付いてます。
まぁそれはそれとして、PowerShellのようなものがGUI化されると聞くと興味を覚えます。
直感や省力化の助けになるような何かがあるのかどうか、Hotwireちょっとさわってみるか。
をぉ (スコア:1)
想像するとすごい気持悪いもののようだ。。。 若者しか適応できない気がする。。。
Re:をぉ (スコア:0)
# オートコンプリートフル搭載みたいなイメージでも可。
古すぎる人間の感想 (スコア:1, 興味深い)
最近gnome-terminalからktermに戻ってしまった身からすると(軽くて行間が調整できて便利。gnome-terminalでも調整できた?)、どうせターミナル作るんだったら、アンチエイリアスの効いた豪華なktermなんか作ってくれたほうがありがたかったりする。
もっともこのshellの肝は、オブジェクトが渡せるとかいうところにあるのだと思うが(某OSのPowerShellとかいうのに似ているのでしょうか?)面白そうなんだけど、gui出力をncurses表示にしてくれたほうが、ターミナルユーザーには受けるんじゃないかな。
# 古すぎて、ほんとに済まん、、、
Re:古すぎる人間の感想 (スコア:2, 興味深い)
yakuakeというターミナルエミュレータが好きです。
GUIが欲しいときもある (スコア:1)
私はWindowsでも、スタートアップでコマンドプロンプトでtcshが立ち上がるようになっていて、主にtcsh上で作業してたりしますが、
「遠く離れたディレクトリ間で、ファイル一覧を見ながら特定の条件にあったファイルを選んでコピー」するときとか、コマンドライン入力がめんどくさい場面は結構あるんですよね。
似たような名前のファイルが山ほどあって、ファイル名に日本語が混じってたりすると、ファイル補完駆使しても「ファイル名を入力」するのに一苦労です。
コマンドラインで「cp /source/folder/path/directory/{foo.txt,bar.txt,baz.txt,…以下略} /destination/folder/path/directory/」みたいな入力をするよりは、explorer 使って一覧からマウスクリックで「ファイルを選ぶ」方が簡単確実。
まあ、ヴィジュアルは重要ですがグラフィカルである必要は無いので、「dired使え」とか「FDcloneはどうだ」って言われそうですが、
こういう作業してるときは、キーボードだけで選ぶよりは、マウスでスクロールさせてクリックの方が楽なんですよね。
Re:GUIが欲しいときもある (スコア:1)
> 似たような名前のファイルが山ほどあって、ファイル名に日本語が混じってたりすると、ファイル補完駆使しても「ファイル名を入力」するのに一苦労です。
そういう時よく考えるのは、lsの結果のファイル一覧をドラッグしてファイルマネージャに
コピー・移動したいとか(その逆も)、右クリックメニューでcdやリネームできたらいいのにな〜 とか。
シェルとGUIの連携ということならこっちの方がいいな。CUIの拡張としてのGUI。
ログインシェルの指定に準じてくれると最高です。
# 最近は画像や動画の整理はファイルマネージャを使う機会が多くなったんですが、
# ドラッグ中に落っことしたり、似たディレクトリ名のとこに間違えて置いちゃって
# 探すのに一苦労とかあるのでw
Re:GUIが欲しいときもある (スコア:1, 興味深い)
それはおそらく、
ls(例えば)の結果をリダイレクトして落としたテキストファイル
なんだよね。
選択しなおしたい?じゃあviで不要行を削除してくれ。
変換とかもそれでいいだろう。
(sedやgrepのようなバッチ処理の話は置いといて)
そして出来たリストを
hogehoge `list`
と別のコマンドに食わせればいい。
…と考えると、ドラッグドロップ(やクリップボード)との利便性の違いは、
いったんテンポラリファイルの「名前をつけ」ないとならないって点だな。
名前をつけたファイルを作るってのは実は結構重労働だ。「名前重要」が逆に縛りとして効いて来る。
シェルのパイプラインの途中にviを入れたいんだけど、(標準では)できないんだよね。これが残念でならない。パイプの流れのようなものと、インタラクティブ編集(vi的な)とを、両立させることをUNIX陣営はあまり熱心に考えてこなかった(GUIに任せてしまった)。それが残念だ。
>ドラッグ中に落っことしたり
上記の逆の話になりますが、
作業用のテンポラリフォルダを作るといいですよ。
そのフォルダを開き(GUIシェルでって意味ね)、
それを、ドラッグの途中で落としそうもないくらいに「近く」に置いておくんだ。
典型的には「隣」とか「半分重ねて」くらいの位置に置けばいい。
そしてドラッグする。
一通り済んだら次は、そのテンポラリフォルダ(のビュー)を
目的の場所まで移動する。
それこそ目的の場所の隣とか(以下同文)
そして目的のものにドラッグドロップする。
ドラッグドロップ動作を入れ子にする感じですね。コンテナに積み込んで鉄道で送ってもらう感じともいう。
WindowsのExplorerでいえば、
ツリー表示がゴテゴテついたモードは、そんなわけで私は使いません。
単にファイル(やフォルダ)が並ぶ1つの箱として表示されるモードを多用します。
そしてその箱自体を必要に応じて移動します。
だから。
ドラッグできるくせにファイル用フォルダに一旦(中継)ドロップができないObjectは、クソです。
いや、それは不公平な言い方だな。正確にいえば逆に「どんなObjectでも一旦ドロップしておけるようなフォルダ」をOS(シェル)が用意しててくれるベキなんです。
GUIはもっと「オブジェクト(指向)」らしく作られるべき&使うべきです。例えば上記の話は「複数種のオブジェクトを場合によっては同一視できる機能」つまり「多態」です。
Re:GUIが欲しいときもある (スコア:0)
> それはおそらく、
> ls(例えば)の結果をリダイレクトして落としたテキストファイル
> なんだよね。
>
> 選択しなおしたい?じゃあviで不要行を削除してくれ。
> 変換とかもそれでいいだろう。
> (sedやgrepのようなバッチ処理の話は置いといて)
>
> そして出来たリストを
> hogehoge `list`
> と別のコマンドに食わせればいい。
パイプライン的な処理でいいなら、~/.bashrcに
alias cat_vi_ls="ls >/tmp/vi_ls.$$; vi /tmp/vi_ls.$$; cat /tmp/vi_ls.$$; rm -f /tmp/vi_ls.$$"
とか書きこんで、
exec
Re:GUIが欲しいときもある (スコア:0)
> コピー・移動したいとか(その逆も)、右クリックメニューでcdやリネームできたらいいのにな〜 とか。
ええと、まだ記事のアプリケーションが完全に理解できてないのですけど
「これ」がおっしゃる操作を実現するものと思えるのですが
Re:GUIが欲しいときもある (スコア:1)
>> コピー・移動したいとか(その逆も)、右クリックメニューでcdやリネームできたらいいのにな〜 とか。
> ええと、まだ記事のアプリケーションが完全に理解できてないのですけど
> 「これ」がおっしゃる操作を実現するものと思えるのですが
ターミナル上でのbash等の表示結果に対して「それ」ができればいいなぁ〜って話です。
hotwireはGUI側からのシェルへのアプローチのように見えます。
# 失礼。先のメッセージを書き込む前にHotwire 0.599をFedora 7で試しているのです。
# それで「やっぱり違う。違和感ありすぎ。スムーズにいかない」という使用感だったので
# どちらかというと、bashのGUI拡張の形で実現できたら違和感が少なくて良いのに・・と
# 思ったところを書きました。
lsは確かにリスト表示されますが、ドラッグはできない(全部クリックになってしまう)し、
mvもできません。
かといってコマンドラインでのファイル名補完も(のエスケープをうまくやってくれないので、
最近の長々と付けられたファイル名に対応できない。
# 最新版では対応しているのかもしれませんが。
Re:GUIが欲しいときもある (スコア:0)
Re:GUIが欲しいときもある (スコア:1, 参考になる)
例が悪いとは思うけど、MIME Typeとは違う別のオプションつけてたとえばこんな感じで深いディレクトリを探ろうとするじゃない? /foo/あたりでタブを押すとせめてそのディレクトリ位は表示して欲しいんだけど、Completionが出てくるだけ。
別コマンドでls入れてウィンドウ出してマウス選択していっても入力領域にドロップして行編集することもできないし。
お前はGUIで何を実現したいんだ?とか思うのよ今のところは。
#今後に期待。
Re:古すぎる人間の感想 (スコア:0)
http://sourceforge.net/projects/mlterm/ [sourceforge.net]
行間調整もアンチエイリアス表示も出来ます
Shell (スコア:1)
Re:Shell (スコア:0)
あれ、Hotwired [goo.ne.jp] はWiredvisionに移ったしなーとか一瞬よぎった。
素直におもしろいと思う (スコア:1)
シェルが使い慣れている私なんかは、Windowsでエクスプローラーなんか使っていると、ついつい「ここでcdが使えたらなぁ」とか考えてしまうことがありますし、逆にシェルを使っていてこのディレクトリに移動するのにダブルクリックが使えたらなぁとか思うこともあるので、Hotwireがもっと発展していけばcdを使いたいという欲求とダブルクリックを使いたいという欲求を同時に満たしてくれそうな気がしています。ただ、今の段階ではまだまだHotwireにはいくつか不満な点があって常用しようという気にはなれませんでした。特に余計なところで動作がもさっとするところが気に入りませんでした。ファイル数が多いディレクトリにcdしただけでちょっと待たされたり、1字打つ度にいちいち候補が表示されたり。でも、今後の展開が楽しみです。
それから、個人的に決定的にイケてないと思う点があります。それはPythonで実装されていることです。やっぱり今の時代何でもRubyでしょ!(←新しくプログラミング言語を覚えたくないだけの身勝手な言い分)
でも、このHotwireの実装をアイディア検証のプラットフォームとして、あとはアイディアだけパクって自分の好きなスクリプト言語で似たようなもん作ってしまえばいいのかなぁとか妄想しています。
// Give me chocolates!
Re:素直におもしろいと思う (スコア:1)
「エクスプローラ上でcdを使う」というのがどういうことがいまいち読み取れないのですが、
「エクスプローラで開くフォルダを直接指定したい」のでしたら、フォルダオプションで「アドレスバーにファイルのパス名を表示する」にしておけば、アドレスバーで自由に指定できるようになります。
「エクスプローラで現在開いているフォルダに、シェル環境側でcdしたい」のでしたら、フォルダやファイルをコマンドプロンプトにドラッグドロップすれば、そのファイル名がペーストされますので、「cd」と入力した後にドロップしてから「」で、エクスプローラで表示してるフォルダにcdできます。
Re:素直におもしろいと思う (スコア:0)
なんだぁ (スコア:0)
PrographCPX [google.co.jp]
や、Quartz Composer [mycom.co.jp]
みたいのかと思ったけど、そういうのでも無いのね。
#どーせやるならこの位までぶっ飛んじゃって欲しい気がする
#各部署の値をいじって結果を流せるピタゴラ装置みたいの
複数入力をサポートするコマンドからなる世界 (スコア:0)
>や、Quartz Composer [mycom.co.jp]
音楽ソフトのMAXとも似ていますね。
(MAXを焼きなおしたFreeソフトとしてはPureDataをよろしくね)
で、それらと比べて
UNIXパイプラインが残念なのは、
各コマンドの入力および出力が1つしかない、って点です。
UNIXだと
入力=標準入力
出力=標準出力
それだけです。
ファイルにも吐けますがそれは「パイプライン」の一環とは普通は見なさない。
標準エラー出力もありますが、あれは「標準出力とまとめる」か「捨てる」かの何れかくらいにしか使わない。
あえて言えばコマンドの起動引数(オプション)が第二第三の入力だと
Re:なんだぁ (スコア:0)
俺が言いたかったのは、
・lsとかgrepとかのコマンドおよび結果も全て視認もできるオブジェクトになってる。
・そのオブジェクトをパイプ(まさにパイプ)で繋ぎ、各objを右クリック等すれば出るプロパティ
メニューでCUIでいうオプションを変えられるようになってる。
・プロパティを変えれば自動的に一連のobj群を再実行して結果も動的に変わる(一部できないものも出てきそうだけど)。
で、結果をCUIで見たいならコンソール表示objに流しこむとかテキストにしたければテキスト保存objに流し込
Re:なんだぁ (スコア:0)
とりあえず (スコア:0)
Re:とりあえず (スコア:1, 興味深い)
それぞれのライブラリをベースとした泡沫Forkプロジェクトが多数できて、
プロジェクトのリソースは「たわけ」状態に…がオチ?
注:もともとは「田分け」。リソースを分割しすぎると弱体化する(から愚かだ!)という意味。
Rubyにも色々なGUIバインディングライブラリが有るが、
それらは実装が違うだけじゃなく、制御モデルも結構違うんだよね。
互換性どころか、互換性を得るためのラッパーすら、どう作ったものやら…
一方ロシア^H^H Matz氏は (スコア:0)
>コマンド(プロセス)間をパイプでつなげるというのはシェルの得意技なんだから、それを活用する方が自然だよね。脱帽。
なんかテキストベースでデータをやり取りする古臭い手法のほうに
感動してしまったらしい。
きっとクリスマスプレゼントは「オブジェクト間のデータをすべてテキストでやり取りするRuby」だぜ。