トップページ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/
0462名無しさん@お腹いっぱい。2012/07/30(月) 09:54:33.32
echo


OPERANDS
The following operands are supported:
string
A string to be written to standard output. If any operand is -n,
it will be treated as a string, not an option.
The following character sequences will be recognised within any of
the arguments:

\a Write an alert character.


-nはオプションじゃなく文字列として扱え、
以下の(\)シーケンスを認識しろ、

と書かれてるね。
0463名無しさん@お腹いっぱい。2012/07/30(月) 09:59:16.71
それはここでbash依存の質問をしてくるようなもんw
0464名無しさん@お腹いっぱい。2012/07/30(月) 10:06:31.42
>>461
FreeBSDが使っている事と「POSIXだけ守ってれば良い」は全く独立なわけだが。

>>462
それはSUSv2。POSIXじゃない。
0465名無しさん@お腹いっぱい。2012/07/30(月) 10:07:00.53
お前ら、ちゃんとdashのことも考えろよな
0466名無しさん@お腹いっぱい。2012/07/30(月) 10:14:40.58
>>464
いや、ここでは「POSIXだけ守ってれば良い」が否定されればそれでいいので
もう結論が出たよ。

>それはSUSv2。POSIXじゃない。
いや、POSIXだよ。1997年のだけど。
少なくともこの時点でのPOSIXがこんなことを言ってたんだから、
役に立たないというのも判ろうもの。
0467名無しさん@お腹いっぱい。2012/07/30(月) 10:16:54.62
>>457
> FreeBSDのashにはprintfが組み込まれてない(外部)ので、
> printfの使用はパフォーマンス的にダメージ。

微妙にダウトだな。
FreeBSD 9.0 からは printf は builtin に戻ったよ。
FreeBSD 4.X までも builtin だったので、5.X〜8.X の間は外部コマンド。
まあ builtin から外したのが判断誤りだったってことだな。
NetBSD の場合、昔からずっと builtin のまま。

> 実際、FreeBSDのスクリプトはechoが多用されてる。

OS 附属のスクリプトは、implementation-defined な仕様を利用してもいい
んだよ。undefined な仕様を利用するのは駄目だが。
0468名無しさん@お腹いっぱい。2012/07/30(月) 10:22:50.67
>>467
>OS 附属のスクリプトは、implementation-defined な仕様を利用してもいい
>んだよ。undefined な仕様を利用するのは駄目だが。

後出し条件追加ですか?w
0469名無しさん@お腹いっぱい。2012/07/30(月) 10:33:03.72
>>それはSUSv2。POSIXじゃない。

> いや、POSIXだよ。1997年のだけど。

さらっと嘘書くなよ。

ttp://en.wikipedia.org/wiki/Single_UNIX_Specification
にちゃんと、
・1997: Single UNIX Specification version 2
・2001: POSIX:2001, Single UNIX Specification version 3
 Beginning in 1998, a joint working group known as the Austin Group
 began to develop the combined standard that would be known as the
 Single UNIX Specification Version 3 and as POSIX:2001 (formally:
 IEEE Std 1003.1-2001).
って、書いてあるだろ。SUS と POSIX が統合されたのは、SUSv3 から。
SUSv2 は POSIX じゃない。

で、SUSv3 の echo の仕様
ttp://pubs.opengroup.org/onlinepubs/009695399/utilities/echo.html
には、ちゃんと implementation-defined って書いてある。
0470名無しさん@お腹いっぱい。2012/07/30(月) 10:40:01.92
>>OS 附属のスクリプトは、implementation-defined な仕様を利用してもいい
>>んだよ。undefined な仕様を利用するのは駄目だが。

> 後出し条件追加ですか?w

オイオイ、規格書の読み方も知らんのか…
もし implementation-defined な仕様の利用が許されないのなら、
そもそも、なんでわざわざそんな仕様を決めるんだよ。
状況が許せば使っていいからに決まってるだろ。
規格書読む上では、implementation-defined と unspecified と undefined の
違いくらい常識だから、勉強しておくように。
0471名無しさん@お腹いっぱい。2012/07/30(月) 10:45:07.83
>>470
論点がずれてるし、そんなこと言ってないよ。

「POSIXだけ守ってれば良い」という命題が否定されたので議論終了。
0472名無しさん@お腹いっぱい。2012/07/30(月) 10:51:04.06
>>471

嘘書いておいて、謝罪もなしか、厚顔無恥とはお前のためにあるような
言葉だな。

> 論点がずれてるし、そんなこと言ってないよ。
> 「POSIXだけ守ってれば良い」という命題が否定されたので議論終了。

論点がずれているのは、おまえさんの方。
もともと「POSIXだけ守ってれば良い」っていうのは、
「ポータブルなスクリプトを書く」という目的を達成するための手段の話だ。

FreeBSD の OS 附属のスクリプトなんて、ポータブルである必要がそもそも
全くない。シェルは ash、OS は FreeBSD だけ考えれば十分だ。
だから、POSIX を守る必要なんてそもそもない。
そういうものを挙げて「POSIXだけ守ってれば良い」っていう意見への反論だと
思うってことは、お前がそもそも、何の話をしているのか理解してないって
ことだな。
0473名無しさん@お腹いっぱい。2012/07/30(月) 10:54:17.05
>>472
>だから、POSIX を守る必要なんてそもそもない。


POSIXを守る必要なんてそもそもないんですね、駄目押しありがとう。
0474名無しさん@お腹いっぱい。2012/07/30(月) 11:01:41.95
家内制手工業に従事する自称プロは「POSIXだけ守ってれば良い」とかいう
命題勝手に作り出してそれを強制終了する以外にチンケなプライド守る方法が
無くなってしまったんだよ。

元々の噴飯ものの主張が
>>390
> ・bash/zsh/kshの共通項に合わせる
> か、
> ・純shに合わせる
> かの2択。
それで、共通項は手作業でAND取るんだって。プロwww
これでechoにかかわる非互換はどう解消されるんだろう。
0475名無しさん@お腹いっぱい。2012/07/30(月) 11:03:16.64
なんだ、最初から「FreeBSD でだけ動けば良いスクリプト」の話をしてたのかよ。
そういう限定した話を、OS限定しないスレで明示せずに主張してたのか。
悲しい奴だな。

一応指摘しておくが、たとえ「FreeBSD でだけ動けば良いスクリプト」を書く
場合でも(POSIX を守る『必要』はないが)、「POSIX を読んで理解しておく」
方がいいことは明白だ。
POSIX を参照せず、個々のシェルのマニュアルだけ読んでいるってのは、
C++言語の仕様も知らずに、Visual C++ のマニュアルだけ読んでるってのと
同じで、全く褒められた話じゃないからな。
もちろん、ash/bash/zsh すべてで動くスクリプトを書くつもりがあるのであれば、
たとえ FreeBSD 限定であっても POSIX を読んでおいた方がいい。その方が
知識取得の効率がいいからな。
ash/bash/zsh すべてのマニュアルを読んでおくのも勿論良い姿勢で、これまで
それで済んでいたのは分かるが、効率の点からは POSIX を読まないというのは
損であるとしか言いようがない。まあ自分の時間を無駄にしたいのであれば、
それでも構わんが、一般論としてスレでそれを主張するのはやめとけ。
0476名無しさん@お腹いっぱい。2012/07/30(月) 11:03:31.55
>>474
>これでechoにかかわる非互換はどう解消されるんだろう。

AND取る時点で自動的に解消されてるよ。
0477名無しさん@お腹いっぱい。2012/07/30(月) 11:06:07.21
>>476
はあ?
bash/ksh/zsh/ashで動くスクリプト要求されたらどうするんですかあ?
ANDが空集合だから出来ません。と断るんですか? www
プロは仕事を選ぶ www
0478名無しさん@お腹いっぱい。2012/07/30(月) 11:09:55.97
なんでこうトロくさいやり方に固執するかねえ。まあ、これまで うまく
いってたやり方を続けたいってのは人間の性質としてありがちではあるが。

ちょっと考えれば全部読んでANDするなんて効率悪いことぐらい分かりそうなのに。
エンジニアだったら、時間を効率的に使うことが美徳であることくらい知ってる
だろうに、恥ずかしくならないのかな。
0479名無しさん@お腹いっぱい。2012/07/30(月) 11:11:49.79
>>477
実際にAND取ってみればわかるが、空集合にはならない。
その集合だけでOKの用途の場合はechoを使う。
そうじゃない場合はecho以外の手段を使う。

ところが、POSIX至上主義だとimplementation-definedと書かれてるだけで
何の解決にもならない。批判してるのはそういう点だよ。
0480名無しさん@お腹いっぱい。2012/07/30(月) 11:14:59.11
> ところが、POSIX至上主義だとimplementation-definedと書かれてるだけで
> 何の解決にもならない。批判してるのはそういう点だよ。

いや、POSIXに従うのであれば printf を使えば解決する。FreeBSD でも動くよ。

まあ FreeBSD 5.X〜8.X では、ちょっと遅いが、それは FreeBSD が一時期、
判断間違えてただけの話(しかも、もう直ってる)。
FreeBSD 5.X〜8.X 固有のマイナーな問題点を、OS を限定しないスレで主張すんな。
0481名無しさん@お腹いっぱい。2012/07/30(月) 11:16:06.92
> その集合だけでOKの用途の場合はechoを使う。
> そうじゃない場合はecho以外の手段を使う。
ぷぷぷ、POSIXと同じこと言ってることに気づいて無いの。 www
0482名無しさん@お腹いっぱい。2012/07/30(月) 11:20:56.87
> ぷぷぷ、POSIXと同じこと言ってることに気づいて無いの。www

ご苦労さんとしか言いようがないよなあ。
POSIX にズバリそのまま書いてあることを、3つのマニュアルを見比べて、
自分の頭の中でANDするという手間ヒマかけて再発見とか。
まあ、それだけ暇な仕事なんだろう。ある意味うらやましいな。
真似は絶対したくないがw

0483名無しさん@お腹いっぱい。2012/07/30(月) 11:27:08.81
>>477 ってPOSIX読んでないだろ。
指摘されるまで AND取ったら空集合だと思い込んでたみたいだし。
0484名無しさん@お腹いっぱい。2012/07/30(月) 11:48:32.16
>>483
はあ? AND取るのにPOSIXは関係ありませんが。
4つのシェルのANDとるなんてバカな作業はもちろんやったことないですけど。www
0485名無しさん@お腹いっぱい。2012/07/30(月) 11:50:29.32
4つのシェルの仕様のANDをとるのがバカだということは分かるのに、
3つのシェルの仕様のANDをとるのはバカじゃないって思ってんの?
フツー1つの仕様(POSIX)読んで終りだろう、常識的に考えて。
0486名無しさん@お腹いっぱい。2012/07/30(月) 11:54:55.78
>>485
やだなあ。レス番よく追ってよ。僕(>>477)は、3つのシェルの仕様のANDを
取ってる自称プロを弄ってた方だよ。
0487名無しさん@お腹いっぱい。2012/07/30(月) 12:02:20.94
あ、そういうことか。勘違いした。
まあ >>477 の主張はちょっと不明確な気がする。
4つのシェルの仕様のANDとって、空集合になるなんてことはあまりない
(だいたいは代替手段がある)ので、何が言いたいのか分からないな。
4つのシェルの仕様をちゃんと読めば、目的が果たせることには変わりない。
問題なのは、それがとんでもない時間の無駄使いだってことだろう。
0488名無しさん@お腹いっぱい。2012/07/30(月) 12:02:51.87
POSIXでは、echoの引数に -n が(最初に)使われてる場合、
または
バックスラッシュが使われている場合が implementation-defined
と書かれている。

実はこれダウトなんだよ。
bashやzshのechoとか、-E (大文字)も特別扱いするから、(-eもだけど)

echo -E は、POSIXで言うところのimplementation-definedに該当しないはずなのに
ポータビリティーがない。

-E -e の件はPOSIX読んだだけでは書かれていないから、
正確なことを知るには自分でAND取るしかない。
0489名無しさん@お腹いっぱい。2012/07/30(月) 12:08:03.50
うん、今のたいていのシェルはPOSIX準拠だからね。ANDをとればPOSIXになる。
でも、自称プロは自分でANDを取る。 w
延べ数千人のレビューを経たPOSIXより、自分でANDを取った規約の方が上。
0490名無しさん@お腹いっぱい。2012/07/30(月) 12:11:17.53
>>489
延べ数千人のレビューを得ても echo -E / echo -e を見落としたんですか?
0491名無しさん@お腹いっぱい。2012/07/30(月) 12:18:41.90
> -E -e の件はPOSIX読んだだけでは書かれていないから、
> 正確なことを知るには自分でAND取るしかない。

お、珍しくマトモな意見だな。
POSIX の仕様が -n に限ってるのは、BSD の仕様をベースにしてるからだな。
だから *BSD で /bin/sh 使う分には POSIX だけで OK だけど、bash や zsh
だとまずい。
実際、俺は - で始まる文字列は単に避けるか、どうしても必要な場合は
printf 使うようにしてるんだよね。

規格は基本、実装の後追いだから、Linux 起源の仕様がどんどん POSIX に
採り入れられている現状からして、そのうち、echo の仕様も訂正されるん
じゃないかな。(でも getline(3) みたいなウンコはやめて欲しかったがなorz)

こういう齟齬は避けられないから、テストは不可欠だし、できれば各シェルの
マニュアルも確認しておいた方がいい。
でも、順番としてはまず POSIX が最初で、各シェルのマニュアルを参照するのは
後だよ。こういう例外を除き、ほとんどの場合、POSIX が仕様の AND をとっていて
くれるので、その方がずっと効率がいいからな。

だから、「各シェルのマニュアルも読んだ方がいいよ」って言うのなら主張として
いいんだよ。だが「POSIX は要らん。各シェルのマニュアルのANDだけで良い」と
いう主張はおかしい。まず最初に POSIX を確認すべき。
「各シェルのマニュアルのAND」は最後でいい。テストでコケるまで参照しなくても
いいくらいに優先順位が低い。

0492名無しさん@お腹いっぱい。2012/07/30(月) 13:58:58.26
むしろFreeBSDやashが排除されるのが合理的。
0493名無しさん@お腹いっぱい。2012/07/30(月) 14:03:07.82
FreeBSDだけやったところで、NetBSD, OpenBSD, DragonflyBSD,
それに Debian GNU/Linux があるぜ。
まあ FreeBSD だけに限っても無理だろうけど。
0494名無しさん@お腹いっぱい。2012/07/30(月) 22:42:54.26
ポータブルなスクリプトを作るってスペースを減らすしかないんじゃないの?
0495名無しさん@お腹いっぱい。2012/07/30(月) 23:13:07.54
んっ…はぁっ、あっ
0496名無しさん@お腹いっぱい。2012/07/31(火) 00:37:56.28
そもそも改行無しのechoなんて使わなきゃいいのに
0497名無しさん@お腹いっぱい。2012/07/31(火) 00:57:04.92
posixシェルを否定する唯一の材料みたいだからね。
ANDとる作業で工数水増ししてるのかもね。w
0498名無しさん@お腹いっぱい。2012/07/31(火) 01:04:07.56
すみませn
""rm
という記述を見たんですが、""ってなんか意味があるんでしょうか?
0499名無しさん@お腹いっぱい。2012/07/31(火) 02:14:35.41
rmがaliasになってるときにaliasを展開しないためじゃないかな
0500名無しさん@お腹いっぱい。2012/07/31(火) 06:30:16.07
シェルスクリプト中で alias使うってすごいな。
0501名無しさん@お腹いっぱい。2012/07/31(火) 12:35:16.71
>>500
だからだろ
0502名無しさん@お腹いっぱい。2012/07/31(火) 12:46:26.03
シェルスクリプト中でジョブコントロールには勝てないだろw
0503名無しさん@お腹いっぱい。2012/07/31(火) 14:19:59.11
ジョブコントロールはふつーに使うでしょ。
なんか重い処理を並列で走らせるときに

cmd1 &
cmd2 &
cmd3 &
wait

みたいな感じで。
0504名無しさん@お腹いっぱい。2012/07/31(火) 14:34:56.99
>>503
それジョブコントロールちゃう。ただのバックグラウンド。

SIGTSTPで止めてバックに回して、
あとで fgしたりするやつ。
0505名無しさん@お腹いっぱい。2012/07/31(火) 15:01:13.63
>>504
節子、を付けるべきだなw
0506名無しさん@お腹いっぱい。2012/07/31(火) 15:07:12.60
バックグラウンドで動かすのもジョブコントロールの一部でしょ。
0507名無しさん@お腹いっぱい。2012/07/31(火) 15:16:47.63
>>506
ちがう。

決定的な違いはプロセスグループIDの処理。
ジョブコントロールの場合は各コマンドのプロセスグループIDを別々にして、
親のシェルからは独立する。ttyの端末プロセスグループIDを
フォアグラウンドプロセスと同一にし、管理を行なう。

一方、ジョブコントロールなしの場合は、fork/execのあと、
単にwaitしないというだけの処理で、プロセスグループIDは親シェルと同じ。
だから、Ctrl-Cで同一プロセスグループIDのプロセスが死なないように
&を付けたコマンドはSIGINTを無視するようにしている。
(ジョブコントロール有りの場合はSIGINTはそのまま無視しない)


ジョブコントロールは、今のシェルなら set +m で無効にできる。
set +m でジョブコントロール無効にした状態でも
& や waitは実行できる。

純正/bin/shにはジョブコントロールがなかったが、
& や waitは当然実行できる。
0508名無しさん@お腹いっぱい。2012/07/31(火) 15:31:33.28
>>499
それって\の方がシンプルだよね?
0509名無しさん@お腹いっぱい。2012/08/01(水) 22:19:00.88
MNT=$(mount | grep "rootfs/proc")
if [ -z "$MNT" ]; then
mount -t proc proc ../rootfs/proc/
fi
この構文は短縮できないんでしょうか
0510名無しさん@お腹いっぱい。2012/08/01(水) 22:22:35.02
>>509
mount | grep -q 'rootfs/proc' && mount -t proc proc ../rootfs/proc
05115102012/08/01(水) 22:23:46.64
&&ではなく、
|| に。
05125092012/08/01(水) 22:32:13.39
>>510
ははあー
0513名無しさん@お腹いっぱい。2012/08/02(木) 08:59:36.06
いちいち判定しなくても二重にマウントされることはないんだから、
mount -t proc proc ../rootfs/proc/ >/dev/null 2>&1 || :
でいいじゃね?
0514名無しさん@お腹いっぱい。2012/08/02(木) 09:25:31.26
いちいち||判定しなくても最後のステータスが有効なんだから、
mount -t proc proc ../rootfs/proc/ >/dev/null 2>&1; :
でいいじゃね?
0515名無しさん@お腹いっぱい。2012/08/02(木) 09:28:56.05
書き込んだらセミコロン(;)消えた、、まあ、set -eなんてしてないという前提で。
0516名無しさん@お腹いっぱい。2012/08/02(木) 20:18:32.37
jikken () {
command hoge $@
}
という関数を定義してたんですが

jikken -m "" -n "" unko

というコマンドを実行すると
hoge -m -n unko
というコマンドの実行になってしまうんですよね。
引数をきっちり hoge に渡すには
どうしたらいいんですかね
0517名無しさん@お腹いっぱい。2012/08/02(木) 20:24:44.26
command hoge "$@"
0518名無しさん@お腹いっぱい。2012/08/02(木) 20:29:19.70
>>517
ありがとう
0519名無しさん@お腹いっぱい。2012/08/08(水) 12:58:57.06
bash だと変数の部分文字列を ${a:m:n} で取得できるけど、
同じことを bash の拡張機能を使わず、かつ内部コマンドだけでやる方法ってないかな?

いまは echo $a | cut -c$x-$y でやってるけど、
スクリプト中で何百回と呼ばれていて、これのせいでかなり速度が遅くなっちゃってる。
0520名無しさん@お腹いっぱい。2012/08/08(水) 13:18:46.05
>>519
頭の3文字と後ろの2文字をカットしたい場合、

a=ABCDEFG
b=${a#???}
echo "${b%??}"

みたいにするしかないかな。この例では DE が残る。
0521名無しさん@お腹いっぱい。2012/08/08(水) 14:17:12.55
ありがとう。それは考えたんだけど、位置を数値指定したいんだよね。
? を指定回数数並べた文字列を作るのにまためんどくさい手間がかかるのはちょっと。

とはいえ、やっぱり方法はそれしかないよなぁ。
0522名無しさん@お腹いっぱい。2012/08/08(水) 14:18:52.44
>>521
printf %.5s '??????????????'

で5個の ????? が得られるよ。
0523名無しさん@お腹いっぱい。2012/08/08(水) 14:20:25.24
欲しいのはこっちだろ
printf "%.*s" 5 '?????????????????????????????'
0524名無しさん@お腹いっぱい。2012/08/08(水) 14:24:59.78
>>523
>>522 で合ってる。 %.${a}s にすればいいだけ
0525名無しさん@お腹いっぱい。2012/08/08(水) 14:35:28.32
おお、ありがとです。なんとかなりそうだ。
0526名無しさん@お腹いっぱい。2012/08/08(水) 15:49:08.27
実行速度が3倍になった。ありがとう。
0527名無しさん@お腹いっぱい。2012/08/08(水) 21:33:50.42
名前付きパイプの使い方を修得した (`・ω・´)

一時ファイルの代わりにこれを使えばHDDガリガリしなくて済むんだよね?
0528名無しさん@お腹いっぱい。2012/08/09(木) 00:33:59.19
まあその通りだが、いまのシェルだと
diff -u <(ls /old) <(ls /new)
とかできるから、わざわざ名前つけたりは、ほとんどしなくなったなあ。
0529名無しさん@お腹いっぱい。2012/08/09(木) 06:48:33.30
>>528 のことを「名前付きパイプ」って呼んでる可能性もあるわけで・・
(mkfifoのことじゃなくて)
0530名無しさん@お腹いっぱい。2012/08/09(木) 10:01:01.43
そうだとすると言葉の誤用なので (実装は pipe(2)でできるし)、
それはないと思いたいところだけどなあ。どうだろね。
0531名無しさん@お腹いっぱい。2012/08/09(木) 10:45:19.41
>>530
実装依存だな。(言葉の誤用ではない)
FreeBSDだと本当にnamed pipeで実装されてるよ。

bash$ file <(:)
/tmp/sh-np-4033202023: fifo (named pipe)
0532名無しさん@お腹いっぱい。2012/08/09(木) 10:57:37.18
コマンドがパス名を必要としている引数位置で使うのに、
どうやってnamed pipe以外で実装するんだよ。
0533名無しさん@お腹いっぱい。2012/08/09(木) 10:59:51.72
>>532
Linuxだと、普通のpipeで実装して、それを/dev/fd/n(/proc/self/fd/n)経由で参照する 。
だからnamed pipeにする必要はない。
0534名無しさん@お腹いっぱい。2012/08/09(木) 11:09:46.25
Named pipeの後始末は誰がする?
0535名無しさん@お腹いっぱい。2012/08/09(木) 11:47:08.57
私自らが処罰を与える
0536名無しさん@お腹いっぱい。2012/08/09(木) 11:49:03.21
>>531
いや、実装依存だから、名前の誤用なんだよ。
「<(コマンド)」の実装に常に named pipe が必要ならばともかく、
pipe(2) で実装されたり named pipe で実装されたりするものを、
named pipe って呼んじゃ駄目でしょ。
0537名無しさん@お腹いっぱい。2012/08/09(木) 11:50:51.69
>>534
「<(コマンド)」の場合なら、これを解釈するシェルが始末する。

自力で named pipe 作ってるシェルスクリプトなら、ふつうは
そのスクリプトの中で trap とか使ってやるんじゃない?
(named pipe の目的にもよるので状況によりけりだけど)
0538名無しさん@お腹いっぱい。2012/08/09(木) 12:06:58.48
>>536
もともと「named pipeを自動で」という設計思想で設計されたものだから、
結果の実装がどうあれ、named pipeと呼んで良い。
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ループ始まるより遅いってこと?
■ このスレッドは過去ログ倉庫に格納されています