splash が 6月にベルリンで行われた GIMP developer's conference の写真になってる. Sven Neumann さんは参加したのかな？ そうだとすれば, どれかな？
どうも, 1.1.25 リリースまえの駆け込み commit が 7/30, 31 に大量にあったせいかな？ 若干, 混乱しているもよう. ビルドできませんよ？
いや, まじで.
しょうもないシェル技とかをたまにここで書いてますが, なんか, 俺の知らんところで引用とかされてるらしんで, ここらへんでも, あんまりええ加減なこと書けませんな. 困りましたな.
たとえば, コマンドをカッコとコッカで括れるんですな. これ, 便利ええですね. 「&」はコマンドの中では評価順序が高いので, 長いコマンドを 「&&」とかでつないたものをバックグラウンドに 回すときに, 一旦 suspend してからだと, 具合わるかったりするわけです. そこで, 全体を「()」で括って最後に「&」 をつければ, まとめてバックグラウンドにまわって, ナイス.
シェル語ってのがあって, つまり, 上に述べたようなコマンドの文法とか意味論のことなんですが, これ, 普段はあんまり深く考えずにコマンドをズバっと入力したり してますが, 実はれっきとしたプログラミング言語なんすよね.
だから, いろんなお約束があって, これをうまく活用すると, めんどくさい仕事がズバっと終わったり, うっかりミスが 無くなって具合良かったりもするわけです. 特殊文字や予約語が幾つかあって, それがいろんな働きを持ってたりする. そして, 何かステートメントを入力すると, そのたびに, シェルはそのステートメントを評価するわけで, だから, 「コマンド インタプリタ」という名前はダテじゃない.
以下, わしのバイブルである(つうか, unix 関連で読んだ唯一の本) 「UNIX プログラミング環境」からの引用
シェルがプログラム可能になっている理由
UNIX のシェルは, コマンド インタープリタとしては典型的なものではない. 確かにシェルは通常のやりかたと同じようにコマンドを実行させてくれるが, 一種のプログラミング言語でもあるため, はるかに多くのことが可能になる.
(中略)
シェルは, ループだとか, < , > といった入出力切替えだとか, * を使ったファイル名の拡張だとかいった仕事を受け持つ. このため, プログラムの中でこういった機能を考慮する必要は無くなる. さらに重要なことは, こういった機能があらゆるプログラムに対して 同等に適用できるようになることである. シェルファイル(註：シェルスクリプト) とかパイプといった機能は, 実際にはカーネルが実行しているが, それを作り出すための自然な構文を提供してくれるのはやはりシェルである. これらの機能は, 単に便利であるという範囲を超えて, 実際にシステムの性能アップに役立っている.
(中略)
ユーザはシェルスクリプトであることに何等気を使う必要は無い. RUN のような(註：笑), 特別なコマンドを使って実行する必要は ないのである. また, シェル自身も一つのプログラムであり, カーネルの一部ではないので, 他のプログラムと同じように, 機能を整備したり, 拡張したり, 使ったりできる. このアイデアはなにも UNIX だけのものではない. しかし, 他のどんなシステムより, UNIX ではこれらがうまく活用されている.
(中略)
シェルで何かをしているときには, 実際はいつもそれをプログラミングしているのだ ということは心にとめておいていただきたい -- シェルが成功している理由の 大半は, この性質のおかげである.
実は, わしが tcsh から zsh に移動した理由のひとつは, 普段書いている bash シェルスクリプトの構文がだいたいそのまま インタプリタでも使えることだった. シェル構文のダブル スタンダードはめんどくさくてウザい.
tcsh を使っていたときには, わしは, シェルがプログラミング可能という 性質をほとんど使っていなかった. もちろん, tcsh でも, インタラクティブにループや分岐が書けるし, そのことは知っていたわけだが...
たとえば, チャリのギア比のテーブルを計算するときに, いちいちエクセルなんか 起動するよりも, プロンプトから直接
for i in 42 52 do for j in 13 14 15 16 18 20 22 do echo "$i/$j" | bc -l done done | sort -n
の方が, ずっとカッコイイですよね？ いや, そう思わない奴も居るだろうけどさ. (む. zshell は float いけるらしいけど, よくわかんねもんで, bc 使ってます.)
だから, 補完とかヒストリも良いけど, こういう性質をうまく使ってやると, なんか, unix って感じかも. たとえば grep が, パタンに一致する文字列があったときと 無かったときで exit status が違っている理由は, 実にここにあるわけですよ. つまり, 「もしこのパタンが含まれていたら」とかの分岐が シェルでは grep なんかを使って簡単に書けるわけです. しかも, 正規表現 全開で. そういう処理が, プロンプトからインタラクティブに書けるところが, unix のシェルの強力なところ, 良いトコなんすよ.
emacs とシェルは, アプローチは (それに, 出身も)大いに異なるが, なんというか, 目指したところは, けっこう共通している気もするなあ. つまり, コンピュータを使うというのは, 結局, プログラミングを することに他ならないのだ, という洞察と, それを 手軽で効率的なものにしようという決意がね. これは, グラフィカルな開発環境がモゲ, とか, そういう目に見えるハナシとは 違って, もっとこう, 「システムは如何にあるべきか」といった, ファイルシステムとかの設計なんかも含めた, 全体的で, 幾分哲学的な問題だ. 哲学的ってのはつまり, システムの中で何がもっとも基礎的な構成要素であり, 他のどれを何と何の組合せで作るのか, という問題が, 形而上学で言えば, まさに存在論そのものだからである.
さらに言えば, シェルのうまい使い方を習得していくうちに, プログラミングに関する優れた作法が身に付いていく, というところが, シェルは最高にイカスかも. や, 俺はプログラミングが全然へなちょこなんで, ここは「作法が身に付くこともある」としておこう.
あるシェルにあって, 他のシェルにはないちょっと便利な小技なんかを いちいち憶えるのも悪くないが, マニュアル調べりゃ判ることを いちいち憶えてるのはあんまりかっこよくないかも. そんなことよりも, シェルを使うときは, それを使ってプログラミングしてるんだ, ってことを憶えておくと, わりと良いかもだ. そして, これは俺なんかが勝手に思い付いたことではなく, UNIX 流の始祖 B. Kernighan 師が仰っていることなのである.
GUI と CUI がどうしたとか, そんな話は くだらなすぎ. 「CUI はコマンド憶えないといけないからもげ」とか言ってる奴は ダメでそ. そんなのは全然まったくどうでもよくて, インターフェースがプログラマブルかどうか, ってのが 本質的なんすよ. もし, 「パソコン」として汎用プログラマブルマシンという形態に拘るのであれば, プログラマブルなインターフェース以外は生き残らないだろう. てゆうか, 生き残って欲しくないなあ. それが今のシェルみたいなものになるかどうかは知らんが.