トップページunix
1001コメント289KB

シェルスクリプト総合 その20

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2012/06/08(金) 00:35:51.19
シェルスクリプトの総合スレです。
スクリプトのお勉強・自慢・腕試しなどにどうぞ。

□お約束
・特記なき場合はBourne Shell(/bin/sh)がデフォルトです。
 bash/zsh/ksh/ashなどに依存する場合は明示しましょう。
 Linuxユーザは/bin/shの正体がbashなので特に注意。
 FreeBSDユーザは/bin/shの正体がashなので注意。
 v7 shに一番近くて、現役のshは、OpenSolaris由来のheirloom sh。
  http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sh/
  http://heirloom.sourceforge.net/sh.html
・csh/tcshのシェルスクリプトは推奨されません。
 (理由は「csh-whynot」でググれ)
・UNIXにはシェルスクリプトに便利な小さなコマンドがいろいろあります。
 manや参考リンクを見ましょう。
 aproposないしはman -kでそれらしい単語による簡単な検索もできます。
・シェルスクリプトのことをシェルってゆーな
・シェルで使えるワイルドカード等は正規表現ではありません。
 正規表現の話題はスレ違い(正規表現スレへ)

□初心者へのアドバイス:
・適した道具を判断するのも頭の重要な使い方。シェルスクリプトよりも
 RubyやPerlの方が適した仕事には素直にそちらを使いましょう。
・知らないコマンドが出てきたらmanを引きましょう。
・思い通りに動かないときは、まずは sh -x でトレースしましょう。

前スレ
シェルスクリプト総合 その19
http://toro.2ch.net/test/read.cgi/unix/1323515200/
0539名無しさん@お腹いっぱい。2012/08/09(木) 12:13:15.06
>>527がおいてけぼりになっとる。
0540名無しさん@お腹いっぱい。2012/08/09(木) 12:23:57.33
上の例だとdiff終了時点でshellが削除だろうね。
0541名無しさん@お腹いっぱい。2012/08/09(木) 12:31:51.13
全子孫が終了するまで削除しちゃだめだよね。

こんなのとか
daemon hoge <(hage)
0542名無しさん@お腹いっぱい。2012/08/09(木) 13:19:33.96
>>538
え、そんなの初めて聞いたぞ。

「"named pipe" "shell script"」でググって出てくる上位5サイトに
「<(コマンド)」や「>(コマンド)」の話が、チラっとも出てこない
ことからして、君の組織だけで生まれたローカルな用法なんじゃねえ?
0543名無しさん@お腹いっぱい。2012/08/09(木) 13:32:16.61
プロセス置換 (process substitution) がサポートされるのは、 名前付きパイプ (FIFO) または ファイル・ディスクリプターの /dev/fd 形式での指定 をサポートしているシステムです。
0544名無しさん@お腹いっぱい。2012/08/09(木) 13:35:52.74
UNIX domain socketでも何とかなるでしょ。
0545名無しさん@お腹いっぱい。2012/08/09(木) 13:40:06.41
>>543はbashのman page
0546名無しさん@お腹いっぱい。2012/08/09(木) 13:40:10.34
>>544
UNIX domain socketでは、そのファイル名を渡されたコマンド側が
open()でオープンできないから無理。
0547名無しさん@お腹いっぱい。2012/08/09(木) 13:41:12.87
>>544
openできないからだめ。
0548名無しさん@お腹いっぱい。2012/08/09(木) 14:21:53.82
>>543
「コマンド置換」と、
「名前つきパイプ または ファイル・ディスクリプターの /dev/fd 形式での指定」が、
きちんと分離して書かれてるね。

しかも、名前つきパイプが使えることと、コマンド置換が使えることは等価ではない
(ファイル・ディスクリプターの /dev/fd 形式での指定ができればコマンド置換が
使える)ことも明確に書かれている。

ますます >>538 が、何を読んで、コマンド置換のことを名前つきパイプだと
思い込んだのか知りたくなるな。まさか >>543 の文章じゃないよな。
05495482012/08/09(木) 14:26:25.67
s/コマンド置換/プロセス置換/
だった。
0550名無しさん@お腹いっぱい。2012/08/09(木) 14:26:36.71
初期のshellは”コマンド置換”的な文法だったと「UNIX原典」にあった。
0551名無しさん@お腹いっぱい。2012/08/09(木) 14:27:37.29
>>548
「コマンド置換」??www

いつの間にコマンド置換に話になったんだよw

プロセス置換を理解していない無知自慢かよwww
0552名無しさん@お腹いっぱい。2012/08/09(木) 15:34:32.97
<( … )の形でパイプが使えると知らなかったときは
/dev/shmに一時ファイル作ってガリガリ言わんようにしてたな
他に何も代わりの方法を思いつかなかったからだが

パイプって読取る方が書込む方より遅かった場合、書込む方は待たされるのか?
最近マルチコアが当たり前だし、キャッシュも利くだろうから、
一時ファイル作る方が速く処理が終わるかもしれん
0553名無しさん@お腹いっぱい。2012/08/09(木) 15:52:20.68
>>552
> パイプって読取る方が書込む方より遅かった場合、書込む方は待たされるのか?
でかい出力処理 | less
とかやったことないの?

> 最近マルチコアが当たり前

> 一時ファイル作る方が速く
が、全然つながんねえ
0554名無しさん@お腹いっぱい。2012/08/09(木) 15:56:31.53
> > 最近マルチコアが当たり前
> と
> > 一時ファイル作る方が速く
> が、全然つながんねえ

だね。
名前つき/なしに関わらず、パイプやソケットならマルチコアで
並列に動く可能性がある(マルチコアを生かせる)けど、
ファイル経由してたら、シングルコアと性能変わらん。

>>551
で、結局、「プロセス置換のことを、named pipe と呼ぶ」っていうのは
どこかの組織のローカルルールの話だったってことで OK?
世の中に広まってる話なら、ソースよろ

0555名無しさん@お腹いっぱい。2012/08/09(木) 16:12:16.26
>>554
ggrks
0556名無しさん@お腹いっぱい。2012/08/09(木) 16:17:46.74
世界最強のシェルスクリプトを作ったのでみんなで使ってください。
たぶんzshでしか動きません:)

command-line clock - Pastebin.com
http://pastebin.com/HvYxU9bu


>>read -t1 q ## -t1=timeout option 1 second.

ところで、ここを-t0.001とかどんどん小さな値にしていくと、終了時の動作(適当にEnterとか入力して終わらせてください。)として
breakした後にまだechoってるような表示になってまうことが10回起動・終了すれば1回ぐらいあるような感じなんですが、
これってなんでなんですか。
0557名無しさん@お腹いっぱい。2012/08/09(木) 16:26:30.18
readの次に
sleep 0.5
とか入れてみればほぼ100%再現するよ
0558名無しさん@お腹いっぱい。2012/08/09(木) 16:28:06.39
>>555
答えられないのね。
0559名無しさん@お腹いっぱい。2012/08/09(木) 16:29:35.46
>>557
うん、そうなんですよね。どういうことなんでしょうか。
ていうか、プログラムのコピペミスってますね、さーせん。
0560名無しさん@お腹いっぱい。2012/08/09(木) 16:33:00.69
あぁ、sleep中に打ち込んでるからってことでしょうか。なるほろ×2。
本当にありがとうございました。
0561名無しさん@お腹いっぱい。2012/08/09(木) 16:36:14.11
>>555
グーグルは存在の検索はできるが、非存在の検索は出来ない。
0562名無しさん@お腹いっぱい。2012/08/09(木) 16:36:26.28
いや、でもやっぱりそれっておかしくねえ?
readの変数への代入がwhileループ始まるより遅いってこと?
0563名無しさん@お腹いっぱい。2012/08/09(木) 16:38:02.93
あぁ、おかしくないか、打ちこんでる間のタイムアウトの方が早くて次のループに入ってるだけの話か。そういうことっすよね?
本当にありがとうございました。
0564名無しさん@お腹いっぱい。2012/08/09(木) 16:38:42.42
改行して、whileで一度中に入って、時刻表示して、次のreadで取り込まれて、while抜ける
0565名無しさん@お腹いっぱい。2012/08/09(木) 16:39:14.15
>>562
変数への代入じゃなくて、
read実行開始時に端末のバッファをフラッシュする関係で
直前のEnterを取りこぼすということ。
0566名無しさん@お腹いっぱい。2012/08/09(木) 16:42:25.90
>>565
いや、それは違うだろ
0567名無しさん@お腹いっぱい。2012/08/09(木) 16:45:15.73
read -t 0.01 とか sleep 0.5 とか、Linux限定全開ですな
0568名無しさん@お腹いっぱい。2012/08/09(木) 16:47:58.63
昔gccがgasにpipeで渡すか、それとも一時ファイルかという議論があった時は、
性能評価のレポートによりpipeで渡す方が効率が良いということになった。
もちろんSSDが主流になるといろいろと変わってくると思われるが。
0569名無しさん@お腹いっぱい。2012/08/09(木) 16:49:47.73
read -t は駄目だけど、sleep 0.5 は *BSD でも動くよ。
まあどっちも POSIX 外で、移植性はないけどな。
0570名無しさん@お腹いっぱい。2012/08/09(木) 16:52:50.82
zsh限定って最初から断わってんだから、read -t も有り
0571名無しさん@お腹いっぱい。2012/08/09(木) 16:55:46.68
sleepってビルトイン関数じゃないからzsh関係ないような。
0572名無しさん@お腹いっぱい。2012/08/09(木) 17:02:39.79
だからー
sleep 0.5 は *BSD で可なので、Linux限定ではない
read -t は zsh で可なので、Linux限定ではない
05735562012/08/09(木) 17:18:27.14
-tの時間を少なくしていくと、
While文の条件判定の所で一番時間が掛かるようになっていって、
そこの間でEnterを打ち込むから、echoが二度効いてしまうように見えるってことかな?

最初はecho中にEnterが効いてるからと思ったけど、それならWhileループに二度目突入しないものね。
0574名無しさん@お腹いっぱい。2012/08/09(木) 17:25:58.46
readがタイムアウトした瞬間から、
echoの最初の文字を出力する瞬間までの、どこでもありうるね
echoが二度効いてるんじゃなくて、Enterで次の行に行っちゃったから、
そこにechoしてるだけ。
0575名無しさん@お腹いっぱい。2012/08/09(木) 17:58:01.77
世界最強ってところには誰も突っこまないのか。
0576名無しさん@お腹いっぱい。2012/08/09(木) 18:20:53.39
そこつっこんでも面白くならない。
0577名無しさん@お腹いっぱい。2012/08/09(木) 18:38:20.10
突っ込まれたくないなら世界で2番目くらいに強いって言っとけばいい

所で、時計なのに一定時間待つって処理でいいの?タイマ設定してシグナル送ってもらった方が正確じゃね
05785562012/08/09(木) 18:59:37.13
command-line clock v2 - Pastebin.com
http://pastebin.com/nRfEbSZF

ちょっと改変して、コマンドのreturnの値を条件式として使うように、
こんな風にしてみました。

でも、こうしても-tの値を減少させていくと、二重にechoってるようになるのが
どうしても解せません。なんでだよ!さすがにおかしいだろ!
やっぱり順次処理されてないのでは?

>>577
そんな格好いいのが出来るなら、敗北は認めなければなりませんね。
そこに美しさがあれば世界金メダルは譲ります。
0579名無しさん@お腹いっぱい。2012/08/09(木) 19:02:59.50
readでタイムアウトしてからechoまで0秒じゃないんだから、
そこでEnter打ったらなるんだよ
echoの前に sleep 入れてみたら確認できるだろ
05805562012/08/09(木) 19:06:32.81
>>579
あ、前のechoが残ってるのか、
どうやらオバカさん世界一の金メダルは私のもののようですね。ふっふっふっ。

本当にどうもありがとうございました。
0581名無しさん@お腹いっぱい。2012/08/09(木) 19:18:48.76
てゆーか、この程度なら、別に zsh の read -t とか、
BSD&Linux の拡張 sleep とかに依存せず、POSIX 範囲内で書けないか?
こんな感じ。

#!/bin/sh

while :; do printf "\r%s" "$(date +%Y-%m-%dT%H:%M:%S%:z)"; sleep 1; done &
pid=$!
read x
kill $pid
0582名無しさん@お腹いっぱい。2012/08/09(木) 19:25:37.74
sleep 1 だと遅延が蓄積して、どこかで2秒進んだりするから、
1秒未満でもうちょっと細かく再表示したいっていう意図じゃないの?
0583名無しさん@お腹いっぱい。2012/08/09(木) 19:26:03.35
>>581
せっかくそこまでするなら $( ) は ` ` にすべき。
0584名無しさん@お腹いっぱい。2012/08/09(木) 19:35:13.63
> sleep 1 だと遅延が蓄積して、どこかで2秒進んだりするから、
> 1秒未満でもうちょっと細かく再表示したいっていう意図じゃないの?

対話的シェルにリアルタイム保証なんてないから、read -t の時刻指定を
いくら細かくしたところで、マシン負荷が高くなれば、2秒どころかもっと
進む可能性はあるよ。そういう、対話的シェルで実現困難な仕様は、そもそも
盛り込むべきじゃないだろう。

ちょっとの負荷で2秒とびが嫌だっていうなら、拡張sleepに依存して
sleep 1 を sleep 0.9 ぐらいにするって手は、まあないわけではない。
read -t や sleep で指定する秒数をあまり小さくすると、無駄なマシン負荷が
増えるので、あまり小さくするのは推奨せんが。

>>583
Solaris の古いシェルとかで動かすことも考慮するなら、その通りだな。
まあ、そこは常識で分かると判断した。
0585名無しさん@お腹いっぱい。2012/08/09(木) 19:36:24.68
それをいっちゃあ、リアルタイムOSじゃないのに、xclockとかありえんって話になる
0586名無しさん@お腹いっぱい。2012/08/09(木) 19:39:33.95
date +%N で現在時刻のナノ秒を取得して、
それを sleep 0.123 とかの小数点以下に(計算の上)反映すれば
無駄にプロセスを使わずにうまく同期できるのでは?
0587名無しさん@お腹いっぱい。2012/08/09(木) 19:41:11.55
逆逆。
リアルタイムOSじゃないので、xclockだって、更新間隔が1秒より大きくなる
こともある。それが仕様。
xclock にだって不可能なことを、シェルスクリプトに求めるなんて、そもそも
そういう要求自体がおかしいってこと。
0588名無しさん@お腹いっぱい。2012/08/09(木) 19:43:59.25
>>586
高負荷時のことを考慮に入れるのなら、そんなんじゃ全くもって無理。

鯆管って、ほんとリアルタイム処理を分かってないなーって言っちゃうよ。
ちゃんと考えてみなよ。

どうしても分かんなければ説明するので、その場合は降参と宣言することw
0589名無しさん@お腹いっぱい。2012/08/09(木) 19:46:52.91
よし降参だ説明くれ
0590名無しさん@お腹いっぱい。2012/08/09(木) 19:47:45.98
>>588
高負荷時のことはどうでも良くて、
位相的にきっちり合わせたいということでしょ。

非同期で突然 sleep 1 を whileループで回せば、
最初から誤差が最大 0.99999... 秒になる。
これを、毎回 date +%N で 1秒未満の残り時間を把握しつつ
sleep 0.9821 とかすれば「位相」が同期する。
05915562012/08/09(木) 19:50:02.71
>>581
つーか、これでいいっすね。&使ってバックグラウンドに回しても表示効くのね。
しかもそいつをreadでインプット待ちにしておいて、インプット来たら殺すとかすげー。
でもこいつでsleep間隔いくら小さくしても、おいらの作ったスクリプトみたいに、echoの二重表示にならないのはどうしてなのか理屈がわからない。どうしてでしょう。
バックグラウンドジョブにしてるから?わかる人本当にお願いします。

>>582
そういう意図はありまくりんぐでしたけど、>>581さんのやり方でsleepの時間をさらに小さくするだけでいいように思います。負荷との兼ね合いですが。
0592名無しさん@お腹いっぱい。2012/08/09(木) 19:53:13.20
>>589
答えは、
 高負荷時には、date +%N の実行だけで数秒ないしそれ以上の
 時間がかかることがあるから
だ。

分かりやすい例でいうと、メモリが溢れていて、date コマンド
どころか、シェルまで swap に追い出されていて、スラッシング
しまくりの状況を考えてみるといい。

たとえメモリが足りててても、CPUその他のリソースが足りてなければ
数秒程度の遅延は普通に起こる。

まあ、鯆管的には、そんなに高負荷になる前にリソースなりマシンなりを
増やせってことになるので気にしてないだろうが、高負荷を気にしないなら
sleep 0.9 でも十分だ。

>>590
なるほど。
そういう意図であれば、確かに拡張sleepに依存するのもいいな。
0593名無しさん@お腹いっぱい。2012/08/09(木) 19:59:25.40
>>591
> でもこいつでsleep間隔いくら小さくしても、おいらの作ったスクリプトみたいに、echoの二重表示にならないのはどうしてなのか理屈がわからない。どうしてでしょう。

read と kill の間に、時間のかかるdateみたいな処理がないから、
その間にechoが動いてしまう可能性が確率的に非常に少ない。
そこにダミーのsleepでも入れれば二重表示にできるよ。
0594名無しさん@お腹いっぱい。2012/08/09(木) 20:01:56.63
>>593 の言う通りだ。

read x
sleep 1
kill $pid

に変更すれば、二重表示が簡単に確認できる。
05955562012/08/09(木) 20:12:11.80
>>593>>594
おぉ、本当だ。お前らかっこいいなぁ。ワクワクさん並に輝いてるわ。

どうも本当にありがとうございました。
05965272012/08/09(木) 21:43:53.53
後始末について聞いてみたかったんだけど
やめといたほうがいいのかな… (; ・ω・)
0597名無しさん@お腹いっぱい。2012/08/09(木) 21:56:40.30
終了したからいいよね。named pipeだった時の
>>541の後始末のタイミングは?
0598名無しさん@お腹いっぱい。2012/08/09(木) 22:20:41.64
よく知らんけど、たぶん、named pipe を使ったプロセス置換の実装の場合、
>>541 は、うまく動かない可能性もあるんじゃないかな。
まだ使用する前なのに消されてしまうことがあると予想。

ただ、コマンド hoge が既に named pipe をオープンし終えていれば、
ディレクトリツリーから named pipe が消されても、named pipe の実体は
残っている。その場合は動く。
というわけで、これは 消される前にオープンできるか否かという
race condition があるケースであり、うまいこと動くこともあるとは思う。

named pipe ではなく、pipe と /dev/fd/ を使った実装なら、
そういう race condition なしで動くだろうけど。
0599名無しさん@お腹いっぱい。2012/08/09(木) 22:32:03.31
>>598
<(...) や >(...) が named pipeで実装されてるFreeBSDのbashでちょっと
試してみたが、daemonみたいに子が先にexitして孫が残るケースでも無問題。

どうやら、named pipeに対する読み手と書き手が揃ってパイプがつながった段階で
unlink(2)される模様。プロセス実行中に先にunlinkされてる。
0600名無しさん@お腹いっぱい。2012/08/09(木) 22:34:14.50
検証どうも。
以外な結果だなあ。
孫が、引数をオープンする前に、たとえば10秒くらい待つような場合、
named pipe を管理するシェルはずっと待機しているってこと?
0601名無しさん@お腹いっぱい。2012/08/09(木) 22:35:20.24
おまえらのために実験してやったぞ
シェルの実装依存だ

zsh: 親が死んだらさっさと消す
bash: みんな死んでもbash自体が終了しても消さない
他は誰か試せ

テストコード
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
void check(char *path) {
if (access(path, F_OK) == 0) printf("%s exists\n", path);
else printf("%s does not exist\n", path);
}

int main(int argc, char *argv[]) {
sleep(1); check(argv[1]);
sleep(1);
if (fork()) {
printf("forked\n");
sleep(1); check(argv[1]);
sleep(1); printf("parent exits\n");
exit(0);
} else {
sleep(3); check(argv[1]);
sleep(1); printf("child exits\n");
exit(0);
}
}
0602名無しさん@お腹いっぱい。2012/08/09(木) 22:39:20.34
>>600
読み手と書き手が揃わない場合は、named pipe は放置されるww

例えば、
bash$ ls <(:)
bash$ exit

なんてやると、lsコマンドも :コマンドもnamed pipeにアクセスしないから、
/tmp/np-sh-XXXXX みたいなファイルが残ったまま bashが終了できてしまう。
bash終了時にはunlinkしないみたい。
0603名無しさん@お腹いっぱい。2012/08/09(木) 22:42:25.58
cat <(ls)
でも残るんだが
0604名無しさん@お腹いっぱい。2012/08/09(木) 22:42:51.12
> 読み手と書き手が揃わない場合は、named pipe は放置されるww

これはひどいw
FreeBSD でも /dev/fd/ が実際にはあるわけだから、named pipe じゃ
なくて、そっち使うように直した方がいいんじゃ。
0605名無しさん@お腹いっぱい。2012/08/09(木) 22:46:21.67
>>603
残らないよ。(bash/FreeBSDで)
0606名無しさん@お腹いっぱい。2012/08/09(木) 22:48:04.29
> cat <(ls)
> でも残るんだが

FreeBSD-7.3 + bash-4.0.24 の組合せで確認した。
確かに /var/tmp/sh-np-数字 という名称で残る。

>>605
バージョンは?
0607名無しさん@お腹いっぱい。2012/08/09(木) 22:50:00.77
>>604

ls /dev/fd 3< file

↑これとか実行してみるとわかるが、
FreeBSDの /dev/fd は、0 1 2 しかファイル記述子に対応してない。(3以降ダメ)
0608名無しさん@お腹いっぱい。2012/08/09(木) 22:50:56.70
>>606
FreeBSD-8.1 bash-4.1.7
0609名無しさん@お腹いっぱい。2012/08/09(木) 22:55:26.55
>>607
マジか、知らなかった… が、確かにそのようだ。確認した。
NetBSD あたりから動く実装持ってくればいいのに。
NetBSD の方では、zsh も bash も /dev/fd/ 使ってる。
0610名無しさん@お腹いっぱい。2012/08/09(木) 22:58:20.47
bash-4.2.37/FreeBSD-9.0だけど残る
0611名無しさん@お腹いっぱい。2012/08/09(木) 23:02:10.30
よくよく確認したら、3以上のディスクリプタについても、
FreeBSD-4.3 なら動いたよ。
/dev/fd/* の実体はキャラクタ型のデバイス・ファイルなので、
デバイス自体はたぶん FreeBSD-7 でも動くんじゃないかな。

つまり、devfs 導入時にデグレったんだ、これ。
0612名無しさん@お腹いっぱい。2012/08/09(木) 23:05:07.38
FreeBSD-7.3 上で bash-4.2 の配布物そのままを野良ビルドしてみたが、
やっぱり named pipe が /var/tmp/ に残るね。
bash のバージョンの違いが原因ではなさそう。
0613名無しさん@お腹いっぱい。2012/08/09(木) 23:10:05.47
残らないという環境の>>608は、何が原因なんだろう
そもそも、bashに、named pipeの中身が書かれたり読まれたという事実がわかるのか?
0614名無しさん@お腹いっぱい。2012/08/09(木) 23:14:54.36
> そもそも、bashに、named pipeの中身が書かれたり読まれたという事実がわかるのか?

そう、自分もそれが疑問だった。
kqueue(2) にはそういう機能なさそうだから、無理じゃないか。

まあ kdump(1) と同じことするって手がないわけじゃないが、
bash のやるようなことじゃない。
0615名無しさん@お腹いっぱい。2012/08/09(木) 23:14:56.99
>>613
オレもそれ考えてたんだけど、
named pipeに対して select(2)してパイプがつながったかどうか検出してるとか。
0616名無しさん@お腹いっぱい。2012/08/09(木) 23:15:48.98
cat <(ls) して、しばらくほっといたら消えた!
0617名無しさん@お腹いっぱい。2012/08/09(木) 23:16:35.39
読み手が繋がったことは、それじゃ分からないよ。
書き手についても、書き込みが起こるか、あるいは書き込みオープン後クローズ
されれば分かるけど、書き込みオープンされただけじゃ分からない。
0618名無しさん@お腹いっぱい。2012/08/09(木) 23:41:09.94
bash-4.2.37/FreeBSD-9.0だけど

cat <(ls)
した直後は確実に/var/tmp/sh-np-hogeが残っている。
けど、Enter押して次のプロンプトが出たときに消える。
別の端末でlsして確認した。

: <(ls)
だと消えない。
けど、誰かが cat /var/tmp/sh-np-hoge すると、
次のプロンプトを出すときに消える。

: <(ls)
して、bashをさっさとexitしてしまうと、
誰かが cat /var/tmp/sh-np-hoge しても、永久に残る。

つまり、named pipeを作ったbashが、プロンプトを出すか何かの時点で、
named pipeが読まれたかどうかを確認していることになる。

どうやってかは知らない。
0619名無しさん@お腹いっぱい。2012/08/09(木) 23:51:57.74
そもそも残ってることって問題か?/tmp 以下なら再起動で消えそうだけど
別の話だけど、名前付きパイプだと全く関係の無い別のプロセスからも
読み書きできるから大丈夫なのって思う
0620名無しさん@お腹いっぱい。2012/08/09(木) 23:58:35.21
パーミッションが自分にしか出てないからいいんじゃない?
0621名無しさん@お腹いっぱい。2012/08/10(金) 00:09:04.36
>>609
kldload fdescfs
0622名無しさん@お腹いっぱい。2012/08/10(金) 00:39:28.35
dbus-*地獄とか勘弁w
0623名無しさん@お腹いっぱい。2012/08/10(金) 01:00:01.40
/var/tmpだから再起動じゃ消えない。
頻繁に呼ばれるCGIとかでこれが起きたらやっぱりやだよ。
0624名無しさん@お腹いっぱい。2012/08/10(金) 01:06:07.46
bashのソース(subst.c)読んだ。自分用まとめ。

・ <(hoge) が出てくると、mkfifoしてforkする。
・ 親シェルはそのfifoと子シェルpidをひもづける。
・ 子シェルはそのfifoをwrite openする。
・ fifoのwrite openは、readするプロセスがいなければブロックされる。
・ だから : <(hoge) だと、hogeは起動されず、子シェル状態のまま。
・ readするプロセスが現われたら、openが成功し、dup2してstdoutにつなぐ。
・ parse_and_executeを呼んで中でforkしてhogeを実行する。
・ hogeが終わったら子シェルは死ぬ。
・ 親シェルは定期的(コマンド起動のタイミングとか)にfifoにひもづけられた子シェルの状況を調べて、死んでたらfifoをunlinkする。
0625名無しさん@お腹いっぱい。2012/08/10(金) 01:13:15.04
bash実装の場合、ソース読むと、
コマンド列の最後のコマンド終了した時に消してるみたい。
0626名無しさん@お腹いっぱい。2012/08/10(金) 01:18:16.27
そだね。
cat <(ls)
だと、子シェルが死ぬタイミングがちょっと遅れるみたいで、
直後にはfifoがunlinkされない。
cat <(ls); sleep 1
だと、確実に残らない。
0627名無しさん@お腹いっぱい。2012/08/10(金) 01:19:10.77
結論としてnamed pipe版プロセス置換はカス。でいい?
0628名無しさん@お腹いっぱい。2012/08/10(金) 01:21:11.65
>>627
OK! おやすみ!
0629名無しさん@お腹いっぱい。2012/08/10(金) 01:34:51.13
最近のFreeBSDではmount -t fdescfs fdescfs /dev/fd
してからbashを作るとpipe+/dev/fdで作成される。
0630名無しさん@お腹いっぱい。2012/08/10(金) 01:39:01.51
>>629
コンパイル時決め打ちだからちょっとまずいね。
0631名無しさん@お腹いっぱい。2012/08/10(金) 01:58:31.64
send-prしといて
0632名無しさん@お腹いっぱい。2012/08/10(金) 07:29:33.75
質問させてください。

現在、'nc -l 12345'コマンドを発行し、それに対しsocket通信を行い、期待した通信が行われているか確認しています。
しかし、上記コマンドでは1回closeしてしまうと、上記コマンドも終了してしまいます。
連続的にsocket通信を行い、期待した結果が入っているかチェックを行いたかったので、以下のようなスクリプトを書きました

while :
do
  `nc -l 12345`
done

しかし、上記を実行して、socket通信を行うと、なぜか、送信したデータを表示するのではなく、実行しようとして、エラーメッセージが出ます
socket通信を受けるたびに、nc -l... コマンドを発行し通信内容を表示するにはどうすればいいのでしょうか?

よろしくお願いいたします。



0633名無しさん@お腹いっぱい。2012/08/10(金) 07:34:47.58
>>632

` ` が余計だろ。
0634名無しさん@お腹いっぱい。2012/08/10(金) 07:57:12.67
>>632
わざわざシェルスクリプトにしなくても、

nc -k -l 12345

を発行(笑)すればcloseしても終了しないよ。
0635名無しさん@お腹いっぱい。2012/08/10(金) 13:05:30.89
発行って言葉使っちゃいかんの?
0636名無しさん@お腹いっぱい。2012/08/10(金) 13:07:59.84
コマンドは普通は「実行」する。
0637名無しさん@お腹いっぱい。2012/08/10(金) 13:23:20.11
起動だな
0638名無しさん@お腹いっぱい。2012/08/10(金) 13:32:30.35
execute
■ このスレッドは過去ログ倉庫に格納されています