[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 12:29 / Filesize : 215 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

UNIXプログラミング質問すれ Part5



1 名前:名無し募集中。。。 [05/01/15 02:18:37]
UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド

前スレ
Part4 pc5.2ch.net/test/read.cgi/tech/1095843584/
Part3 pc5.2ch.net/test/read.cgi/tech/1085930894/
Part2 pc5.2ch.net/test/read.cgi/tech/1055110889/
Part1 pc2.2ch.net/tech/kako/992/992057422.html

Part3のミラー
makimo.to/2ch/pc5_tech/1085/1085930894.html
Part2のミラー
makimo.to/2ch/pc5_tech/1055/1055110889.html

関連スレ
Cygwin使っている人いますか? その13 (UNIX板)
pc5.2ch.net/test/read.cgi/unix/1099157755/
Cygwin使っている人いますか? 3 (Windows板)
pc5.2ch.net/test/read.cgi/win/1090131123/

関連板
pc5.2ch.net/unix/
pc5.2ch.net/linux/


189 名前:デフォルトの名無しさん mailto:sage [05/02/18 09:30:24 ]
>>184
psで見れるのはどのUNIXでもargv[0]だと思う。

190 名前:デフォルトの名無しさん mailto:sage [05/02/18 10:20:06 ]
んだから、unixのファイルシステムでは、
1このファイルに対してファイル名(パス)がいくつでもつけられるから、
実行ファイルのある場所は?っていう質問には無理があるのよ。

実行ファイルといっしょに置いた設定ファイルを使おうとした場合、
最悪でも今のPATHと照らし合わせれば、どのファイル名で実行されたかは
わかるだろうけど(which)、そこに一緒に置かれた設定ファイルが
あるかどうか保証できないじゃん。


191 名前:デフォルトの名無しさん mailto:sage [05/02/18 10:54:10 ]
>>190
というか、ユーザー空間からpathnameを取得するための関数って
POSIXには含まれてないの?pathnameの有効性ともかくとしてさ。

192 名前:デフォルトの名無しさん mailto:sage [05/02/18 10:57:22 ]
man 〜すると、
| pathnameの有効性はともかく、こうなります
って書いてあんのかよ…いらねーよ。つーか有害。


193 名前:デフォルトの名無しさん mailto:sage [05/02/18 11:01:41 ]
>>192
なにを言ってるのかよく分らないんだけど、
execveシステムコールを発行する時点で、
pathnameは決まってるんじゃないの?だったら
それをユーザー空間から取得できるよう、共通のインターフェイスを
提供してもいいんじゃないの?っていう話なんだけど。

194 名前:117 = 124 mailto:sage [05/02/18 11:13:30 ]
♪ 喧嘩をやめて〜 二人を止めて〜
♪ 私のため〜に〜 争わな〜い〜で〜

195 名前:デフォルトの名無しさん mailto:sage [05/02/18 11:22:17 ]
>>193
アプリは /usr/xxx/app
設定ファイルは /usr/xxx/app.conf
だとして

ln /usr/xxx/app /usr/bin/app
とやったらどうなのよ?
/usr/bin/app として実行したら
/usr/bin/app.conf は存在しないだろ?


196 名前:デフォルトの名無しさん mailto:sage [05/02/18 11:41:17 ]
>>195
それは「設定ファイルが見付かりません」でいいんじゃないの。

Linux で readlink("/proc/self/exe", ...) するとパスが取れるよう
な仕組みの、共通の API が欲しいぞ、と。



197 名前:デフォルトの名無しさん mailto:sage [05/02/18 11:44:43 ]
それを見付かりませんなんてするよりパスを固定する方がはるかに建設的じゃん。
>>195みたいなのはUNIXでは完全にlegalな使い方なんだから、
それをわざわざ制限するのはアホ。




198 名前:デフォルトの名無しさん mailto:sage [05/02/18 11:53:45 ]
つまり Sun の Java はアホだと。

少ないとは思うけど需要はあるので、共通の手段があってもいいと思う
けどねえ。自分は使わないけど。



199 名前:デフォルトの名無しさん mailto:sage [05/02/18 12:01:48 ]
>>198
いったいいつごろのJavaの話をしているのかねえ。


200 名前:デフォルトの名無しさん mailto:sage [05/02/18 12:11:10 ]
>>198
JDKはその配布形態から定数を埋め込めないが、
代わりにちゃんとJAVA_HOMEという環境変数をみるよ。
それがない場合にやむを得ずdirname $0をとってるだけ。



201 名前:デフォルトの名無しさん mailto:sage [05/02/18 12:26:42 ]
>>196
>>192

202 名前:デフォルトの名無しさん mailto:sage [05/02/18 12:48:45 ]
ちっちゃなアプリなら、インストールパスを固定
(configure 時に --prefix で指定する) で十分だ
と思うけどなあ。そんなに大きなアプリなん?
インストールされた場所から設定ファイルを探すっ
てのは、UNIX 的にはむしろ嫌われることが多い。
どうしてかっていうと、インストールされたもの
は NFS などで共有される可能性があるけど、
設定ファイルは各マシンごとあるいは各ユーザー
ごとで別々にしたいから/etc か $HOME に置くの
が普通だから。

203 名前:デフォルトの名無しさん mailto:sage [05/02/18 12:51:30 ]
大きなアプリで、設定ファイルじゃなくて、アプリ
に附属するデータファイルがあり、その場所を変更
したい場合には、JDK みたいに環境変数で指定可能
にして、環境変数がない場合には wrapper script
経由で dirname $0 を見るってのがまあ習慣。

Linux 方式は、カーネルメモリがちょっと無駄になる
(普通のカーネルは、わざわざ使えないかもしれない
情報を記憶して、物理メモリを無駄にするなんて
ことはしない) ってことの他に、>>126 の言うよう
に chroot 環境からは、そのアプリが使えないって
問題もあるな。


204 名前:デフォルトの名無しさん mailto:sage [05/02/18 12:59:37 ]
あと、だから UNIXは… なんて言ってる Win厨は、
シンボリックリンクがないせいで、固定パス名
(たとえば C:\Program Files\アプリ名\data) から
データを検索するように作ると、起動ドライブにしか
データファイルを置けなくて実用に耐えないとか、
実行中のアプリケーションやDLLを削除することが
できないせいで、セキュリティフィックスを当てる
間は実行中のサービスを止める必要があるし、結局
一度はリブートが必要になることが多いっていう
Windows の欠陥を欠陥だと認識できてないんだと
思うな。

UNIX の場合、プログラム実行中でも削除できてしまう
から、パス名の検索はもともとできない変わりに、
サービスを止める時間はほんとに一瞬で済むし、
リブートは必要ないんだが。

205 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:03:04 ]
ムキになった海栗糞厨の見当違いなWindows批判が始まりました。

206 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:05:36 ]
>>204
NTFS 使ってるならハードリンクもシンボリックリンクも使えるよ。

207 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:05:53 ]
そのへんにしか反応できないって哀しいね。




208 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:10:19 ]
>>206
XPに限定されるけどね。

209 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:13:19 ]
WindowsにUnixスタイルを持ち込むのはアホ。
同じように、UnixにWindowsスタイルを持ち込むのはアホ。
どっちが良いとか悪いとかはケースバイケースでしょ。

210 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:41:18 ]
結局、
できない
ということでまとまりましたか?

211 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:50:34 ]
>>206
シンボリックリンクってどうやるの?
.lnkの話?

212 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:54:17 ]
>>210
wrapperスクリプト経由ならできるでまとまったのでは?

213 名前:デフォルトの名無しさん mailto:sage [05/02/18 13:56:59 ]
つまり、
できないと

214 名前:デフォルトの名無しさん mailto:sage [05/02/18 14:00:18 ]
>>211
ttp://homepage1.nifty.com/emk/symlink.html

215 名前:デフォルトの名無しさん mailto:sage [05/02/18 14:01:26 ]
>>209
そうなんだけどそれがわからん奴が多過ぎ。ム板にあるせいか
自分の無知からくる妄想的な優越感にかこつけて
昏いコンプレックスを晴らそうとする厨が絶えないね。
まあ元から知性に欠けるので馬脚を現しまくりなんだけど。

>>212
まとめは>>202-203だろ。
別にラッパースクリプトでしなければならない必然性はないけどね。
単にそれが手間がかからないからそうすることが多いってだけで。
あえて言えば、Cのコード書くより早いのと、動作を知るのに
特にドキュメントを探し回らなくても読めばわかるってのが利点だね。


216 名前:204 mailto:sage [05/02/18 14:01:34 ]
>>206
ははあ、Windows 2000 からリバースポイントって機能が追加されて
たのか。勉強になりますた。
これって、ディスクが足らなくなって増設した場合とか、画期的に
便利だと思うんだけど、広まってないのはなんでかな?

>>211
support.microsoft.com/default.aspx?scid=kb;ja;JP205524
とか
homepage1.nifty.com/emk/symlink.html
とかあるみたい。
ntfs.sys にパッチを当てないとディレクトリしか指せないみたいだ
けど、ディスクが足りなくなった場合とかはそれでも問題なかろう。

通常はマシンごとにある設定ファイルを、ネットワークで共有したい
から /etc/設定ファイル → /global/etc/設定ファイル みたいな
シンボリックリンクを作りたいっていう要求に相当するのは無理だけ
ど。ファイルを指せないだけじゃなくて、リモートファイルシステム
も指せないみたいだから。


217 名前:デフォルトの名無しさん mailto:sage [05/02/18 14:01:57 ]
FAQ



218 名前:デフォルトの名無しさん mailto:sage [05/02/18 14:17:42 ]
>>215

全然問題を理解してないね
さすがwwwwww

219 名前:デフォルトの名無しさん mailto:sage [05/02/18 14:27:58 ]
>>218
不親切な奴だな。

>>215
wrapper スクリプトの場合は、スクリプトが setuid/setgid
されてない限りは確実に argv[0] にパス名が渡ってくるん
だけど、Cプログラムの場合、argv[0] には基本的にコマンド
名しか渡ってこないから無理なんよ。
まあ、C でも、
1. strchr(argv[0], '/') != NULL なら argv[0]
 からディレクトリを取り出す。
2. さもなくば $PATH から $argv[0] を探し、そこ
 から探す
とすれば、実用上は問題なく探せるわけだが。

220 名前:117 = 124 mailto:sage [05/02/18 16:41:26 ]
もう勘弁してくだせぇ。
「実行モジュールと同一ディレクトリを、設定ファイル置き場のデフォルトに・・」なんて
こたぁ、もう口が裂けても言いませんからぁ・・・
gnu さまに逆らおうなんて気は、毛頭なかったんでごぜーます。 ほんの出来心で・・・
デフォルト位置は、リテラル文字列でソースに梅込みますです。
そのあと、core 吐いて氏にます。

221 名前:デフォルトの名無しさん mailto:sage [05/02/18 16:51:45 ]
釣果に大満足で引き上げる>>220であった。

222 名前:デフォルトの名無しさん mailto:sage [05/02/18 17:24:55 ]
>>219
> だけど、Cプログラムの場合、argv[0] には基本的にコマンド
> 名しか渡ってこないから無理なんよ。

え! もしかして俺はargv[0]に常にフルパスが入ると思ってたとみなされてるわけ?
イヤン。

> まあ、C でも、
> 1. strchr(argv[0], '/') != NULL なら argv[0]
>  からディレクトリを取り出す。
> 2. さもなくば $PATH から $argv[0] を探し、そこ
>  から探す
> とすれば、実用上は問題なく探せるわけだが。

普通そうするでしょ。

> >>215
> wrapper スクリプトの場合は、スクリプトが setuid/setgid
> されてない限りは確実に argv[0] にパス名が渡ってくるん

これって$0のこと? そんなわけないと思うんだけど。
それともスクリプトの側にフルパスで書いてあるからって話?


223 名前:デフォルトの名無しさん mailto:sage [05/02/18 18:00:43 ]
> これって$0のこと?

そうそう。
そう。$0 のこと。書き間違えた。

> そんなわけないと思うんだけど。

いいや、そんなわけある。
でないと、インタープリタ (/bin/sh とか) がスクリプトが
どこにあるか見つけられないでしょ。だから $0 には確実に
ディレクトリ名が渡ってくる。細かいことを言うと $PATH に
カレントディレクトリが入っていて (← これはセキュリティ
ホールだから避けるないとまずい設定だがそれは置いておいて)、
カレントディレクトリのスクリプトを起動した場合には、$0 に
ディレクトリ名が入ってないわけだが、この場合もカレント
ディレクトリにあるスクリプトであるという情報はちゃんと分かる。

wrapper を使うことが結構多いのは、この性質を利用するため。

ただし、セキュアな setuid/setgid スクリプトを実装している
OS 上で、setuid/setgid スクリプトを起動した場合は例外。


224 名前:デフォルトの名無しさん mailto:sage [05/02/18 18:29:57 ]
>>204 == >>216
> >>206
>ははあ、Windows 2000 からリバースポイントって機能が追加されて
>たのか。勉強になりますた。
>これって、ディスクが足らなくなって増設した場合とか、画期的に
>便利だと思うんだけど、広まってないのはなんでかな?

デフォルトフォーマットであるベーシックディスクでは実現出来ないので
ダイナミックディスクにフォーマットコンバージョンする必要がある。
別にディスクの中身が消える訳ではないのだが、変換直前に警告がうるさく
出てくるので普通の人はビビってそこで思いとどまることが多い。
パフォーマンスの低下を心配して思いとどまる人も多いらしい。
私は問答無用でインストール直後にダイナミックディスクにしてます。

225 名前:デフォルトの名無しさん mailto:sage [05/02/18 18:47:33 ]
>>184
FreeBSDで
execlp("./hoge", "/bin/oreore", "oredayo", NULL);
を、じっこうして、
ps -o comm,args すると、該当行の表示は

hoge /bin/oreore oredayo (hoge)
となりますた。(ばれています。)

manによると
> キーワード ucomm (アカウンティング名) は信用できます。
これのaliasのようです。

226 名前:デフォルトの名無しさん mailto:sage [05/02/18 18:47:38 ]
>>223
> > そんなわけないと思うんだけど。
>
> いいや、そんなわけある。
> でないと、インタープリタ (/bin/sh とか) がスクリプトが
> どこにあるか見つけられないでしょ。だから $0 には確実に
> ディレクトリ名が渡ってくる。細かいことを言うと $PATH に

ああ、そうかそうか。PATHの上にある場合は確かにフルパス必要ですね。
なぜか相対パスで叩く場合しか考えてませんでした。納得。

ついでに恥をしのんでおききしますが、

> ただし、セキュアな setuid/setgid スクリプトを実装している
> OS 上で、setuid/setgid スクリプトを起動した場合は例外。

これってどのようなOSでどのような動作をしますか?
私の知識は「最近はセキュリティ上の理由で昔のOSと違って
スクリプトのsetuidビットは無効になる」って10年前ので止まってるんですけど、
最近はその問題を解決した上でスクリプトに立てられたsetuidが有効になるんですか?


227 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:00:48 ]
> これってどのようなOSでどのような動作をしますか?

通常、スクリプトファイルをオープンするのはインタープリタ
の仕事だが、このような OS では、カーネルが直接スクリプトを
オープンし、そのファイルディスクリプタ番号を、インタープリタ
に「/dev/fd/ディスクリプタ」という名称で渡す。

少なくとも、SVR4 と NetBSD では実装してる。
NetBSD はカーネルオプションに SETUIDSCRIPTS と書かない限りは
無効。NetBSD が OpenBSD との分かれる前からある機能なので、
たぶん OpenBSD でも使えるんじゃないかと思う。
10年前でも、SVR4 は間違いなく対応してたと思うけど…
SVR4 直系である Solaris でも勿論使える。



228 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:06:26 ]
>>221
その背後で、魚たちはなおもじゃばじゃばと跳ね続けるのでした。
脱糞。

229 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:15:43 ]
ヂャバジャバ

230 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:18:38 ]
193だけど、誰もこれには真面目に答えてくれないのかな?
カーネル内にプロセスと1:1対応する実行イメージのファイルパスは
保存されてるわけでしょ。なんでそれがユーザー空間から取得できないの?
Win厨とバカにするなら、まずは疑問にはちゃんと答えるべきでしょ。

231 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:23:34 ]
ファイル自体とファイルのパスは1:1対応じゃないと何度いったら

232 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:26:10 ]
パッケージ(アプリ)の置場所を自由に変えるなんて事をしたい場合は、
そのパッケージに依存するパッケージが、
置場所を見つけられるような機構がないとどうにもならない。
そうしないとRPMにあるようなfile単位でのconflict,
dependを扱えなくなってしまうから。

233 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:27:09 ]
>>230
されてない。取得できるとも限らない。
unlink(2)してしまえばfile systemとの関係がなくなるので。

234 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:27:11 ]
なんだかよくわかりませんがWindowsの圧勝ってことにしておきますね。

235 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:27:48 ]
>>230 そういうものを利用するというのが既に挙げられたような具合で
悪習といえるからじゃない?


236 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:28:57 ]
>>231
ハードリンクやchrootでpathnameという文字列の意味自体が変わるってことは分ってる。
知りたいのは、システムコールとして渡った文字列。なんでそれがユーザー空間から
取得できないのかってこと。

237 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:33:29 ]
パスからvnodeを引っ張った後は、もうパスは使わないんじゃないの?



238 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:36:27 ]
>>236
>システムコールとして渡った文字列
これってなんのこと?

239 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:38:55 ]
その通り。だから Linux 以外の UNIX 系 OS では
コマンドのパス名はメモリの無駄だから保存されてない。
>>205にある ucomm は、コマンド名のbasenameの部分
だけでディレクトリは含んでないの。


240 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:42:11 ]
というか、システムコールとして渡った文字列がカーネルに
保存されているとなぜ思ったのかしら。保存しておいても、
あてにならない (コマンド実行中に削除されたりすれば意味が
ない) んだから、保存しておく意味もないんだけど。

Windows の場合、実行中のプログラムの削除ができないから、
保存しておく意味も一応あるだろうけど。

241 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:49:08 ]
>>237,>>239,>>240
ああなるほど。納得した。UNIXのVFSがフレキシブル、
というのをしきりに強調してたのはそういうことですか。

242 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:49:32 ]
Unixだとファイルオープン中に他プロセスからファイルを削除されても問題ないって聞いたけど、
ディレクトリエントリが消えるだけってことかな?
だとすれば、実行モジュールの件もファイル名と実行モジュールが対応しないわけだよね。

243 名前:デフォルトの名無しさん mailto:sage [05/02/18 19:55:18 ]
ファイルは、自分を指しているディレクトリエントリが全部 unlink されて、
自分を開いているプロセスも1個もなくなったら消えます。

一時的に使うファイルを、オープン直後にunlinkしたりするのは昔からけっこうある。
誰にもいじられないし、プロセスが終わると勝手に消える。

244 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:06:01 ]
>>242
その通り。
実行中に改名だってできるし。

245 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:08:07 ]
UNIXのVFSが高度な柔軟性を持っていることはいいとして、
それに対するパスの表現力があまりにも貧弱だっていうことは
ありませんか?。ユーザー空間からは、パスを通してしか
VFSにアクセスできないわけでしょう。かといってパスに変わる
何があるんだって言われると、答えられないけど。

246 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:10:42 ]
>>236
意味のないものを使えるかのように振る舞って、
初級プログラマを悩ませない。
そのような可能性のあるAPIは排除して、
問題のあるプログラムを作成させない。

これは一つの見識。Windowsとは違う点。

247 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:13:48 ]
>>245
パス以外のアクセス手段を用意しようものなら、ディレクトリ階層と
そのパーミッションないしACLに基づいたアクセス制御モデルがご破算に
なりかねませんが。




248 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:16:33 ]
まあ *BSD 系だと、vnode を意味する不透明データ
(handle。ただし Windows でいう HANDLE とは別物)
を指定して直接アクセスする fhopen って機能もある
けどね。>>247の言うようなセキュリティ上の問題が
あるから root だけからしか利用できないけど。


249 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:32:57 ]
結論はWin厨から見たらUNIXは元々うんこな仕様だった、と。
これでいいかな。

250 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:34:49 ]
勝利宣言? 朝鮮人みたい。


251 名前:デフォルトの名無しさん mailto:sage [05/02/18 20:39:33 ]
ウィルスが感染したらひとたまりもありませんね

252 名前:デフォルトの名無しさん mailto:sage [05/02/18 21:38:06 ]
・UNIX は実行中のプログラムの削除や改名ができるが、
 その代わり、プログラムのパス名を求めることができない。
・Windows はプログラムが自身のパス名を求めることができ
 るが、その代わり、実行中のプログラムおよびそれを含む
 ディレクトリの削除や改名ができない。

どっちをウンコだと思うかは人それぞれだと思うが。俺自身はUNIX厨だからセキュリティアップデートで多くの
場合リブートを必要とする Windows の仕様の方がヤだなー。

253 名前:デフォルトの名無しさん mailto:sage [05/02/18 21:39:24 ]
しかし、ってことは Windows の場合、リバースポイントの
ジャンクションを含むパス名を指定したプログラムを実行中
の場合、そのジャンクションの削除もできないのかぁ。

254 名前:デフォルトの名無しさん mailto:sage [05/02/18 21:56:56 ]
>>252
ものの良し悪しはともかく、Windowsの方が
厨房にも直感的に理解できる仕様とはいえませんかね。

255 名前:デフォルトの名無しさん mailto:sage [05/02/18 22:05:09 ]
>224
スレ違いではあるんだが一応。
ベ ー シ ッ ク デ ィ ス ク で も で き ま す よ ?
NTFS にしとけば OK なはず。つか実際使ってますが。
FAT32 と間違ってるんじゃない?

普及してない理由としては、標準状態で簡単に使えるインタフェースが用意されていない、
アプリによって挙動が異なる、があると思う。
例えば、適当なファイル、サブディレクトリがあるディレクトリに対するリパースポイント
(ジャンクション)をエクスプローラで削除してみれば納得できるかと。
あ、あくまでテスト用のごみファイルでやりましょう。

256 名前:デフォルトの名無しさん mailto:sage [05/02/18 22:11:06 ]
>>255

>>224はジャンクションの話をしてるんじゃなくて、
>>206の言うディスクが足りなくなって増設した
場合に便利な機能==ダイナミックディスクの話を
してるみたいだね。

UNIX で言うところの LVM + Software RAID +
resizable filesystem に相当する機能のようだが
まとめて一つの名前になってるのがなんか変な感じ。

> エクスプローラで削除してみれば納得できるかと。

どうなるん?

257 名前:デフォルトの名無しさん mailto:sage [05/02/18 22:11:10 ]
>>254
そうね。
UNIXでは乱立のファイルロッキングも
Windowsはバカチョンだしね。

ただし、分散ファイルシステムでは、かなりきつい制約になるけども。

って、これ板違いの話題じゃねえ?



258 名前:デフォルトの名無しさん mailto:sage [05/02/18 22:12:51 ]
>って、これ板違いの話題じゃねえ?
海栗糞がいらんことで抗弁するから話題がそれていくんだよ

259 名前:デフォルトの名無しさん mailto:sage [05/02/18 22:13:37 ]
> UNIXでは乱立のファイルロッキングも

昔は確かに乱立してたけど、1990年代の
終わり以降は fcntl の F_GET/SETLK で
ほぼ統一ですよ。
NFS 経由のロックも、今はそれなりに
動くようになったようだ。

260 名前:デフォルトの名無しさん mailto:sage [05/02/19 00:46:59 ]
いまだに advisory lock が基本なのは勘弁してほしい。

261 名前:デフォルトの名無しさん mailto:sage [05/02/19 00:59:05 ]
え?商用UNIXだとたいていmandatoryの方もサポートしてるけど?

262 名前:デフォルトの名無しさん mailto:sage [05/02/19 09:11:03 ]
RedHat Linuxは商用Linuxですが対応していますか?

263 名前:デフォルトの名無しさん mailto:sage [05/02/19 09:47:48 ]
スレが伸びてる!と思って覗いたらこれかよ・・・お前らLv低すぎです。
首 洗 っ て 出 直 し て き な!!

264 名前:デフォルトの名無しさん mailto:sage [05/02/19 09:54:56 ]
おまえが一番レベル低い。慣用句の使い方間違ってるし。


265 名前:デフォルトの名無しさん mailto:sage [05/02/19 10:32:24 ]
おもろい。

266 名前:デフォルトの名無しさん mailto:sage [05/02/19 10:58:51 ]
顔 洗 っ て 待 っ て ろ よ な!!


267 名前:デフォルトの名無しさん mailto:sage [05/02/19 11:05:40 ]
>>266
今さら言い直しですかw
お 前 L v 低 す ぎ で す



268 名前:デフォルトの名無しさん mailto:sage [05/02/19 12:01:37 ]
>>262
うん、対応してるよ。
もっとも俺は RedHat のことを指して商用UNIX とは
呼ばないけどなあ。商用UNIXクローンと呼ぶならまあ
分かるけど。

269 名前:デフォルトの名無しさん mailto:sage [05/02/19 12:04:14 ]
「商用UNIX」の定義議論はスルーの方向で。

270 名前:デフォルトの名無しさん [05/02/19 12:27:53 ]
BSDのstruct procはLinuxだと何に相当するんですか?

271 名前:デフォルトの名無しさん mailto:sage [05/02/19 12:37:13 ]
商用UNIXってどういう定義なの?
MacOSXは商用UNIXに含まれますか?

272 名前:デフォルトの名無しさん mailto:sage [05/02/19 12:46:04 ]
板から言って、ユーザ空間から/proc関係をいじる時だよね?
libproc(procps)の<proc/readproc.h>にあるproc_t辺りでどう?

273 名前:デフォルトの名無しさん mailto:sage [05/02/19 12:57:15 ]
>>268
RedHatLinuxを商用と呼べない、というのには納得がいかないな。
事実上商用として使われているメジャーOSのひとつだろ。
単なるオープンソース寄せ集めじゃなくて、コードのメンテナが付いてて
しかも24時間サポートもやってるわけじゃん。その分カネもかかるけど。

これを商用UNIXと呼ばないで何を商用UNIXと呼ぶの?
まさかコードの由来がどうのとかツマンナイこと言わないよね?

274 名前:デフォルトの名無しさん mailto:sage [05/02/19 14:54:14 ]
プログラミングに関係ないことは他所でおねがいします。

275 名前:デフォルトの名無しさん [05/02/19 14:54:58 ]
>>271
売り物

276 名前:デフォルトの名無しさん [05/02/19 14:56:18 ]
>>273
268はUNIXと呼びたくないだけじゃないの?

277 名前:デフォルトの名無しさん mailto:sage [05/02/19 15:27:19 ]
lockingについては結局のところOS依存?



278 名前:デフォルトの名無しさん mailto:sage [05/02/19 15:59:55 ]
なわけねー

279 名前:デフォルトの名無しさん mailto:sage [05/02/19 16:14:08 ]
>>272
カーネル内のデータ構造体だとどれになりますか?

280 名前:デフォルトの名無しさん mailto:sage [05/02/19 16:21:38 ]
>>279
カーネル依存

281 名前:デフォルトの名無しさん mailto:sage [05/02/19 17:02:58 ]
struct task_structとstruct thread_infoってありますよね。

struct task_struct {
....
unsigned long flags; /* per process flags, defined below */

#define PF_ALIGNWARN0x00000001/* Print alignment warning msgs */
#define PF_STARTING0x00000002/* being created */
#define PF_EXITING0x00000004/* getting shut down */
#define PF_DEAD0x00000008/* Dead */

これってどういう意味ですか?
task_structってのはBSDのproc構造体とは違うんですか?

282 名前:デフォルトの名無しさん mailto:sage [05/02/19 18:16:00 ]
どのOSの話だよ。
まあ知ってはいるが、ちゃんと書け。バージョンもな。

あとここよりLinux板のカーネルなんちゃらスレの方が適切。


283 名前:デフォルトの名無しさん mailto:sage [05/02/20 06:17:43 ]
パーミッションをいじらないとmandatory lockをかけられないよな?

284 名前:デフォルトの名無しさん mailto:sage [05/02/20 15:49:27 ]
>>283
別に何の問題もないでしょ。
ファイルをロックする権限があるのに、パーミッションを変更
する権限がない状況なんてありえないんだから。

逆に、advisory と mandatory を切替えるのにプログラム側の
対処が全く必要ないっていうのは、大きなメリット。
開発サイドとはまったく関係なく、運用サイドだけで対応でき
るからね。


285 名前:デフォルトの名無しさん [05/02/20 20:32:46 ]
質問です。

fcntl (sock, F_SETOWN, getpid () );
fcntl (sock, F_SETFL, O_ASYNC);

でSIGIOを受けるようにした後で、
SIGIOが発生しないように、fcntlで設定をするにはどうしたらいいでしょうか?


286 名前:デフォルトの名無しさん mailto:sage [05/02/21 00:51:18 ]
O_ASYNC←→O_SYNC

287 名前:デフォルトの名無しさん [05/02/21 01:22:29 ]
>>286
ありがとうございました。



288 名前:デフォルトの名無しさん mailto:sage [05/02/21 10:41:42 ]
>>273
> これを商用UNIXと呼ばないで何を商用UNIXと呼ぶの?
RedHat が Open Group の conformance test 通ったら
商用 UNIX と呼んであげよう。


289 名前:デフォルトの名無しさん mailto:sage [05/02/21 10:57:14 ]
Linux is not Unix.






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<215KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef