河野真治 @ 琉球大学情報工学です。

今日は、prompt と precmd 書いて、kterm のtitleは変更できるよう
になりました。cd/pushd は、まだやってない。
    if (  $?TERM == 1 ) then
みたいなのって、どうやって書くんだろう?

.zshenv が常に読まれて、.zshrc がinteractive な時に読まれて、
login shell では、.zprofile なのね。それはわかりやすい。
    if ($?USER == 0 || $?prompt == 0) exit
とかやる必要はないわけね。が、既に、login shell なんていうの
は死語だな。

module とかもチェックしたけど、lock 関係はないのかぁ。がっかり。

In article <d1ugbd$1gtd$1@nsvn02.zaq.ne.jp>, shirai@unixusers.net (Takashi SHIRAI) writes
> 　因みに POSIX shell 仕様は context free grammar じゃないの
> で yacc では parse し切れないと思います。「)」に複数の意味が
> ありますから。

context dependent grammer でないものを探す方が難しいです。変
数の宣言は context dependent だしさ。で、yacc/bison で context
dependent を何とかするのは、状態を覚えておけば良いだけなので、
まぁ、そんな感じで実装すれば良いわけ。

> 　bash も yacc 使ってるので「)」を正しく parse 出来ないんで
> すよね。

それは「yacc だから」ではないです。単純に bash のパーサの
バグと言うと思う。

> 　yacc でも頑張れば出来るのかも知れませんけど、そんなところ
> で無理するくらいなら自前で parser 作った方が楽なんじゃないか
> しらん。

それには結構賛成するんだけどさ。でも、たぶん再帰下降法 + 状態
管理で書くことになると思います。それは実は yacc + 状態管理と
あまり差がない。差がないなら使わないっていう選択肢ももちろん
あります。

> 　でも、得てして普及してるソフト程 source が汚いんですよね。
> adhoc な方が賛同を得易いということなのかな。

adhoc なソースの方が、

        豊富な機能をすばやく実装できる

っていうのがありますからね。Windowsが広まった原因だ。そして、実は、

        adhoc なソースの方がバグをとりやすい

ってのもある。何故かと言うと、

        adhoc な方法でバグ取りする心理的障壁が低い

から。綺麗なソースで機能拡張するときに、

        「あぁ〜 adhoc なソースになってしまう」

あるいは、綺麗にはバグ取り切れなくて、

        「この機能は、次回のmajor changeの時にしよう」

なんてのや良くある話...

> 　job control は結局端末制御に帰着するので、環境依存が激しい
> ですよね。「POSIX に限る」とか制限つけたところで、仕様に忠実
> な実装してない OS も少なくないし :-)

しかも、GUI当り前の方から見ると時代遅れだしなぁ。このあたり
OSの授業からは外そうかと思ってます。いまさら bg/fgでもあるまい。

あんまり関係ないけど、「スレッドの落とし穴」
    http://www.itmedia.co.jp/enterprise/articles/0503/23/news086.html
とかいうのがあって、自分的にはつっこみながら読んで笑えた。

「thread みたいなことしたくないから、process を作ったのに」
ってな話を誰かがしてたなぁ。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科