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

UNIXプログラミング質 ..

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

>>211
URLﾘﾝｸ(support.microsoft.com)
とか
URLﾘﾝｸ(homepage1.nifty.com)
とかあるみたい。
ntfs.sys にパッチを当てないとディレクトリしか指せないみたいだ
けど、ディスクが足りなくなった場合とかはそれでも問題なかろう。

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

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

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

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

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

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

222:デフォルトの名無しさん
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:デフォルトの名無しさん
05/02/18 18:00:43
> これって$0のこと?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

229:デフォルトの名無しさん
05/02/18 19:15:43
ﾁﾞｬﾊﾞｼﾞｬﾊﾞ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どうなるん？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

271:デフォルトの名無しさん
05/02/19 12:37:13
商用ＵＮＩＸってどういう定義なの？
ＭａｃＯＳＸは商用ＵＮＩＸに含まれますか？

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

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

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

274:デフォルトの名無しさん
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:デフォルトの名無しさん
05/02/19 15:27:19
lockingについては結局のところOS依存？

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

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

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

281:デフォルトの名無しさん
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:デフォルトの名無しさん
05/02/19 18:16:00
どのOSの話だよ。
まあ知ってはいるが、ちゃんと書け。バージョンもな。

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

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

284:デフォルトの名無しさん
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:デフォルトの名無しさん
05/02/21 00:51:18
O_ASYNC←→O_SYNC

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

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

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

290:デフォルトの名無しさん
05/02/21 11:08:50
くだらね

291:デフォルトの名無しさん
05/02/21 11:15:51
>>290
チョー有名な再帰型定義だろ。今さら反応すんな。

292:デフォルトの名無しさん
05/02/21 21:39:52
>>288
それはcompatibleかどうかの定義であって
商用かどうかの定義とは異なるのでは？

293:デフォルトの名無しさん
05/02/21 21:43:39
商用Linuxという事でええやんか

294:デフォルトの名無しさん
05/02/22 01:06:42
だから商用UNIXというのはマシンとの抱き合わせ商法だってば
HP-UXとかSolarisとか
OSだけなんて商売にならねーって
M$でさえPCとのバンドルで儲けてるのに

295:デフォルトの名無しさん
05/02/22 01:13:12
だからさー、なんで抱き合わせだとかconoformance testに通ったかどうか
なんてのが「商用」になるのさ。
抱き合わせは、特定ハードウェア用の、という意味だろ？
全然商用と関係ないやん。

296:デフォルトの名無しさん
05/02/22 01:13:34
>>294
は？

297:デフォルトの名無しさん
05/02/22 01:35:08
>>295
だ～か～ら～、「商用」の部分に文句をつけてる奴は
誰もいないんだってば。

「商用UNIX」ではなく「商用Linux」
OK?

298:デフォルトの名無しさん
05/02/22 01:57:30
は？商用UNIXという言葉の定義が不明瞭だという話では？

299:デフォルトの名無しさん
05/02/22 03:49:24
このスレのレベルが下がりつつあります。

300:デフォルトの名無しさん
05/02/22 09:29:25
>>292
通んなきゃ、少なくとも商標としての UNIX は名乗れんぞ。

301:デフォルトの名無しさん
05/02/22 09:41:07
Linuxのどのあたりがテストにひっかかるの？

302:デフォルトの名無しさん
05/02/22 09:42:13
そもそもLinuxはUNIXを名乗るつもりは毛頭無い

303:デフォルトの名無しさん
05/02/22 10:46:15
>>301
URLﾘﾝｸ(www.opengroup.org) を自分で調べれ。

>>302
そらそうだ。

304:デフォルトの名無しさん
05/02/22 11:42:37
1 名前：名無し募集中。。。投稿日：05/01/15 02:18:37
UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド

305:デフォルトの名無しさん
05/02/22 13:34:24
UNIXと名乗るにはライセンシーが必要。
当然、金がかかる。

306:デフォルトの名無しさん
05/02/22 13:46:31
JEDIと名乗るにはライトセイバーが必要。
金がかかるかどうかは知らない。

307:デフォルトの名無しさん
05/02/22 14:38:08
Linuxってスレッドに別のアドレス空間を割り当てることもできるの？

308:デフォルトの名無しさん
05/02/22 15:04:04
それスレッドとは言わない。

309:デフォルトの名無しさん
05/02/22 15:38:55
それはスッドレだな。

310:デフォルトの名無しさん
05/02/22 17:41:25
別に不可能ではないだろう

311:デフォルトの名無しさん
05/02/22 18:52:10
UNIXにRead/WriteProcessMemoryみたいなのありませんか？
プロセスのメモリ覗きたい

312:デフォルトの名無しさん
05/02/22 19:09:09
よく分らんけどptraceとか？

313:デフォルトの名無しさん
05/02/22 20:11:34
それであってる。

314:デフォルトの名無しさん
05/02/25 01:14:14
314げっち

315:デフォルトの名無しさん
05/02/25 01:41:10
時間を指定して指定時間後に
XCloseDisplay
exit
したいのですが、その指定時間までの間にもXNextEvent の処理を受けたいのですが
この場合はどのように書くのでしょうか？
XNextEvent をループでまわしてそのループの中でtimeで計算して指定時間後に抜けようと思ったのですが
XNextEvent は、イベントが起きるまでそこで止まってしまうのでループでまわすことができません
すいませんが、教えていただけると幸です

316:デフォルトの名無しさん
05/02/25 03:14:38
>>315
イントリンシックスにタイマーなかったっけ?
それなら時間になれば勝手にコールバックが呼ばれると思うが。

317:デフォルトの名無しさん
05/02/25 05:24:04
XtAddInput() だな。Xt 使ってるならそれでOK。

Xlib しか使ってないなら ConnectionNumber() で
ファイルディスクリプタを求めて、poll(2) かな。

318:317
05/02/25 07:25:27
なに寝惚けてるんだ俺は。
s/XtAddInput/XtAddTimeout/

319:デフォルトの名無しさん
05/02/25 17:21:07
>>282
2.6のkernel/fork.cのdo_fork関数とcopy_process関数を読んだら分りました。
しかしこのネーミングなんとかならないですかね。もう手遅れかな。

320:デフォルトの名無しさん
05/02/25 19:47:09
>>319
Hurdを待て

321:315
05/02/25 23:16:31
>>317
ありがとうございます
Xtはつかっていず、 Xlibだけです
ConnectionNumberとpollを調べてみたのですが
プログラミングを始めたばかりでよくわかりません
poll の第3引数にタイムアウトまでの時間を指定すると
言うことしかわかりませんでした・・・
すいませんが、簡単にサンプルを書いていただけませんでしょうか？
すいませんが、よろしくおねがいします

322:デフォルトの名無しさん
05/02/25 23:51:46
>>321
っていうかググれ！

323:デフォルトの名無しさん
05/02/26 00:17:03
俺、納品作業中で逃避したい気分だから答えちゃう。
たぶん、こんな感じ。

324:デフォルトの名無しさん
05/02/26 00:17:39
*** piyo.c.org　　Fri Feb 25 23:51:21 2005
--- piyo.c　　　　　　Sat Feb 26 00:07:42 2005
***************
*** 1,6 ****
--- 1,10 ----
　　#include <stdio.h>
　　#include <X11/Xlib.h>
　　#include <X11/Xutil.h>
+ #include <sys/types.h>
+ #include <poll.h>
+ #include <time.h>
+ #include <errno.h>
　　
　　#define STRING　　　　　　　　"Hello, world"
　　#define BORDER　　　　　　　　1
***************
*** 49,54 ****
--- 53,59 ----
　　　　　　XSizeHints xsh;
　　　　　　char *geomSpec;
　　　　　　XSetWindowAttributes xswa;
+　　　　 time_t deadline = 0;
　　
　　　　　　if ((dpy = XOpenDisplay(NULL)) == NULL) {
　　　　　　　　fprintf(stderr, "%s: can't open %s\n", argv[0], XDisplayName(NULL));

325:デフォルトの名無しさん
05/02/26 00:18:49
***************
　　　　　　XMapWindow(dpy, win);
　　
　　　　　　for (;;) {
+　　　　　　 time_t now;
+　　　　　　 struct pollfd fd;
+　　　　　　 int rv;
+
+　　　　　　 if (deadline != 0 && !XPending(dpy)) {
+　　　　　　　　　　 time(&now);
+　　　　　　　　　　 if (deadline <= now)
+　　　　　　　　　　　　　　 break;
+　　　　　　　　　　 fd.fd = ConnectionNumber(dpy);
+　　　　　　　　　　 fd.events = POLLIN;
+　　　　　　　　　　 rv = poll(&fd, 1, (deadline - now) * 1000);
+　　　　　　　　　　 if (rv == -1) {
+　　　　　　　　　　　　　　 if (rv == EINTR)
+　　　　　　　　　　　　　　　　　　 continue;
+　　　　　　　　　　　　　　 perror("poll");
+　　　　　　　　　　　　　　 exit(1);
+　　　　　　　　　　 }
+　　　　　　　　　　 if (rv == 0) /* timer expired */
+　　　　　　　　　　　　　　 break;
+　　　　　　 }
　　　　　　　　XNextEvent(dpy, &event);

326:デフォルトの名無しさん
05/02/26 00:20:40
deadline が 0 だったら終了しない。
deadline に、終了時刻 (UNIX Epoch からの秒数) を入れておくと、
そのタイミングで終わる。

327:デフォルトの名無しさん
05/02/26 00:28:51
あ、すまんちょっと間違えた。
if (rv == EINTR)
は、
if (errno == EINTR)
が正しい。

328:デフォルトの名無しさん
05/02/26 00:34:01
piyo.cってなんだよｗｗ

329:デフォルトの名無しさん
05/02/27 10:26:19
しかも何故にpatchなのかw

330:デフォルトの名無しさん
05/02/28 04:59:34
セキュリティ対策です

331:デフォルトの名無しさん
05/02/28 05:06:12
ﾜﾛｽ

332:117 = 124
05/02/28 13:57:11
>>325
for 分の、
(;;) ← が、なんかモサモサしててｶﾜｲｰ

333:デフォルトの名無しさん
05/02/28 13:57:44
↑ for 文の、

334:デフォルトの名無しさん
05/03/01 09:26:59

335:デフォルトの名無しさん
05/03/01 16:53:14
C, C++(gcc)で任意の文字コードをEUCやUTF-8に変換したいのですが，
良いライブラリがあったらお教えください。

ちょっと探してみたんですがシンプルで使いやすそうなのが見つかりませんでした。

336:デフォルトの名無しさん
05/03/01 17:00:59
URLﾘﾝｸ(www.gnu.org)

337:デフォルトの名無しさん
05/03/01 17:33:15
ふつー、iconv(3C) くらいあるでしょ。

338:デフォルトの名無しさん
05/03/01 17:39:49
>336

iconvだと変換元の文字コードを指定しなきゃいけないですよね。
それは仕方ないのかな…
PerlのJcode.pmみたいにお手軽に使えるのはないんですかね？

sylpheedってMUAのソースにあるcodeconvあたりを流用するのが良いような気がしてるんですけど。

やっぱ定番はiconvなんですか？

339:デフォルトの名無しさん
05/03/01 17:43:45
iconv なんてよんでる？
私はあいこんぶ

340:335
05/03/01 17:47:07
>>337
あります。

>>339
同じく"あいこんぶ"です。

酢昆布も好きです。

341:デフォルトの名無しさん
05/03/01 18:19:30
>>338
あー、なるほど。自動判別「も」したい、と。
そういうのって、用途 (というか、入力がどこまで
限定できるか) に拠って全然違ってくるからねぇ…

342:デフォルトの名無しさん
05/03/01 18:35:36
UNIXてどこで役に立つですか？
このスレよんでたら眠くなってきた。

343:デフォルトの名無しさん
05/03/01 18:41:13
任意の文字コードの自動判別って可能なのかね？

344:デフォルトの名無しさん
05/03/01 18:44:02
もちろん、完全にやるのは不可能。
文字コードを自動判別しないといけない時点で負け。

345:デフォルトの名無しさん
05/03/01 18:44:52
>>342
なんか最近は自作自演で回ってるみたい。
俺も眠たくなってきた。

346:デフォルトの名無しさん
05/03/01 18:45:41
nkf

347:デフォルトの名無しさん
05/03/01 18:49:49
ELFフォーマットってUNIX共通ですか？
実行ファイルに細工したいので
UNIXの実行ファイルのフォーマットを教えてください。

348:デフォルトの名無しさん
05/03/01 18:53:34
1年くらい前にも見たな。ウィルスでも作るのか？

349:デフォルトの名無しさん
05/03/01 18:55:37
Windowsのリソースの真似事がしたいのです。
わかりますか？リソース

350:デフォルトの名無しさん
05/03/01 19:00:04
過去ログでsharとか言ってた人がいますが、
セキュリティの減ったくれもないので使いたくありません。
WindowsでいうPEへのセクション追加ぐらいの手間で解決したいのです。

351:デフォルトの名無しさん
05/03/01 19:01:33
アーキテクチャに依存しないデータは、あまりバイナリの中には入れないよねUNIXの場合。

352:デフォルトの名無しさん
05/03/01 19:03:07
コメント領域があったと思うけど勝手に使えば

353:デフォルトの名無しさん
05/03/01 19:04:59
こたえる気がないなら答えなきゃいいのに。

354:デフォルトの名無しさん
05/03/01 19:05:58
>>349
リンカでつなげば？

355:デフォルトの名無しさん
05/03/01 19:07:58
>>354
何言ってんの？このタコは

356:デフォルトの名無しさん
05/03/01 19:11:10
リソースってようするに初期済みのデータだろ？

357:デフォルトの名無しさん
05/03/01 19:18:15
>>351
だから何ですか？
一般論を聞きたいのではなく、
入れたい場合が出てきたということです。

>>352
詳しく教えてください。

>>354
リンカでどうやって繋ぐのでしょうか？

>>356
初期済みのデータが初期化済みデータのことならその通りです。

358:デフォルトの名無しさん
05/03/01 19:31:03
そういえばX Windowってリソース管理どうなってんの？
アイコンとかって外部ファイル？
もしかしていちいちパス指定で取ってきてる？
パス管理複雑にならない？

359:デフォルトの名無しさん
05/03/01 19:31:28
Cで初期化された大域変数をリンクするのと同じということでは？
ELFの話はLinkers & Loadersていう本にそれなりに載ってる気がする。

360:デフォルトの名無しさん
05/03/01 19:31:52
X or X Window System

361:デフォルトの名無しさん
05/03/01 19:38:33
つまんねー揚げ足すんなよ
おまえ、つまんねー奴って言われるだろ

362:デフォルトの名無しさん
05/03/01 19:39:22
>>359
そういうことでしたら
既存の実行ファイルに対して追加したいので
リンカを使う方法は無理です。

363:デフォルトの名無しさん
05/03/01 19:40:35
>>357
>だから何ですか？
漏れは351じゃないけど、別に多少関連した雑談や世間話くらいしても良いと思うんだけど・・・
質問と回答以外はスレ違い、っていう立場もあるのかもしれないけど。

>リンカでどうやって繋ぐのでしょうか？
テキトーなバイナリなりXMLなり文字列なりをソースとして、
const unsigned char appResourceHoge[] = { 0x11, 0x22, .............. };
みたいなソースファイルを出力するスクリプトなんかを使う。
Xのコードとか書いたことがあればイメージできると思う。
実行ファイルに細工したい（ソース無しでリソースだけ変更したい）って用途には向かない。

なんだから偉そうな質問者様に対してこんな返事しかできなくてごめんね。

364:デフォルトの名無しさん
05/03/01 19:40:43
なあ、俺もUNIXでトロイ作りたいんだけど、
実行ファイルのフォーマット教えてくれよ

365:デフォルトの名無しさん
05/03/01 19:41:29
>>362
ん？既存の実行ファイルを弄らないなら埋め込んでも意味ないだろ？
埋め込んだ上でそれを使うように修正しないと

366:デフォルトの名無しさん
05/03/01 19:41:56
>>363
うわ、そんなことできるならはじめからやってるだよ

367:デフォルトの名無しさん
05/03/01 19:42:53
どうやらここのUNIX使い様はリソースって概念がわからんらしい

368:デフォルトの名無しさん
05/03/01 19:43:23
>>365
Windowsのリソースのように、バイナリに埋め込まれていてかつ後から
編集できるデータ格納方法は無いだろうか、という質問だと思うが。
コード自体は自分で書くのだろう。

369:デフォルトの名無しさん
05/03/01 19:44:14
>>368
そう思ってたが >>362 を読んで違うのかと思った

370:デフォルトの名無しさん
05/03/01 19:46:59
あらかじめリソース予定地とする空のゴミ領域を作っておいて、
後でマジックナンバーか何かで検索して挿げ替えるとか、かなあ。

371:デフォルトの名無しさん
05/03/01 19:50:07
ユーザに差し替えさすならもっと優しい方法にしろ。
自分で埋めるならリンカ使えるだろ
人のアプリをどうこうするなら、Winのリソース差し替えのようにはいかない。

372:デフォルトの名無しさん
05/03/01 19:52:23
だからELFの.commentに好きなフォーマットでデータ埋め込んで、
実行時にファイル開いてELFヘッダからその領域を見ればいいんじゃ。
OSのバグ踏む可能性あるけど

373:デフォルトの名無しさん
05/03/01 19:53:02
そもそもUNIXの実行ファイルはELFフォーマットなの？
それでいいの？

374:デフォルトの名無しさん
05/03/01 19:55:52
ELFが多いだろうけど全部じゃないんじゃない？

375:デフォルトの名無しさん
05/03/01 19:59:16
UNIXのOSはリソースというものを扱えるの？
もし、OSの支援が無いならば、
実行プロセスが自分自身の元になった実行ファイルの所在を
正確に把握する手段を持たなくてはいけないはず。
これって、少し前に出ていた設定ファイルの議論と重なるような気がする。

376:デフォルトの名無しさん
05/03/01 20:11:33
なんでここの連中は仮定で話したがるかね
ちゃっちゃと調べて実際をどうなのかを書けよ

377:デフォルトの名無しさん
05/03/01 20:12:56
> UNIXのOSはリソースというものを扱えるの？

リソースにもいろいろあるでしょ。
メモリとかディスクとかいったリソースならもちろん扱える。
人的リソースみたいなものは、OSの守備範囲外だから当然無理。
てゆうか、そもそも質問が意味不明。

> 実行プロセスが自分自身の元になった実行ファイルの所在を
> 正確に把握する手段を持たなくてはいけないはず。
> これって、少し前に出ていた設定ファイルの議論と重なるような気がする。

実行ファイルのディスク上の物理位置は正確に把握している。
パス名は把握しても意味がない (Windows と違い、実行ファイル
のパス名が存在しなくなっても実行を継続できる) から、そんな
ものは記録しないってのは、このスレでさんざん既出。

なんか、基本的な素養に欠けているって感じの質問だなあ。
ソースとまでは言わんから、せめて本ぐらい読めというか。

378:デフォルトの名無しさん
05/03/01 20:13:15
そうはいかんざき

379:デフォルトの名無しさん
05/03/01 20:13:46
>>376
質問スレだから。
質問だけするのが正しい態度。

380:デフォルトの名無しさん
05/03/01 20:14:10
>>377
だったら最初からこの本読めとかリンク出せよヴォケ

381:デフォルトの名無しさん
05/03/01 20:14:50
で、アイコンとかダイアログのリソースはどっから取ってきてるのかね？ん？

382:デフォルトの名無しさん
05/03/01 20:16:20
ある一人のレスが浮き上がって見える

383:デフォルトの名無しさん
05/03/01 20:16:41
>>377
>リソースにもいろいろあるでしょ。
この流れだとWindowsや(旧)Macで言うところのリソースのことではないでしょうか。

>>381
WineではPEファイルから取ってくるみたいですよ。

384:デフォルトの名無しさん
05/03/01 20:18:59
たった今、UNIXに挫折したとです。

385:デフォルトの名無しさん
05/03/01 20:20:04
UNIXで良書なんて見たことないから
どこに載ってるか書いて欲しいなあ。

386:デフォルトの名無しさん
05/03/01 20:20:41
>>384
！！！そのキーワードは、

いっちゃいかん！！

387:デフォルトの名無しさん
05/03/01 20:21:49
WindowsみたいなリソースはOSはサポートしないだろう。

388:デフォルトの名無しさん
05/03/01 20:23:21
リソースがなにを指しているか分からないと、
本の名前も出せないでしょ。
>>381みたいな質問している人にOSの本勧めても
無意味だし。

>>381
Xの場合、ダイアローグの表示はツールキットの
仕事なのでツールキットの種類によりけり。
アイコンの表示はウィンドウマネージャの仕事
なので、ウィンドウマネージャによりけり。
(ツールキットが決まると、ツールキット標準の
ウィンドウマネージャが決まる場合もある。)
知りたいツールキットとウィンドウマネージャの
種類を具体的に述べれば、もっと具体的な答も
出せるかもね。
いにしえのXtとtwmで言うなら
/usr/X11R6/include/X11/{bitmaps,pixmaps}/
と /usr/X11R6/lib/X11/app-defaults/ あたりが
標準的な場所なわけだが。(アプリケーション固有
の場所に置くこともできる。)

ツールキットは狭義ではOSの一部ではない。
>>387が言ってるのはそういう意味。

389:デフォルトの名無しさん
05/03/01 20:23:27
つか、ELFをばらして好きに弄ってもう一回固めればいいんじゃないの？

390:デフォルトの名無しさん
05/03/01 20:26:23
>>389
わかってないなあ

391:デフォルトの名無しさん
05/03/01 20:27:27
UNIXを捨てた
おれは正解を選んだ

392:デフォルトの名無しさん
05/03/01 20:28:33
452 名前：デフォルトの名無しさん投稿日：05/02/28 01:15:33
もうUNIXで仕事したくないのに
UNIXの仕事がきます。
どうすればよいですか？

453 名前：デフォルトの名無しさん投稿日：05/02/28 01:18:47
仕事があるだけマシってもんよ
そうだろう？兄弟

454 名前：デフォルトの名無しさん投稿日：05/02/28 01:26:38
もういやだ！
もういやだ！
もういやだ！

393:デフォルトの名無しさん
05/03/01 20:30:51
あほくさ

394:デフォルトの名無しさん
05/03/01 20:31:13
ELFフォーマットを採用してるOSを上げてください。
自分はLinux以外知りません。

395:デフォルトの名無しさん
05/03/01 20:34:08
>>394
商用、フリーを問わず、現役のUNIX系OS、ほぼ全て。
ELF の規格を定めたのは、AT&T と Sun じゃないかな。
linux は最初のうちはa.outしかサポートしてなかったね。

396:デフォルトの名無しさん
05/03/01 20:35:29
じゃ、とりあえずELFでトロイ作ってみるよ。
あんがと。

397:デフォルトの名無しさん
05/03/01 20:37:56
Windowsヲタは固定観念のかたまりだな...

398:デフォルトの名無しさん
05/03/01 20:38:25
>>394
Solaris, *BSD, IRIX, SVR4 等...
最近は組み込み用途の開発ツールも ELF を吐き出す.

399:デフォルトの名無しさん
05/03/01 20:40:27
BSD系は最近だな

400:デフォルトの名無しさん
05/03/01 20:42:04
CPUの種類やOSの種類が異なると、同じ elf でも
使える命令セットやシステムコールが異なるので、
同一のトロイの木馬を複数のOSに対応させるのは
面倒なんだけどね。まあやれば当然できるが。

つうか、そういうものを作るだけの知恵のある奴は、
ふつうはもう少し建設的なことに暇を使うと思うんだが。
そういう、できて当たり前で、人が困るだけのプログラム
を作るのは、そういうことの判断ができない頭弱い奴だけ
じゃない？

401:デフォルトの名無しさん
05/03/01 20:58:38
商用UNIXだとしっかりしてるんだけどね。

402:デフォルトの名無しさん
05/03/01 22:05:13
お前ら落ち着け

403:デフォルトの名無しさん
05/03/01 22:09:20
さては藻前も釣りだな。

404:デフォルトの名無しさん
05/03/01 22:25:28
UNIXにもノートンみたいな製品を進出させるには
トロイとかウィルスばらまかないとね
需要のための供給

405:だよもん
05/03/01 22:37:03
だよもんウィルスだよもん

406:335
05/03/01 22:49:49
１文書に複数文字コードが入ってるとか，そういうややこしいのじゃなくて
１文書が１つの文字コードに限定されてるんです．

>>341
そうです．自動判別”も”したいんですけど，
どうも良いライブラリがみつかんないんですよねぇ．

>>344
>文字コードを自動判別しないといけない時点で負け。
orz.

完全に自動判別すんのが厳しいのは分かってるんですけど…
大体でよいんです．

>>346
nkfに渡すのも考えてるんですけど…
ライブラリ化されてて使いやすいのはないものかと．

407:デフォルトの名無しさん
05/03/01 23:36:56
>>335
URLﾘﾝｸ(tricklib.com)
g++ だと多少問題があるらしいがこれはどうだ？
僅かな文字数でも高い精度で判別できるぞ。

408:デフォルトの名無しさん
05/03/02 11:14:24
コードに日本語でコメントが入っているというだけで
使う気がしなくなるのは俺だけか？

409:デフォルトの名無しさん
05/03/02 11:23:12
↑ソースクレ厨

410:デフォルトの名無しさん
05/03/02 13:38:21
↑車輪を何度も再発明して貴重な人生を無駄にする香具師

411:デフォルトの名無しさん
05/03/02 15:11:02
>>410
↑見ず知らずの他人の趣味を「人生の無駄」呼ばわりする香具師

412:335
05/03/02 15:50:59
>407
ありがとうございます。よさげですね。
g++だと何か問題があるんですかね？
ちょっと試してみます。

413:デフォルトの名無しさん
05/03/03 23:45:23

414:デフォルトの名無しさん
05/03/05 05:52:29
各種UNIXでcursesの互換性ってどの程度まであるの？

415:デフォルトの名無しさん
05/03/05 11:28:09
問題ないくらい

416:デフォルトの名無しさん
05/03/07 13:17:21
linuxだとアドレス値を整数演算するときに
unsigned longに入れてるんだけど、これって
128bitCPUが出てきたときに問題にならないの？

417:デフォルトの名無しさん
05/03/07 13:30:53
問題になるかならないかは不明。
128bit CPU が実用になる時代が本当に来たとしても、
その CPU で long>=128bit なら問題にならない。
long<128bit なら問題になる。

一般論としては、そういう用途には unsigned long では
なく、uintptr_t ないし intptr_t を使うべき。
この型は C99 なら #include <stdint.h> すると定義
される。

418:デフォルトの名無しさん
05/03/07 13:42:04
>>416
longを128bitにするから問題なし。

419:デフォルトの名無しさん
05/03/07 13:42:08
仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う
ほとんどの場合unsignedにする意味なし
Linuxのプロセスメモリマップの使い方でも調べたほうが賢明

420:デフォルトの名無しさん
05/03/07 14:16:30
>仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う
なんだこりゃ

421:デフォルトの名無しさん
05/03/07 18:18:53
>>419 さんは、>>416 さんが「 unsigned 」を疑問視されていると受け取られた
ようでつね。
対して、多くの方々は >>416 さんが疑問視しているのは「 long 」の方だと・・・
どちらにしても、>>417 さんの答えで解決でつよね？

422:デフォルトの名無しさん
05/03/07 19:12:18
UNIXが採用してるLP64というCの型システムだけど、
128bitCPUが出てきたときは、LP128というものを定義して、
unsigned longはつねにポインタサイズと同じビット長になる
ことを暗に想定してるのかな？
LP128だと
short(16),int(32),long(128),long long(128)
こんな感じなのかな？

>>128
>一般論としては、そういう用途には unsigned long では
>なく、uintptr_t ないし intptr_t を使うべき。
ですよねえ

423:デフォルトの名無しさん
05/03/07 19:22:13
システムによって定義されるのはたった数個の型だけど、
これがいろんな型にtypedefされて、またそれらが
インターフェイスの定義に既に使われていたりするところが
ややこしいね。

424:デフォルトの名無しさん
05/03/07 19:50:19
>>422
予測できる将来に128bit CPUが実現するかどうかは
良く分からないけど、もし実現したらUNIX系は
short:int:long:long long=16:32:64:128 になるん
じゃないかなあ。だって、1/2/4/8/16 全てのサイズの
整数型が使えないと不便でしょ。

今やuintptr_tがあるから、long がポインタ変数を
保持できるとかいった仮定を設ける必要ないし。

425:デフォルトの名無しさん
05/03/07 19:53:29
とりあえず、LP64, ILP64, LLP64, ILP32, LP32くらい理解してからレスしろよ、この屑。
URLﾘﾝｸ(www.opengroup.org)

426:デフォルトの名無しさん
05/03/07 20:19:14
LP64・・・longとポインタが64ビットに
ILP64・・・intとlongとポインタが64ビットに
LLP64・・・long longとポインタが64ビットに
ILP32・・・intとlongとポインタは32ビット(今の32bit向けCコンパイラはこれかな？)
LP32・・・longとポインタは32ビット、intは16ビット

こんな感じ？

427:デフォルトの名無しさん
05/03/07 20:23:57
TRANSITION FROM CURRENT INDUSTRY PRACTICEも読め。

次ページ