いやあ今度はサブシステム内の別の機能の製造をやっているんだけどさ。そこの設計はある仕組みが動くという前提で書かれてるんですよ。それは以下の様な仕組みで、そういった記述は沢山あるみたい。因みにシステムは java と Linux で動く物です。
Runtime.getRuntime().exec("ls -l | xxx -x");
俺は Linux は詳しくないから「ふーん」みたいな感じで組み上げてしまったんだけどさ。先行して製造してる人のをコピったから「動くんだろうなあ」みたいに深く考えなかった。だけど帰りの電車でふとこの事が頭に浮かんだんだよね「本当に動くのか…」って。きっかけは復帰コードからだったんだけど。パイプした場合の復帰コードってどのプロセスの復帰コードが返って来るんだろうって疑問に思ったんですよ。そんな事は 10 年以上の経験があるのに試した事が一度も無かった。でまあそこから考えが進んでさ。俺の理解だとパイプってのはシェルが担当するんだよね。そして Runtime#exec はシェルを介さずにカーネルに渡される筈なんだよ十中八九。って事は動かないんだよ…。ええええええええええええええええええええええええええええええええええええええええええええって思ったよ。ちょっと待ってくれって思ったね何と無く。まあ回避策は無くは無いと思うんだけど。実際には exec の中の文字列はユーザが書き変え可能な properties とかに書かれてるから、面倒な事になりそうな予感。もっとちゃんと考えてから設計して欲しいんだけどなあ…。相当に時間が無かったんだよな恐らく…。
っていうのは全て俺の理解違いで実際には動いちゃったりしてな。まあ無いだろうけど…。
http://javafaq.jp/S103.html
っと思ったらあったわ。sh に -c とかオプションがあったのか。でも復帰コードの問題が残るなあ。
http://d.hatena.ne.jp/yamadamn/20090925/1253903166
ほお…。知らないんだよなあ Linux シェルのこういう所…。
http://x68000.q-e-d.net/~68user/unix/pickup?%A5%EA%A5%C0%A5%A4%A5%EC%A5%AF%A5%C8
これは参考になる。ちょっとリダイレクトの仕組みについて頭の中を整理した。ここが重要だな。以下は引用です。
【引用始まり】
標準出力と標準エラー出力をまとめて file に書き出す場合は
% command >file 2>&1
とする。ここで順番を逆にして
% command 2>&1 >file (誤り!)
としてはうまくいかないことに注意。
標準エラー出力のみをページャなどで見たい場合は、
% command 2>&1 1>/dev/null | less
である。これも
% command 1>/dev/null 2>&1 | less (誤り!)
と順番を逆にするとうまくいかない。
【引用ここまで】
これらを成立させる仕組みってのを考えると「そういう仕組みなのか、ちょっと意外」って感じだけど、取り敢えず理解したわ。
つーか読み進んで行くとしっかりと解説してあったし、しかもパイプを使った場合の復帰コードの取得方法っぽい物まで書いてあるわ。やっぱり x68000 さんは頼りになる。8 年ぐらい前から参考にしてるよ x68000 さんは。
http://www.kiso.tsukuba.ac.jp/~makimura/text/node239.html
「閉じる」って事について少し書かれてる。x68000 さん記事の「閉じる」に就いて解説してる所を改めて読み返すとエラーになるのは command2 じゃなくて command の方だ。そこに書かれてる「チェック」って言うのは要は出力出来るかチェックするって事なんだろう。うんうん分かった分かった。
http://x68000.q-e-d.net/~68user/unix/pickup?exec
これはまた奇怪な…。Windows NT では有り得ないんだよなこういうの。そんなのがあるのか…。
