2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

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

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

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


2 :名無し募集中。。。:05/01/15 02:19:15
【POSiX】
The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
http://www.opengroup.org/onlinepubs/009695399/toc.htm


【必読書】
Advanced Programming in the UNIX(R) Environment
http://www.amazon.com/exec/obidos/tg/detail/-/0201563177/

Unix Network Programming
Vol. 1: The Sockets Networking API, Third Edition
http://www.amazon.com/exec/obidos/tg/detail/-/0131411551/

UNIX Network Programming
Volume 2: Interprocess Communications (2nd Edition)
http://www.amazon.com/exec/obidos/tg/detail/-/0130810819/


3 :名無し募集中。。。:05/01/15 02:20:16
man on www
http://www.linux.or.jp/JM/#Search

GNU Make 日本語リファレンス
http://www.ecoop.net/coop/translated/GNUMake3.77/make_toc.jp.html

Unix Programming Frequently Asked Questions 日本語訳
http://www.adl.nii.ac.jp/~moro/unix-programmer/faq-j_toc.html

4 :名無し募集中。。。:05/01/15 02:20:51
関連スレ追加

ネットワークプログラミング相談室 Port12
http://pc5.2ch.net/test/read.cgi/tech/1102427855/
マルチスレッドプログラミング相談室 その3
http://pc5.2ch.net/test/read.cgi/tech/1098268137/

5 :名無し募集中。。。:05/01/15 02:22:57
           /◇
 oノハヽo  /◇◇
 从*・ 。.・) / ◇ ◇ センター試験がんばってね
 /o y/ |`p
 し!|||ii|||J
  |||||||||


6 :名無し募集中。。。:05/01/15 02:24:17
空気読まずに立てちゃったけどOK?


7 :デフォルトの名無しさん:05/01/15 02:27:18
いやでも、
UNIXで挫折って、わかる気がするなあ。
ずっと意味不明なコマンドの文字列打ってたら頭おかしくなりそうだし、
ずっと真っ暗なコンソール眺めてると鬱になりそうじゃん?
かといって思想のまるでないXは、オタ絵とただ沢山コンソール開くしか脳ないし、
こんなの与えても娯楽を常に要求する一般人は見向きもしない。
そもそもWebでしか見掛けない、哀れなOS、というのが一般人の見解だし。
そうそう、最近LindowsがUNIXの印象かなり悪くしたよね。
この事件でUNIXはビジネスで成功できないことがまた証明されてしまったわけだ。
昔からUNIXは関係者同士で常に足を引っ張って成長しない。
お金の匂いしないよね。全然。
そんなOSだから、挫折が常態であるのは必然なんだと思う。

8 :デフォルトの名無しさん:05/01/15 02:27:53
ほらきた。
UNIX使いって貶されると、
すぐ言葉少なになるよね。
もう貶されるのに慣れちゃった?

ちょっと、心をおちつけて。
UNIXを知らなかったあの頃を思い出してごらん。
あの頃の君達は希望に満ち溢れていたよね。
そう、今まで君達は、とっても悪い夢を見ていたんだ。
UNIXなんか捨てて、あの頃見ていた希望を取り戻そうよ!


9 :デフォルトの名無しさん:05/01/15 02:50:47
>>1

10 :デフォルトの名無しさん:05/01/15 15:25:13
どこの板の名無しだよ

11 :デフォルトの名無しさん:05/01/15 15:39:53
>>6
問題なし。

前スレのhttp://pc5.2ch.net/test/read.cgi/tech/1095843584/944
GNUは仕様だけじゃなくて、こうしましょうってガイドラインも出してるよ。
http://www.sra.co.jp/wingnut/standards-j_toc.html

ちなみに--に決めた時は、(+って候補もあった)
メーリングリストで投票していた。ストの仕切りで。

12 :デフォルトの名無しさん:05/01/15 17:16:03
モーヲタがUNIX使う時代なのか

13 :デフォルトの名無しさん:05/01/19 15:11:41
ここら辺もテンプレに入れとかない?

Advanced Programming in the UNIX(R) Environment 和訳
http://www.amazon.co.jp/exec/obidos/ASIN/4894713195/

Unix Network Programming 和訳
http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
http://www.amazon.co.jp/exec/obidos/ASIN/4894712571/

UNIX プログラミング環境
http://www.amazon.co.jp/exec/obidos/ASIN/4871483517/

14 :デフォルトの名無しさん:05/01/19 15:16:21
あと俺、これも好きなんだけどねえ。

UNIX システムコールプログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/487148260X/

古いから、今のとの相違点をマニュアルと比較しながらでないと
使えないんだけど。逆にそれができる香具師には、単純だった頃の
UNIX の姿から学習できるから、かえって入門に向いてる気がする
んだが。


15 :デフォルトの名無しさん:05/01/19 15:30:05
ちなみに↑は去年新版が出たんだが(20年ぶりくらい?)
和訳の予定ってないんかなあ。
最近、原著で読み通すほどの暇と気力がない。orz

http://www.amazon.com/exec/obidos/tg/detail/-/0131411543/


16 :デフォルトの名無しさん:05/01/19 21:06:44
ここ2,3年の間にUNIXのプログラミング題材にした書籍が
アメリカで何冊か出てるよね。

17 :デフォルトの名無しさん:05/01/19 23:27:33
Linuxのみだけど、↓これもなかなかいい内容の本だったよ。
古典的なところをちょっと外れたのも盛り込んでいて。
新人さん向けの本を捜しての斜め読みだけどもね…

Linuxプログラミング―例題で学ぶUNIXプログラミング環境のすべて
http://www.amazon.co.jp/exec/obidos/ASIN/4797327014/

18 :デフォルトの名無しさん:05/01/19 23:46:23
Linux Is Not UniX

19 :デフォルトの名無しさん:05/01/28 11:29:30
質問させていただきます
Xのプログラムをコンパイルしようとおもったのですが
[root@cf root]# gcc -I /usr/X11R6/include -lX11 -L /usr/X11R6/include -I/usr/X11R6/lib -L /usr/X11R6/lib xaa.c -o xaa
[root@cf root]# ./a.out
Shared object "libX11.so.6" not found
といわれて、動作させることができません

[root@cf root]# find /usr/X11R6/ -name "libX11.so.6"
/usr/X11R6/lib/libX11.so.6
で、libX11.so.6はあるのですが‥
どこか根本的にまちがっているのでしょうか?


20 :デフォルトの名無しさん:05/01/28 11:42:56
コンパイルする時に-R/usr/X11R6/libするか、
$ env LD_LIBRARY_PATH /usr/X11R6/lib ./a.out あるいは
# vi /etc/ld.so.confに/usr/X11R6/lib 加えて、# ldconfig

ちなみにその糞OSは何?

21 :デフォルトの名無しさん:05/01/28 18:22:34
おそらくTurboかと

22 :デフォルトの名無しさん:05/01/28 18:46:58
>>20
> $ env LD_LIBRARY_PATH /usr/X11R6/lib ./a.out あるいは

$ env LD_LIBRARY_PATH=/usr/X11R6/lib ./a.out


23 :デフォルトの名無しさん:05/02/02 11:35:16
皆さんに質問で
ファイルから設定を読みこむときって皆さんはどうやってますか?
width=500
height=600
と、設定ファイルにかかれているとき
Perlなら、widthを変数名に、500を値にいれていたのですが
C言語ではどうするのでしょうか?

もしよろしければ適当にソースを書いていただければ幸です


24 :デフォルトの名無しさん:05/02/02 11:58:14
マルチすんなボケ

25 :デフォルトの名無しさん:05/02/02 11:59:21
>>24
こいつぼけ

26 :デフォルトの名無しさん:05/02/02 13:25:31
>>23
C言語の初心者スレへ。

27 :デフォルトの名無しさん:05/02/03 23:25:08
>>19
./a.out <==./xaa の間違い?

28 :デフォルトの名無しさん:05/02/04 12:08:09
詳解UNIXに載ってるIPCの機能は、いまあるメジャーなUNIXでは
殆ど使えてるんでしょうか?それともプロセス間通信はpipeや
mmapみたいな基本的なものに限定しておいて、スレッドを使う
方向で考えた方が、推奨されるやり方なのですか?

29 :デフォルトの名無しさん:05/02/04 12:43:16
>>28
・使えるんじゃない?
・そうとは思わないけど。

30 :デフォルトの名無しさん:05/02/04 16:48:48
>>28
POSIX見れ。


31 :デフォルトの名無しさん:05/02/04 18:47:12
>>30
POSIXに準拠してないOSがあったりするのがUNIXの難しさなのではないですか?

32 :デフォルトの名無しさん:05/02/04 19:12:34
>>31
いまあるメジャーなUNIXでPOSIXのIPCが使えないのってどれ?


33 :デフォルトの名無しさん:05/02/04 19:23:40
>>32
それが分らないから質問してるんですけど。

34 :デフォルトの名無しさん:05/02/04 20:10:02
>>33
そんなのあるのか? って話だと思うけど。
31があると断言しちゃってるけど実際どれよ、FUDじゃねえの? って話じゃないかと。

APUE見りゃちゃんとPOSIXとSysVとBSDで事情がある場合はちゃんと断りがあって、
その上でIPCの機能の記述が通じない「メジャーなUNIX」って一体何を想定してるのか。
元質問者の無知はしょうがないとしても31はちゃんと明確に指摘すべきだろ。


35 :デフォルトの名無しさん:05/02/04 21:24:26
>>34
あんまり厳密な話をしてるつもりはなったのですが、
例えば、GLIBC-2.3.4には>>2にあるPOSIXのドキュメントに載っている
(http://www.opengroup.org/onlinepubs/009695399/idx/head.html)
<trace.h>がなかったりします。こんな感じで微妙に基準を満たしてなかったり
とかするのかなと思ってました。手元にはLinuxしかないので、
*BSDや商用UNIXのことは分りません。

36 :デフォルトの名無しさん:05/02/04 21:36:50
すべてのUNIXで動作するコードを書きたいだけなのか?

37 :デフォルトの名無しさん:05/02/04 21:45:02
>>36
そういうわけではないですけど、何らかの現実的なガイドライン
みたいなのがあれば、それを知りたいなあと思っただけです。
本来ならコード読んで体得するべきで怠けているだけなのは分ってます。

38 :デフォルトの名無しさん:05/02/05 01:21:14
System V IPCがないUNIXがあったら俺の所へ持ってこい!

39 :デフォルトの名無しさん:05/02/05 07:29:32
アホな質問なんですが、
APUEの10.7,10.8のサンプルコードってちゃんと動きますか?
Linux2.6では期待した通りには動きません。
straceで見ると、 readシステムコール中にシグナルが発生しても
普通にreadに戻るだけなんです。

40 :デフォルトの名無しさん:05/02/05 07:31:19
LinuxはLinux Is Not UniXの略だからなぁ。

41 :デフォルトの名無しさん:05/02/05 07:40:35
#include<signal.h>
#include<unistd.h>
static void func(){return;}
int main(){
int n=0;
char line[256];
signal(SIGALRM,func);
alarm(10);
n=read(0,line,256);
alarm(0);
write(1,line,n);
}

$strace ./a.out
...
rt_sigaction(SIGALRM, {0x8048424, [ALRM], SA_RESTORER|SA_RESTART, 0x40046678}, {SIG_DFL}, 8) = 0
alarm(10) = 0
read(0, 0xbffff980, 256) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [RTMIN])
read(0,

select使えばいいんだろうけど。

42 :デフォルトの名無しさん:05/02/05 08:12:12
>>41
ソースの先頭で
#define _XOPEN_SOURCE


43 :デフォルトの名無しさん:05/02/05 08:26:07
>>42
ありがとうございます。

rt_sigaction(SIGALRM, {0x8048434, [], SA_RESTORER|SA_INTERRUPT|SA_NOMASK|SA_ONESHOT, 0x40046678}, {SIG_DFL}, 8) = 0

>>41と違ってrt_sigactionの引数としてSA_RESTARTの代わりにSA_INTERRUPTが入ってますね。

44 :デフォルトの名無しさん:05/02/05 09:29:35
10.12のようにsigaction()でstruct sigactionのsa_flagsに
フラグをきっちり指定してやるのが正しいということですな。
signal()のデフォルトの動作はSysV,4.3BSDはINTERRUCT、
SunOS,LinuxはRESTARTということですな。

お騒がせしました。

45 :デフォルトの名無しさん:05/02/06 00:07:47
4.xBSDが、restartable system callのご先祖様です。

46 :デフォルトの名無しさん:05/02/06 03:52:38
>>45
なるほどそうなんですか。
でも、restartable system callを一番最初に実装したのが4.xBSDだとしても、
ここでの、互換性の話を含むsignalの挙動の話はまた別のですよね?

そもそも上のようなケースがあるから、UNIXではsignal()はもう使うべきではないですね。
マルチプロセスを想定していない、ANSI C特有の関数としてのsignal(),raise()とみなす
べきなのでしょう。UNIXではsigaction(),kill()が正しい。

47 :42=45:05/02/06 09:53:05
glibc$ man 2 signal
(略)
Trying to change the semantics of this call using defines and includes
is not a good idea. It is better to avoid signal altogether, and use
sigaction(2) instead.

signal(2)だけじゃ扱いきれないことが多いですからね。
4.2BSDの頃にはこういう常識が形成されていたと思います。
今手元にないんですが、stevensの"Advanced"にも書いてあったと思います。

48 :デフォルトの名無しさん:05/02/08 13:20:03
sagarisugi


49 :デフォルトの名無しさん:05/02/08 15:18:19
XTIの方がUNIXのインターフェイスらすいと思うのですが、
これってもう誰も使ってないんですか?

50 :デフォルトの名無しさん:05/02/08 15:57:05
らすい?

51 :デフォルトの名無しさん:05/02/08 22:40:00
pthread使ってるからpopen()とか使うな、っつってるのに使いやがったアホ(上司と同義)のために、
「こう書き換えろう゛ぉけっ!」とアドバイスしたいのですが、どういう書き換え方があるでしょうか?

52 :デフォルトの名無しさん:05/02/08 22:45:01
上司を部下に書き換えるとか、勤務先を書き換えるとか

53 :デフォルトの名無しさん:05/02/08 22:50:45
マジレス希望です。

54 :デフォルトの名無しさん:05/02/09 00:02:05
私は popen 使うならシェルからパイプ使えと思う人です

55 :デフォルトの名無しさん:05/02/09 01:06:27
プロセスを走らせながらDLLって書き換えられますでしょうか。。。
dlopen()等でそういった書き換えが考慮されていないプロセスです。

56 :デフォルトの名無しさん:05/02/09 09:06:47
書き換えるのはできないけど、入れ換えるのはできるぞ。
cp libhoge.so /usr/lib/libhoge.so.tmp
mv /usr/lib/libhoge.so.tmp /usr/lib/libhoge.so

57 :デフォルトの名無しさん:05/02/09 12:19:18
入れ替えられても元のdllはロードされたままの罠。

58 :デフォルトの名無しさん:05/02/09 12:25:32
無理やりmunmapしてしまうとか。

59 :デフォルトの名無しさん:05/02/09 15:02:15
dllゆーな。


60 :デフォルトの名無しさん:05/02/09 20:21:36
dllって言う奴はWin上がり

61 :デフォルトの名無しさん:05/02/09 21:54:41
UNIXerはなんて言うの?

62 :デフォルトの名無しさん:05/02/09 21:56:50
そ。

63 :デフォルトの名無しさん:05/02/09 21:58:00
さ。

64 :デフォルトの名無しさん:05/02/09 22:37:10
どるる。

65 :デフォルトの名無しさん:05/02/09 23:39:12
どるるゆーな。

66 :デフォルトの名無しさん:05/02/10 00:03:50
>>56
やっぱ無理ですか。どうもでした。
ちなみにdllってWin用語ですか!?たまたま拡張子がDLLなだけでしょ。

67 :デフォルトの名無しさん:05/02/10 00:15:11
そ。

68 :デフォルトの名無しさん:05/02/10 00:28:17
>>66
なこといっても、dymamic loadable libararyとは言わないもん。
shared libraryだな。

69 :デフォルトの名無しさん:05/02/10 00:35:06
同じというならWindowsのDLL作るのってなんであんなに面倒くさいかね。




70 :デフォルトの名無しさん:05/02/10 00:38:03
誰が同じって言ったんだろう

71 :デフォルトの名無しさん:05/02/10 00:55:21
どるるワラタ

>>68
確か dynamic link library の略だったような。
なぜか soopen() じゃなくて dlopen() だなあ。

72 :デフォルトの名無しさん:05/02/10 14:18:26
>>71
shareされるかどうかの観点 -> so
dynamicにロードされるかどうかの観点 -> dl(l)

73 :デフォルトの名無しさん:05/02/10 17:04:50
>>72
惜しい

74 :デフォルトの名無しさん:05/02/10 17:12:06
>>49
W=リチャード(故)の「UNIXネットワークプログラミング」8000円に
XTIのページが100ページぐらいあって
泣きたくなった

まじでいらん。金その分返せと


75 :デフォルトの名無しさん:05/02/10 17:34:03
>>71
dlopenはもともと別のAPIですから。

76 :デフォルトの名無しさん:05/02/11 21:26:59
perrorを呼んだ後はerrnoの値って変わっちゃうの?
printfは何度呼んでも変わらないようだけど。

int main(void)
{
 errno = ETIMEDOUT;
 printf("errno: %d \n", errno);
 perror("perror");
 printf("errno: %d \n", errno);
 return 0;
}

errno: 2
perror: No such file or directory
errno: 29

77 :デフォルトの名無しさん:05/02/11 21:33:20
そういうもんです

78 :デフォルトの名無しさん:05/02/11 23:16:43
FreeBSDでは変わらんけど。
29ってなんだ?


79 :デフォルトの名無しさん:05/02/11 23:56:23
変らないのはたまたま。
後で利用したければ、保存しなさい。

80 :デフォルトの名無しさん:05/02/12 00:11:46
>>76
perrorが標準エラーに出力するってことは、最終的にwrite(2)が
呼ばれるわけだから、どのみちerrnoが上書きされる可能性がある。

もし、errnoを保存してたとすると、write(2)が失敗した場合のerrnoを
取得できなくなってしまう(可能性も必要性も低いけど)。

こう考えれば納得できるんじゃないかな?

81 :76:05/02/12 00:38:18
>>80
なるほどわかりますた…
あと>>76のETIMEDOUT→ENOENTですた、スマソ
まぁ何でもいいんですが。

82 :デフォルトの名無しさん:05/02/12 21:15:07
>>51
popen()はスレッドセーフだよな?何故使ったらダメなんだ?


83 :デフォルトの名無しさん:05/02/12 21:25:23
pthreadの動作を実際に見せてやれ。
おまいはできる部下だ

84 :デフォルトの名無しさん:05/02/12 21:27:20
>74
本買う前に目録ぐらい見なよ

85 :デフォルトの名無しさん:05/02/12 22:31:57
>>84
ビニールの帯でくくってあってさぁ・・・

86 :デフォルトの名無しさん:05/02/12 22:34:47
>85
何のために常時接続してんだか…

87 :デフォルトの名無しさん:05/02/17 02:45:26
コマンドを実行してそれを返り値にして渡したいのですが
どのような方法があるでしょうか?

具体的には ls -1 *.jpg の結果が欲しいのです
すいませんがよろしくおねがいします

88 :デフォルトの名無しさん:05/02/17 02:52:40
「返り値にして渡したい」の意味が正確には把握できませんが、

  return system("ls -1 *.jpg");

ってことですか? それとも、

  FILE *f = popen("ls -1 *.jpg", "r");
// fから読む

ってことでしょうか?

89 :デフォルトの名無しさん:05/02/17 04:16:35
呼び側で、引数それぞれにつき、BUFSIZぶん確保。
返り値は、エラーの有無。

おもしろかった。

int hoge(char *cmd, char *b)
{
    FILE *fp;
    int ret;

    cmd[strlen(cmd) - 1] = '\0'; /* 改行がくっついてる、と、仮定 */
    printf("cmd: %s\n", cmd);
    if ((fp = (popen(cmd, "r"))) == NULL) {
        perror("popen");
        return (1);
    }
    if ((ret = fread(b, 1, BUFSIZ, fp)) < 1) {
        printf("no output from \"%s\"\n", cmd);
    } else if (ret < 0) {
        perror("fread");
        pclose(fp);
        return (1);
    }
    pclose(fp);
    return (0);
}


90 :デフォルトの名無しさん:05/02/17 04:42:42
??ちょとまずかった??

    if ((ret = (fread(b, 1, BUFSIZ, fp))) < 1) {
        fprintf(stderr, "no output from \"%s\"\n", cmd);
        if (ferror(fp)) {
            perror("fread");
            pclose(fp);
            return (1);
        }
    }

...すみません。もうやめます。

91 :デフォルトの名無しさん:05/02/17 06:11:03
どうしてUNIX厨のソースはこんな醜いんだろう

92 :デフォルトの名無しさん:05/02/17 07:40:22
それがUNIXクオリティ

93 :デフォルトの名無しさん:05/02/17 12:54:54
>>91
それは厨だからさ。

94 :デフォルトの名無しさん:05/02/17 13:22:01
>>91
お前のレベルが低いだけだろ


95 :デフォルトの名無しさん:05/02/17 13:56:20
すみません。よろしければ教えてください。

mailxでメールを送信する際に
添付ファイルをつけて送信することは可能なのでしょうか?

どこぞやにUNIXじゃ添付できないって書いてあったんですけれども
もしできそうならおしえていただけますでしょうか?

96 :デフォルトの名無しさん:05/02/17 13:57:04
帰れ

97 :デフォルトの名無しさん:05/02/17 13:58:42
>>95
板違い

98 :デフォルトの名無しさん:05/02/17 13:59:16
あらら、答えられないなら黙ってればいいのにw
UNIX厨っていつも余計な事するよね

99 :95:05/02/17 14:04:38
もうしわけないです、どこの質問すればいいですか?
誘導願いしますw

UNIXの環境上からmailxで添付ファイルの送り方
があればききたいのですけれども




100 :デフォルトの名無しさん:05/02/17 14:05:32
なんでマニュアル読まないの?

101 :デフォルトの名無しさん:05/02/17 14:06:43
マジレスすると
$ man mailx

102 :デフォルトの名無しさん:05/02/17 14:08:06
$ man ko

103 :95:05/02/17 14:08:38
manなんてインストールしてません
おねがいします
教えてください

104 :デフォルトの名無しさん:05/02/17 14:10:09
マニュアル熟読しないと使えない時点で糞だよね
UNIXなんて捨てたら?

105 :デフォルトの名無しさん:05/02/17 14:11:45
man入れてないんだったらオンラインマニュアルでもなんでもあるだろが
考えろよ

106 :デフォルトの名無しさん:05/02/17 14:13:13
つーかおまえがmanなんて見ても参考にならねーと思う
あきらめろ

107 :95:05/02/17 14:14:06
ばーか

108 :デフォルトの名無しさん:05/02/17 14:14:20
ここはプログラミングのスレであって、ツールの使い方のスレではない。

109 :デフォルトの名無しさん:05/02/17 14:15:16
シグナルってシグナルハンドラからすぐにリターンしないとだめ?
そのまま延々と処理を続けてもいい?


110 :95:05/02/17 14:15:25
なんだかんだと言い訳ばっかでつかえねーやつら。
氏んだらいいと思うよ。

111 :104:05/02/17 14:15:27
はいはいそうですね
そのとうりです
だからもうUNIXと言う文字があるところにはかかわらなくていいですよ
じゃぁね ばいばい

112 :デフォルトの名無しさん:05/02/17 14:16:37
いやでも、
UNIXで挫折って、わかる気がするなあ。
ずっと意味不明なコマンドの文字列打ってたら頭おかしくなりそうだし、
ずっと真っ暗なコンソール眺めてると鬱になりそうじゃん?
かといって思想のまるでないXは、オタ絵とただ沢山コンソール開くしか脳ないし、
こんなの与えても娯楽を常に要求する一般人は見向きもしない。
そもそもWebでしか見掛けない、哀れなOS、というのが一般人の見解だし。
そうそう、最近LindowsがUNIXの印象かなり悪くしたよね。
この事件でUNIXはビジネスで成功できないことがまた証明されてしまったわけだ。
昔からUNIXは関係者同士で常に足を引っ張って成長しない。
お金の匂いしないよね。全然。
そんなOSだから、挫折が常態であるのは必然なんだと思う。

113 :デフォルトの名無しさん:05/02/17 14:18:01
>>109
いいよ
Xのメセージは全部シグナルだし

114 :デフォルトの名無しさん:05/02/17 14:25:17

元95です。偽者発生してもうきけるふんいきじゃないですね。残念です。

man 英語だったんでうーんって感じだったんですけど
あとSHELLからコマンドで毎日定時に送るようにしたかったんですけど、

まあがんばって訳してみます。

結果あらしてすみませんw

115 :デフォルトの名無しさん:05/02/17 14:33:24
ここは役立たずの巣窟

116 :デフォルトの名無しさん:05/02/17 14:36:52
95は何を使ってるんだ?
話はそれからだ

117 :デフォルトの名無しさん:05/02/17 14:45:51
オソル オソル キイテミル
現在実行中のプロセスが「自分自身」の絶対パスを知る方法ってありますか?
適当な path がとおってる環境下で、$ hoge <arguments...> とやったときに、
そのプログラムのなかで、hoge が /usr/bin/hoge なのか /usr/local/bin/hoge
なのかを知る方法でつ。
argv[0] を拾っても、上記の例だと hoge が得られるだけだし・・・

118 :デフォルトの名無しさん:05/02/17 14:53:28
>>117
Linux なら自身のpidを取得して/proc/pid/exe辺りを見ればいいんだけど。
man 5 proc で説明でると思う。他のOSの場合どうするのかは知らん。

119 :デフォルトの名無しさん:05/02/17 14:55:34
>>117
普通に考えると、ない。

120 :114:05/02/17 15:40:39
SunのSolaris 8です

これでこたえなってます?

121 :デフォルトの名無しさん:05/02/17 15:42:08
>>118
ほんとUNIXって使えないね

122 :デフォルトの名無しさん:05/02/17 16:03:21
>>114
だから、ここはプログラミング質問スレなんだから
プログラムの使い方を聞くなってば。

123 :デフォルトの名無しさん:05/02/17 16:09:39
>>111
>そのとうりです
とうり?

124 :デフォルトの名無しさん:05/02/17 16:33:36
>>118 ありがd 調べてみまつ。
>>119 確かに >>118 さんに教えて頂いた方法は「普通」の方法っぽくはないですね。
もっと簡単に出来そうなんだけど・・・
以下のような動作するコマンドって、珍しいものですか?
usage:
 hoge (-f <conf file>)
-f で設定ファイルが指定されればそのファイルを使うけど、オプション指定なしで起動された
場合は、hoge 自身が置かれているディレクトリ直下の conf file を使います(default)。
みたいな・・・

125 :デフォルトの名無しさん:05/02/17 17:25:45
>>95 氏は自分のやりたいことが分かっていないんじゃないかな。
ここで聞くより mailx と MIME でググると少しは幸せになったのに。


126 :デフォルトの名無しさん:05/02/17 17:25:45
>>117
確実に(どんな場合でも)取得する方法はない。
起動後にchroot(2)してたらパスが存在しないことすらありえるし。

127 :デフォルトの名無しさん:05/02/17 17:44:02
>>124
「hoge 自身が置かれているディレクトリ直下の……」というようなことは
「しない」っていうのがUNIXでの流儀なんですよ。
デフォルトのパスは定数として埋め込むのが安全です。


128 :デフォルトの名無しさん:05/02/17 17:47:50
>>124 >>127 さんの言う通りじゃ。どこぞのOSの悪い習慣は捨てなされ。

いくつか流派があるが、GNU流の設定ファイルの置き場のお作法はこうじゃ
ttp://www.sra.co.jp/wingnut/standards/standards-ja_7.html#SEC54


129 :デフォルトの名無しさん:05/02/17 18:17:03
>>128
そんなに悪いものかな?
まあ、郷に入りては郷に従え、と。

130 :デフォルトの名無しさん:05/02/17 18:33:07
そもそも1つのファイルは複数の場所に存在できるんだから、
「自身が置かれているディレクトリ」なんて特定できるわけがない。

131 :デフォルトの名無しさん:05/02/17 18:35:51
↑馬鹿?

132 :デフォルトの名無しさん:05/02/17 18:39:31
>>129
動作を既定する設定ファイルなら、利用者ごとに設定できるようにするべき。
実行モジュールと同じディレクトリに置くという悪しき習慣の弊害は、
Win95時代のソフトウェアがAdministratorでないと設定を変えられない+
利用者ごとに設定できないという形でも現れている。

また、環境に依存するような設定ファイルなら、アプリケーションに埋め込むか
システムで管理するデータベースなどに登録するのがいい。
ここでもやはり、実行モジュールと同じディレクトリに置くというメリットは殆ど無い。

133 :デフォルトの名無しさん:05/02/17 18:41:21
>>130
ああそうか、そういう問題もあるね。今まで気付かなかったよ。

134 :デフォルトの名無しさん:05/02/17 18:55:36
>>132
つーか一体いつの時代のWindowsとアプリを批判してるんだよ・・・

135 :デフォルトの名無しさん:05/02/17 18:57:37
>>132
95くらいだとまだシングルユーザーだったからなぁ……
確かにそういう習慣はあったけれど今ではそれなりに改善されてるよ。
まだ昔の習慣引きずってるアプリケーション多いけどね。
普段Windowsしか使ってなかったから気付かなかったよ。参考になった。ありがとう。

136 :デフォルトの名無しさん:05/02/17 19:29:19
>>126-135
サンクスです。 脳内仕様を、も一回見直してみます。


137 :デフォルトの名無しさん:05/02/17 21:09:15
つーかインストール先のデータ使うなんて普通にありそうだが

138 :デフォルトの名無しさん:05/02/17 21:36:16
>>137 守ってね。管理面倒になるから。
http://www.pathname.com/fhs/pub/fhs-2.3.html


139 :デフォルトの名無しさん:05/02/18 00:13:21
自己解凍書庫とか作れないじゃん


140 :デフォルトの名無しさん:05/02/18 00:24:45
>>139
そこでsharですよ

141 :デフォルトの名無しさん:05/02/18 01:04:11
つーかシェルでは自分自身取得できるってことじゃん
無茶苦茶だな

142 :デフォルトの名無しさん:05/02/18 01:09:34
馬鹿が多いな
自己パス得られないのはUNIXの欠陥の1つだよ

こいつ(>>138)こんなリンク張れば騙される奴がいるとでも思ってんだろうなw

143 :デフォルトの名無しさん:05/02/18 01:15:35
UNIXはそういう便利関数が標準化される前に廃れちゃったからね。
POSIXにもないってのは失敗かもな。

144 :デフォルトの名無しさん:05/02/18 01:19:47
まー、それでもなんとかなってるから別にいいけどね。

145 :デフォルトの名無しさん:05/02/18 01:21:20
>>141
シェルとCで機能の同期が取れてないのはヤバイ
創作の妨げでしかない


146 :デフォルトの名無しさん:05/02/18 01:23:14
はい、これでUNIXのヤバさが1つわかりましたね

147 :デフォルトの名無しさん:05/02/18 01:27:05
ハイハイ

148 :デフォルトの名無しさん:05/02/18 01:30:22
WindowsではAPI一個呼べば済む問題が、
UNIXでは流儀やら互換性やら実現不能やらで大騒ぎ
たしかにアフォすぎる

149 :デフォルトの名無しさん:05/02/18 01:33:30
ファイルシステムのセマンティクスからして違うのに無視して騒ぐバカがいるな。


150 :デフォルトの名無しさん:05/02/18 01:35:17
ム板なんてWin厨ばっかなんだからしょうがないべ。


151 :デフォルトの名無しさん:05/02/18 01:35:57
こんどは意味論で擁護か
おめでたい頭だな
UNIX板で普及スレとか立ってたけど
こんなアフォばっかじゃ永久に無理

152 :デフォルトの名無しさん:05/02/18 01:42:16
それ結構昔だね。
おれも無理だと思う。

153 :デフォルトの名無しさん:05/02/18 01:45:20
まあ、ファイルがバラけるのを良しとしない人は多い気がする。
2chでそういう便利関数集めた汎用ライブラリ作らない?
主要UNIX環境で動くようなやつを。
完全PDSで。

154 :デフォルトの名無しさん:05/02/18 01:50:15
PDSて・・・
PC98出身のフリーウェア作者かい?

155 :デフォルトの名無しさん:05/02/18 01:50:35
じゃあ、とりあえず
・Linux、*BSD、SunOS等のメジャーな奴のやり方教えてくれ
Linuxでのやり方は上に書いてたっけ。

156 :デフォルトの名無しさん:05/02/18 01:51:50
シェルスクリプトならフルパスが得られるんだから、バイナリでもフルパスが
欲しいなら
#! /bin/sh
dir=$(dirname $0)
exec ${dir}/../lib/hoge/hoge.bin "$@"
みたいにするだけだよ。
jdk とか firefox とかでも使ってる、割とメジャーな手法。

157 :デフォルトの名無しさん:05/02/18 01:53:40
じゃあそれ最初に言えよ・・

158 :デフォルトの名無しさん:05/02/18 01:56:54
>>157
そういうシェルスクリプトを作るってことだから。
たぶん何の解決にもなってない。
UNIXは製作者側のセキュリティ保護をまったく考慮しないOS。

159 :デフォルトの名無しさん:05/02/18 01:57:51
つまり嘘ファイルを掴まされてもわからんてことね。

160 :デフォルトの名無しさん:05/02/18 01:58:12
それ引数にフルパス渡せばフルパスが分かるっていってるだけですから〜残念!

161 :デフォルトの名無しさん:05/02/18 02:02:25
シェルスクリプトで出来ることがCで出来ないとでも思ってるのか?


162 :デフォルトの名無しさん:05/02/18 02:04:10
ここはひどく汚染された釣堀ですね

163 :デフォルトの名無しさん:05/02/18 02:06:33
釣り師もレッテル貼るしか能が無いしな。


164 :デフォルトの名無しさん:05/02/18 02:12:52
>>134
>>132の言う問題が明確に問題視されたのは、
Windows 2000 TSEのマルチユーザアプリケーションのガイドラインができてからですね。
その時からWindows(TSEやXP)でも>>124のやり方はガイドライン違反です。
今やMac OS Xでもそうです。


165 :デフォルトの名無しさん:05/02/18 02:14:22
実行可能ならパスは通っているはずだから環境変数PATHを走査して…ってwhichみたいなことをする他ないのか…

166 :デフォルトの名無しさん:05/02/18 02:16:40
違反って言い方は不正確だな。
Windowsロゴを取得する際に要求される仕様だってだけ。
しかもそれはユーザーデータの保存場所の指定に関してであって
カレントディレクトリのコンフィグレーションを読むのは
.NETアプリだって普通にやってるよ。

167 :デフォルトの名無しさん:05/02/18 02:21:38
>>165
パスが通ってない所のものでも実行できるべ?

168 :デフォルトの名無しさん:05/02/18 02:22:13
元々UNIXは専用マシンと一緒に買わせる抱き合わせ商法。
抱き合わせ商法が許されたのは20年以上前の秋葉原ぐらいだが、
現在も生き残ってるベンダーは、今でもその商法で売っている。
まさに20年前の思想。
当然ソフトウェアの保護にはものすごく疎い。
ぶっちゃげ自分のシステム以外の事はどうでもよく、問題を認識してすらいない。
ベンダーはマシンを買ってもらえれば元が取れるからわれ関せず。
不正ユーザーにとっては、動いているソフトは勝手にクラックしてください
と言わんばかりの無法地帯。

169 :デフォルトの名無しさん:05/02/18 02:24:49
>>167
それなら明確に起動時にパスを指定してるから位置がとれるだろうよ。

170 :デフォルトの名無しさん:05/02/18 02:27:18
>>168
とはいえ、今のUNIX(互換OS)の主流であるLinux系やら
BSD系は通常ハードウェアについてこないぞ。

MacOSはついてくるな。

PCは、MSとの契約でWindowsを抱き合わせしないと販売できない
(Windowsを供給してもらえない、仕切り値が高くなる)ようになってる。

171 :デフォルトの名無しさん:05/02/18 02:28:16
>>169
まあ1クッション置けばそうかもしれんが・・・

172 :デフォルトの名無しさん:05/02/18 02:28:36
>>167
あぁ、そうか。あかんね。
カレントディレクトリとargv[0]を繋げるとか…駄目っぽい。

173 :デフォルトの名無しさん:05/02/18 02:35:26
lsは常に/bin/lsでないとこまる。
たとえば/tmp/.../lsとか、./lsはあやしい。

174 :デフォルトの名無しさん:05/02/18 02:38:15
そういう話じゃないだろ。

175 :デフォルトの名無しさん:05/02/18 02:40:36
UNIX板には、シェルスクリプト、よくてperlやrubyスクリプトを
ネチネチいじってオナニーしてる連中しか居らんべ?

176 :デフォルトの名無しさん:05/02/18 02:42:52
argv[0][0]が
・'/'なら絶対パス。
・'/'でなくargv[0]に'/'を含むなら相対パス。
・そうでないならPATHを調べる。
でどう?

177 :デフォルトの名無しさん:05/02/18 02:45:05
argv[0] はただの引数
execl("/path/to/your/program", "/bin/cat", "hoge", NULL);
されたらどうするよ。

178 :デフォルトの名無しさん:05/02/18 02:46:49
出来ません。デフォルトパスは~/にするよろし。
でいいじゃん。

179 :デフォルトの名無しさん:05/02/18 02:47:40
>>177
もちろんお手上げ。

180 :デフォルトの名無しさん:05/02/18 02:49:16
というかmain()に入ったときには
ファイルはunlinkされてるかもしれんし

181 :デフォルトの名無しさん:05/02/18 02:53:23
どうしてできません。ごめんなさい。の一言がいえないのか。

182 :デフォルトの名無しさん:05/02/18 02:54:20
>>180
確かにそれはそうなんだが、そこまで含めてしまうとなあ・・・
せめて自分自身の実体があった場所とか欲しいな

183 :デフォルトの名無しさん:05/02/18 02:57:09
psの -o comm とか -o args は
プロセス構造体とかユーザ構造体から
取得してるのですか??

184 :デフォルトの名無しさん:05/02/18 03:05:32
>>177
ところでpsコマンドで見れるのは
>execl("/path/to/your/program", "/bin/cat", "hoge", NULL);
で言うと"/path/to/your/program"?それとも"/bin/cat"?
今端末の前に居ないんで確認できないんだ。
折角自身のPIDが分かるのにそこから引き出せないのかな?

すみません、ごめんなさい、出来ないみたいです、諦めます。

185 :デフォルトの名無しさん:05/02/18 03:16:40
ld.so(1)さんが、頑張ってますんで参考に。

186 :デフォルトの名無しさん:05/02/18 03:30:38
>>181
ここまでの議論は既にできないことを前提に、
ではどうするかということに移ってると思うんだが。

なぜ謝る必要があるのかわからんな。
そういうことはKen ThonmsonやらPOSIX作ったやつらやらに言っとくれ。

187 :117 = 124:05/02/18 08:35:27
>>117>>124 でつ。 @自宅なので、ID 変わっとります。
自分の書き込みに、こんなにたくさんレスがついたの、初めてです。 やっと、ヒッキー卒業
できそうな気がしてきました。 釣り師の快感も理解でき(ry
とまれ、>>127 >>128 のご意見は参考になりますた。
それと、>>181。 一番、オモシロカターヨ。
ミンナ、アリガd

188 :117 = 124:05/02/18 08:36:01
↑ つーか、ID ないじゃん

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

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

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


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

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


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

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

195 :デフォルトの名無しさん: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 :デフォルトの名無しさん:05/02/18 11:41:17
>>195
それは「設定ファイルが見付かりません」でいいんじゃないの。

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



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


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

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



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


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



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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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 されて、
自分を開いているプロセスも1個もなくなったら消えます。

一時的に使うファイルを、オープン直後に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
商用UNIXってどういう定義なの?
MacOSXは商用UNIXに含まれますか?

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
ttp://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ってなんだよww

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
http://www.gnu.org/software/libiconv/

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
1文書に複数文字コードが入ってるとか,そういうややこしいのじゃなくて
1文書が1つの文字コードに限定されてるんです.

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

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

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

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

407 :デフォルトの名無しさん:05/03/01 23:36:56
>>335
http://tricklib.com/cxx/ex/babel/
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くらい理解してからレスしろよ、この屑。
http://www.opengroup.org/public/tech/aspen/lp64_wp.htm

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も読め。

428 :デフォルトの名無しさん:05/03/07 20:29:51
128bit化なんてその時になってから泥縄的に考えればいいんだよ。
もし動かなかったらIBMに金出させて力技で修正すればいいだけ。
今困っていない事を今対応するな。これがLinuxのモットーだ。

429 :デフォルトの名無しさん:05/03/07 20:33:26
128bit が主流になる頃はおいらは隠居してる.
勝手にやってくれ.


430 :デフォルトの名無しさん:05/03/07 20:48:26
というか32→64の経験でスキームは固まっている。

431 :デフォルトの名無しさん:05/03/07 20:52:54
ところでIPV5って64bitだったの?

432 :デフォルトの名無しさん:05/03/07 20:54:59
型同士の相対的な関係と実際のデータ長っていう
二つの視点で見るとこんなかな。

UNIXは32bit,64bitそれぞれILP32とLP64だけど、
char:short:int:longそれぞれ
ILP32 8:16:32:32 32(pointer)
LP64 8:16:32:64 64(pointer)

ILP32からLP64への移行で変わったのは、
(int,long)と(int,pointer)の相対的関係が変わったことと、
longとpointerの実際のデータ長が変わったということ。

char:short:int:long:long long
ILP128 8:16:128:128:128
LP128 8:16:32:128:128
LLP128 8:16:32:64:128
128bitCPUにおいてはこんな感じのがありえると思うけど、
今UNIXで32bit64bit両方に通用するコードとしてlong=pointerという
仮定の元にコードを書いてしまうともうLP128しかないと思うんだよね。
というかILP32から64bit化においてLP64を採用した時点で
long=pointerという想定を受け入れてるように見える。

ILP128はちょっとありえないね。LP64でせっかくintの実データ長を32で固定した意味がなくなる。
LLP128が1番よさそうに見えるけど、LP64からlongとpointerの相対的関係が異なる。
素人考えだとLP128しかなさそうに見えるけど。

433 :デフォルトの名無しさん:05/03/07 21:01:51
つーか128bit時代にもなってLinux使ってたとしたらソフトウェア界の敗北だな。

434 :デフォルトの名無しさん:05/03/07 21:02:19
> LP64からlongとpointerの相対的関係が異なる

だから intptr_t, uintptr_t を使えってばさ。
それで問題なし。


435 :デフォルトの名無しさん:05/03/07 21:43:35
32bitマシンって1960年代にできて、64bitマシンって1990年頃
だよね。30年くらいかかっている。
同じような指数的ペースで発展する(1年で1bitくらい)として
128bit マシンができるのは、2050年を過ぎたぐらい…

俺は死んでるな。

436 :デフォルトの名無しさん:05/03/07 21:46:46
UNIX/Cを潰したいメーカーが96bitマシンとか出して来たりして。

437 :デフォルトの名無しさん:05/03/07 22:51:54
なぜbit数が増えるのか
という根源的な疑問は起きないのか?

438 :デフォルトの名無しさん:05/03/07 22:59:35
基本的にはストレージのサイズが増えるからという要因が
一番大きいでしょ。(AS/400 みたいに、アドレス空間の
ほとんどを無駄に捨てざるをえないアーキテクチャだと
話は別だが。)
問題は、現在の指数関数的なストレージサイズの増大が、
あと50年続くかどうかと、たとえ続いたとしても、そんなに
使い道があるかどうかだな。
64ビットでも、人類ひとりひとりに、それぞれ2GB以上も
あるというのに。

439 :デフォルトの名無しさん:05/03/07 23:02:38
いつの時代もそういう近視眼的な発言をする奴がいたわけで

440 :デフォルトの名無しさん:05/03/07 23:05:37
いつの日にか、家庭向けPCで地球シミュレーションが軽く動く日がくるんだよ

441 :デフォルトの名無しさん:05/03/07 23:07:41
昔、12bit マシンってのもあったぞ。

442 :429:05/03/08 01:57:05
>>439
438 じゃないんだけど, そのころはおいらは隠居してるわけだ.
興味ねぇ.

>>438
> 基本的にはストレージのサイズが増えるからという要因が
> 一番大きいでしょ。

数値計算とかやってると, アドレッシングできる領域がどれだけ増
えても実際の計算速度が上がらないと, メリットは小さい.
やっと 64bit を有効に使える計算速度に達したってのが現実では?

# DB 検索なんかでもそぉだと思うぞ, エンジン作ってる連中にし
# てみれば...


443 :デフォルトの名無しさん:05/03/08 01:59:32
>>429
ダウト。
データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。


444 :デフォルトの名無しさん:05/03/08 02:36:39
ファイルシステムが2G4G以上をサポートしてる時点で64bit化の恩恵を受けられるわけで。

445 :デフォルトの名無しさん:05/03/08 03:12:48
>>444
ブー。mmapが使えないと結構苦しい。


446 :445:05/03/08 03:13:48
なんか444へのレスとするのは意味不明だな。ごめん。


447 :デフォルトの名無しさん:05/03/08 03:28:32
32bit,64bitそれぞれのシステムでintとlongを使い分けてるけど、
これは一言でいってどういう事情によるものなのかしら?
Linux linux/include/asm/posix_types.h
BSD sys/arch/`uname -m`/include/ansi.h

/*i386*/
#define _BSD_SIZE_T_ unsigned int
#define _BSD_CLOCK_T_ unsigned long
/*amd64*/
#define _BSD_SIZE_T_ unsigned long
#define _BSD_CLOCK_T_ unsigned int

448 :デフォルトの名無しさん:05/03/08 03:35:29
Linuxの場合
/*i386*/
typedef unsigned int __kernel_size_t;
typedef long __kernel_clock_t;

/*amd64*/
typedef unsigned long __kernel_size_t;
typedef long __kernel_clock_t;

449 :デフォルトの名無しさん:05/03/08 05:16:22
つまりポインタをlong型で扱う奴はバカint型で扱う奴はもっとバカってことでいいですか?

450 :429:05/03/08 07:20:28
>>443
> データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。

そぉゆう意味で言ってるんだが...
「やっと」ってゆう言い方が悪かった. すまん.
おれ的には, やっと 10年くらい前からってな感覚だったもんで...

当初からそれなりに, 64bit マシンはメモリバス帯域広いし, マル
チプロセッサ化するために, バスのクロスバ化なんて, ハードウェ
ア的に見た場合, 非効率以外のなにもんでも無いようなことまでやっ
てるところもあるし...
それ以前は, こんなぜいたくはスパコンにしか許されなかったわけ
だから...


451 :デフォルトの名無しさん:05/03/08 07:39:51
http://pc5.2ch.net/test/read.cgi/tech/1109793931/l50

452 :デフォルトの名無しさん:05/03/08 09:07:01
printfでtypedefな型を扱えればいいんだが

453 :デフォルトの名無しさん:05/03/08 09:12:18
>>448
BSDの方の型は、ユーザー空間にも公開しているものなので、
一度決めると変えない方がいいんじゃないかな。まあユーザー
プログラムが行儀良く書かれていれば、同じサイズの型に
変えても問題ない筈だけど、行儀良く書かれてない場合、
int と long の食い違いが生じると、lint では警告さえる
ケースがありそうな。
あとは、その CPU アーキテクチャの ABI の仕様書に書かれて
いる型名に合わせてるとかもあるかも。

Linux の方はカーネル内部用の型に見えるなので、良くわかんない。


454 :デフォルトの名無しさん:05/03/08 09:29:17
>>452
C99 なら一応できるよ。

intptr_t x; なら
#include <inttypes.h>
printf("%" PRIdPTR "\n", x);
とか。

typedef intptr_t MyType;
してるなら同時に
#define PRIdMYTYPE PRIdPTR
もとしておいて、MyType の printf には
PRIdMYTYPE を同様に指定すればいい。

size_t も "z" 修飾子を使ってどうような
ことができる。


455 :デフォルトの名無しさん:05/03/08 09:43:57
>>454
> size_t も "z" 修飾子を使ってどうような
> ことができる。

ついでにここも詳しく……


456 :デフォルトの名無しさん:05/03/08 10:48:23
128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは
相当長い間必要ないだろ。データバスが128bitなのはGPUじゃ
当たり前になってるんだろうけど。

16bit -> 32bit アドレス空間は6万5千倍。
32bit -> 64bit アドレス空間は42億倍。

このアドレス空間を使い尽くすのっていつ頃?
ヘタしたら人間が絶滅してるかもなw

457 :デフォルトの名無しさん:05/03/08 10:49:29
>128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは
                   ↓
128ビットCPU(データバス幅>=アドレスバス幅=128bit)なCPUは

458 :デフォルトの名無しさん:05/03/08 11:21:26
>>455
z A following integer conversion corresponds to a size_t or
ssize_t argument. (Linux libc5 has Z with this meaning. Don't
use it.)

#define PRIdSIZE "z"

こういうのあんまり好きじゃないが。

459 :デフォルトの名無しさん:05/03/08 11:22:55
>>458
うちのシステムには入ってないや……。


460 :デフォルトの名無しさん:05/03/08 11:24:18
あ、標準では定義されてないけど458のように定義すりゃ同じようにできるよ、って
話かな?


461 :デフォルトの名無しさん:05/03/09 13:00:27
そゆこと。でも>>458みたいにするんじゃなくて
#define PRIdSIZE "zd"
の方がいい。小文字の「d」の意味がなくなっちゃうから。
#define PRIxSIZE "zx"
とかしたいしね。


462 :461:05/03/09 13:46:14
補足。
C99を前提にしていいソフトなら、#defineせずに
"z"を直に書いた方がいいだろうけどね。
#defineする必要があるのは、C99より前の処理系
への移植を考慮する必要があるケースと、あとは
typedef size_t MyType;
#define PRIdMYTYPE "zd"
のように、自分で定義した型に対して printf の
フォーマット文字列を提供したい場合。


463 :デフォルトの名無しさん:05/03/09 23:29:27
linuxで、mallocの関数の中身を知りたくて探してるのですが見当たりません。
glibcのソースを探してるのですが。。どこにあるのでしょうか?

464 :デフォルトの名無しさん:05/03/09 23:32:00
>>463
ダウンロードした場所にありましたよ

465 :463:05/03/09 23:37:42
ダウンロードした場所ですか?
うーん。glibc-xxx/malloc/malloc.cの中とかその周辺とか調べたんですがないんですよ。。

466 :デフォルトの名無しさん:05/03/09 23:38:51
入れなきゃ無いわな

467 :デフォルトの名無しさん:05/03/09 23:40:22
勝手にソース覗くのはストールマンに失礼ですよ。

468 :デフォルトの名無しさん:05/03/09 23:43:22
>>467
アホ発見


469 :463:05/03/10 00:03:13
検索したらやっとそれらしいのにヒットした。。
http://www.gelato.unsw.edu.au/linux-ia64/0111/2457.html
>BTW, calloc is included in malloc.c.
> You would like to open the file glibc-2.2.4/malloc/malloc.c,
> and then you will be looking for cALLOc. It is calloc function.
そういえばmALLOcみたいな変なのがあったな。。
今ソースがないので明日調べてみます。お騒がせしました。

470 :デフォルトの名無しさん:05/03/10 00:38:22
UNIXのソースってなんでこんなに汚いの?

471 :デフォルトの名無しさん:05/03/10 00:39:56
お前の顔より綺麗だ

472 :デフォルトの名無しさん:05/03/10 16:32:09
なんで俺の顔知ってんの?

473 :デフォルトの名無しさん:05/03/10 17:16:57
基本

474 :デフォルトの名無しさん:05/03/10 20:35:26
おそらく基本的な質問だとおもいますが
-lpthreadのリンクを下のようにMakefileで記述するとcannot find -lpthreadという
エラーがでてしまいます。

test:main.o sub.o
gcc -o test main.o sub.o -lpthread
main.o:main.c test.h
gcc -c main.c test.h
sub.o:sub.c test.h
gcc -c sub.c test.h

コンソールで一つずつコンパイルしていけば問題はないんですが・・・
よろしくおねがいします

475 :デフォルトの名無しさん:05/03/10 21:34:31
-lpthreadをオプションと認識していないみたいですな。
それはともかく、スレ違いです。

476 :デフォルトの名無しさん:05/03/10 21:46:46
>>475
Unixプログラミングの場合、スタンダードなIDEがないので、
Makefileやコンパイルオプション指定をする段階から
すでにコーディングの戦いが始まっていると思うのは俺だけですか?

477 :デフォルトの名無しさん:05/03/10 21:50:13
ある程度以上の規模なら、IDEを使おうと使うまいと
素敵なビルドの仕組みを作ることは
コード自体を書くことと同じくらい重要でぷ。

478 :デフォルトの名無しさん:05/03/10 21:51:24
だからあれほどUNIX捨てろって言ったのに・・・

479 :デフォルトの名無しさん:05/03/10 21:53:09
Windowsだとマウスでポチポチやるだけで終わる作業なのにねえ。
UNIXって頭悪すぎ。

480 :デフォルトの名無しさん:05/03/10 21:56:15
みえみえの展開に萎え

481 :デフォルトの名無しさん:05/03/10 21:58:32
>>474
-lpthread の前に変なコード入ってないか od ででも確認してみたらどうだろう。

482 :デフォルトの名無しさん:05/03/10 22:20:31
>>480
みえみえというか、すでに1つのお約束になってますな。
お約束は美しい。

483 :474:05/03/10 22:49:23
>>481
もう一回書き直してみましたけど直らないです
あとコンソール直打ちでもcannot findになってしまいました・・・

484 :デフォルトの名無しさん:05/03/10 22:54:35
コンソール直打ちでうまくいってたときと、ダメなときの違いはなんなのよ。
libpthread.* がリンカから見えてないんじゃない?

485 :デフォルトの名無しさん:05/03/10 23:12:02
たぶん環境変数 LD_LIBRARY_PATH が設定されてたとか、
そういう話じゃないの? でも libpthread が /usr/lib
にない OS ってなんじゃろ? NetBSD-1.6 とか?

486 :デフォルトの名無しさん:05/03/11 00:22:44
>>474
UNIXの種類は何か書いた方がいい。
それ専用の板やスレに行くとモアベター。

487 :474:05/03/11 00:29:21
OSはFreeBSD4.11です。専用スレへ行ってきます
スレ汚しすいませんでした

488 :474:05/03/11 01:00:05
なんか-lpthreadを-pthreadにしたらリンクできた・・・
ちゃんと動いてるし・・・いいんだろうか・・・(´・ω・`)

489 :デフォルトの名無しさん:05/03/11 01:03:57
>>488
いいです。
-pthreadで、マクロの定義、ライブラリの適切な処理等を行います。

490 :474:05/03/11 01:11:28
>>489
どうもありがとうです
前にコンソールでやったのは-pthreadだったかもしれなかったです

491 :デフォルトの名無しさん:05/03/11 01:22:00
この謎仕様も悪しきUNIX譲りですか?

492 :デフォルトの名無しさん:05/03/11 01:45:01
ここはUNIXプログラミング質問スレですが何か?

493 :デフォルトの名無しさん:05/03/11 01:45:43
やっぱWindowsの方がちゃんとしてるな。

494 :デフォルトの名無しさん:05/03/11 16:15:29
スレッドってそんなにいいのか?

495 :デフォルトの名無しさん:05/03/11 17:07:19
はい。

496 :デフォルトの名無しさん:05/03/12 00:40:12
俺よりもいいのか?

497 :デフォルトの名無しさん:05/03/12 00:42:55
ごめんなさい。

498 :デフォルトの名無しさん:05/03/12 01:27:23
roz 違う… orz

499 :デフォルトの名無しさん:05/03/12 07:49:46
・・・

500 :デフォルトの名無しさん:05/03/12 14:35:34
>>491
ハァ?プログラミングは「UNIXこそが仕様」ですが何か?

501 :デフォルトの名無しさん:05/03/12 14:51:54
>>500
-pthreadはUNIX仕様じゃなくて、gccの仕様だろ。

マニュアルに書いてある仕様を謎と呼ぶのは
マニュアルも読めない厨房だけだがな。


502 :デフォルトの名無しさん:05/03/12 14:58:09
マニュアルってどこに売ってるんですか?

503 :デフォルトの名無しさん:05/03/12 15:34:57
groff出力のテキストまたはポストスクリプトが、
アマゾン川流域で、約1000ペソ。

504 :デフォルトの名無しさん:05/03/12 16:05:24
>>503
日本で買えませんかねぇ・・・

505 :デフォルトの名無しさん:05/03/12 18:31:50
もうPOSIXだのANSIだのめんどくさいよ
ぜんぶMSのWindowsにあわせればOKだよ。

506 :デフォルトの名無しさん:05/03/12 20:59:20
WindowsのmessageとPOSIX Message Queueってどう違うの?

507 :デフォルトの名無しさん:05/03/12 22:46:22
商用UNIXだったらしっかりしてるんだけどね。

508 :デフォルトの名無しさん:05/03/14 01:07:10
UNIXやWindowsで動く自作言語を作っているのですが、
UNIXの例外処理はどんなロジックを使えばよいでしょうか?
Windowsの場合はSEHという機構を使ってます。
Javaでいうfinallyやcatch辺りの処理の話です。


509 :デフォルトの名無しさん:05/03/14 01:21:57
>>505
MSのWindows(ゲイツ)は、POSIXだのANSIにあわせるよう努力してくれるが、
逆の努力は誰もしてくれない。

Unixに腐敗臭が漂うのも無理はない。19世紀の老大国を見る思いだ。

510 :デフォルトの名無しさん:05/03/14 01:54:34
ようするにUnixは何をやるにしてもダメっていうことね。

511 :デフォルトの名無しさん:05/03/14 01:57:38
そうだね。UNIXも使えない人な何をやってもダメだね。

512 :デフォルトの名無しさん:05/03/14 01:58:46
皮肉でしか返せないんだね

513 :デフォルトの名無しさん:05/03/14 02:04:42
>>508

実装言語による。
C++で書くなら、C++標準の例外処理処理機構を使えばいいんじゃない?
Cで書くなら、自分で明示的に制御するしかない。


514 :デフォルトの名無しさん:05/03/14 02:06:48
WindowsがやってるPOSIXに合わせようとする努力って
なんの話? SFUのこと言ってるのかな?
だったらUNIX上での似たようなものとしてはWineとか
Monoがあるよ。
というわけで、逆の努力もしてるってことで終了。


515 :デフォルトの名無しさん:05/03/14 02:38:16
コンパイラをANSIに対応させるのは当たり前だし
WindowsNTにPOSIXサブシステムがあったのは「POSIXに準拠してないと導入しない」と
アメリカの政府機関が言い出したからなんだけどな

516 :デフォルトの名無しさん:05/03/14 03:01:02
>>515
NT系Windowsの POSIXサブシステムはそういう話だね。
はっきり言ってあれは全く使いものにならんかった。
FIPS規格に通ることだけが目的で、実用性ゼロ。

でもSFUの方は結構ましだと思うけど。
もちろん、ソースレベルの限定的な互換性しかないから、
バイナリ互換性を提供してくれるWineやMonoには劣るけど。

517 :デフォルトの名無しさん:05/03/14 04:09:45
Unixer達はなんだかんだ言いながらもWindowsのアプリを動かしたくてたまらないちうことやね。
憧れちゃいますかそうですか。

518 :デフォルトの名無しさん:05/03/14 04:21:02
別に好きで使いたいわけじゃないんだけど、上司や客が
WordやExcel形式で文書を送ってくるので仕方ないっすよ。
という俺はVMwareのクライアントOSとしてWindowsを動かす派。
自分で一から書く文書には、もちろんそんなの使わないけどネ。


519 :デフォルトの名無しさん:05/03/14 04:27:17
結論。
Unixerはいらん苦労が好き。

520 :デフォルトの名無しさん:05/03/14 04:39:38
>>518
今ならOpenOffice使うって手もあるけどね。
互換性はまだまだ低いけど。

521 :デフォルトの名無しさん:05/03/14 04:57:31
UNIXは昔からtelnet(というかteraterm)経由ですが何か?
それで問題起きたことないなあ。
つーかteratermなかったらUNIXなんてとっくに死滅してたね。
おまえらもっとteratermの作者に感謝すべきだと思いませんか?

つーかWindows上からteratermの快適さに比べたらX?ナニソレって感じ。
あんなのインスコしてもディスクの無駄。
どーせemacs動けばいいしね。

522 :デフォルトの名無しさん:05/03/14 04:58:27
おっと誤爆した。

523 :デフォルトの名無しさん:05/03/14 08:56:03
teratermを理由もなしに誉めるようじゃ……

524 :デフォルトの名無しさん:05/03/14 09:23:07
telnet上でファイルをやり取りできたらすべての作業がtelnetでやるんだけどできる?

525 :デフォルトの名無しさん:05/03/14 10:07:56
できるね。

526 :デフォルトの名無しさん:05/03/14 10:18:16
>>525
Unixユーザ特有の思考停止だな。

ターミナル経由でなければできないことは、
想定しないように脳内で排除フィルタが発動する。

527 :デフォルトの名無しさん:05/03/14 10:31:55
>>526
確かに面倒ではあるが、uuencodeして標準出力に出力、
telnet端末ソフトにログ機能などがあるだろうからそれを利用して端末側でuudecode。
自分の知識のなさを他人の思考停止に置き換えないように。

528 :527:05/03/14 10:34:08
訂正。
s/telnet端末ソフト/telnet端末ソフト側/
Windows標準のtelnetでも(windowsの機能を利用して)copy&pasteくらいできるだろ。

529 :デフォルトの名無しさん:05/03/14 11:04:48
関係ない話ししはよそでおねがいします

530 :デフォルトの名無しさん:05/03/14 11:10:49
結論から言うと、できないことだらけなのだが、

Unix信者には、「それはそもそも、XであってUnixではない。」
と嘯きつつ逃亡する退路が確保されているので、
Unix信者を追及するのは時間の無駄。

531 :デフォルトの名無しさん:05/03/14 11:16:01
時間の無駄だと言いながら、自分が最後に何か言わないと気がすまないのかね。

532 :デフォルトの名無しさん:05/03/14 14:35:54
ほりえもんもUNIXにビジネスチャンスは無いってさ

533 :デフォルトの名無しさん:05/03/14 14:47:26
おまえらこれを読んでから言え
http://www.amazon.co.jp/exec/obidos/ASIN/4756107834/

534 :デフォルトの名無しさん:05/03/14 14:53:55
UNIXの歴史を物語りみたいに仕立て上げたのって嫌い。文系厨みたい。
ただの実装史と割り切って書かれてる、スティーブンスの本は好き。

535 :デフォルトの名無しさん:05/03/14 15:29:54
がたりり?

536 :デフォルトの名無しさん:05/03/14 15:58:08
teraterm使ってる時点で既にUnix信者じゃないと思うけどね。
そういう俺は当然ktermですよ。mltermでも可。(w


537 :デフォルトの名無しさん:05/03/14 16:01:06
むつかしくてわらえない

538 :デフォルトの名無しさん:05/03/14 18:23:40
そもそもUNIXでプログラミングする事なんてあるの?
teratermみたいにUNIX使うためのWindowsプログラミングでもしてた方がいいんじゃない?

539 :デフォルトの名無しさん:05/03/14 18:28:10
時間の無駄だと言いながら、自分が最後に何か言わないと気がすまないのかね。

540 :デフォルトの名無しさん:05/03/14 19:03:06
>>538
そりゃあるよ。だいたい世の中の7割のWebサイトは
(Linuxを含む)UNIX系OSで動いているんだしさ。
ソフトウェア開発作業を必要とする大規模なサイト
になるほどUNIX系OSのシェアは上がるし。
googleだってamazonだって、Linuxとかそういう
UNIX系OSで動いてるのは知らない?


541 :デフォルトの名無しさん:05/03/14 19:39:43
てゆうか2chもUNIX系OSで動いているわけだが。

542 :デフォルトの名無しさん:05/03/14 19:45:32
てゆうか2chもWindows系OSで動かせばいいんだ。

543 :デフォルトの名無しさん:05/03/14 20:02:35
実際問題として、ライセンスにかかる価格の問題だけ
考えても Windows にすることはありえないけどね。
Windows XP だとクライアント数10までというライセンス
制限にひっかかるから、Windows 2003 Server が必要。
これで 1台あたり10万円×台数分の金がかかる。
これに対し、今みたいに FreeBSD や Linux を使ってれば
ライセンス台はタダ。
Windows にするだけで性能が向上して、台数が1/10で済む
とかいう効果があるのならともかく、そんなことも全然ない
わけだし。

544 :デフォルトの名無しさん:05/03/14 20:19:49
宗教的にUNIXだよもん

545 :デフォルトの名無しさん:05/03/14 21:34:14
Windowsのほうが得意なことはWindowsでやればいいものを、
わざわざkterm上でやって「難しいなあ」とか喜んでる奴は末期症状

546 :デフォルトの名無しさん:05/03/14 21:34:25
>>533
そのページを読めばいいんですね?

547 :デフォルトの名無しさん:05/03/14 21:39:29
別に難しいことないけど。
てゆうかWindowsで好みの設定にするのは俺には難しい。(w
UNIXだとcp .??*だけですむので俺には簡単。

もちろん、君にとっては逆だろう。いいじゃん好きずきなんだし。


548 :デフォルトの名無しさん:05/03/14 21:44:18
つーかWindowsはデフォルトで快適だからなあ。

549 :デフォルトの名無しさん:05/03/14 21:44:51
関係ない話しししはよそでおねがいします

550 :デフォルトの名無しさん:05/03/14 21:54:35
かたいこと言うな

551 :デフォルトの名無しさん:05/03/14 22:00:48
UNIXはいまだに基本がC言語なのがいかんと思う。
その上信頼性もクソもないshで書きなぐられたシステムなんか保守したくないだろ?

552 :デフォルトの名無しさん:05/03/14 22:03:31
GNUマンセー

553 :デフォルトの名無しさん:05/03/14 22:04:15
そういや某国はUNIXに進出しようとして失敗したな。

554 :デフォルトの名無しさん:05/03/14 22:33:54
>>551
シェルスクリプトは滅多にエラーにならないからエラー処理は
必要なくてとても信頼できるらしいです
うちのUNIX暦20年の課長(40)が言ってました
エラーになっても気付いてないだけじゃないんですか、と言おうと
しましたがやめておきました

555 :デフォルトの名無しさん:05/03/14 22:44:22
何について信頼できないとか言ってるのかよく
分からないんだが、シェルスクリプトだって
エラー処理ぐらいできるし、俺はやってるよ。

556 :デフォルトの名無しさん:05/03/14 22:51:19
たぶんそれぞれのエラー処理の意味がちがってるとおもう

557 :デフォルトの名無しさん:05/03/14 23:21:09
>>508
コンパイラですかインタプリタですか?
その自作言語の実行スタックはどういう構成でしょう?

schemeのインタプリタ、コンパイラは参考になると思います。

558 :デフォルトの名無しさん:05/03/15 00:05:48
すみません、質問させてください。
こういうプログラムを書いたのですが、
#include <iostream>

main()
{
cout << "hello";
}


gcc test.cppと書いてコンパイルすると、

/tmp/ccHDOsZp.o(.text+0x19): In function `main':
: undefined reference to `std::cout'
/tmp/ccHDOsZp.o(.text+0x1e): In function `main':
: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std
::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits
<char> >&, char const*)'
/tmp/ccHDOsZp.o(.text+0x4a): In function `__static_initialization_and_destructio
n_0(int, int)':
: undefined reference to `std::ios_base::Init::Init[in-charge]()'
/tmp/ccHDOsZp.o(.text+0x79): In function `__tcf_0':
: undefined reference to `std::ios_base::Init::~Init [in-charge]()'
/tmp/ccHDOsZp.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld はステータス 1 で終了しました

というエラーがでるのですが、C++のコンパイルの仕方が間違っているのでしょうか。



559 :デフォルトの名無しさん:05/03/15 00:08:52
>>558
いいえ

560 :デフォルトの名無しさん:05/03/15 00:12:01
g++もしくは-lstdc++

561 :558:05/03/15 00:12:54
ごめんなさい、std::を忘れてました。

>>559
対処法はあるのでしょうか・・・。よかったら教えてください。

562 :デフォルトの名無しさん:05/03/15 00:22:55
スレ違い。
gccスレで聞け。

563 :デフォルトの名無しさん:05/03/15 00:39:38
>>559は嘘。
コンパイルのしかたが間違っとる。

>>560が書いているように、gcc じゃなくて g++ か
あるいは c++ コマンドを指定する必要がある。


564 :デフォルトの名無しさん:05/03/15 01:11:53
ここは盥回しスレですか。

565 :デフォルトの名無しさん:05/03/15 09:44:25

盥・・・すごい字があるんだな、知らなかったヨ

566 :デフォルトの名無しさん:05/03/15 10:03:09
もう10

567 :デフォルトの名無しさん:05/03/15 14:47:14
>>558
ソースコードが間違ってます。

冒頭で、

using namespace std;

とするか、std::coutとするのが今ん流儀です。

それ以外は処理系依存の動作。


568 :デフォルトの名無しさん:05/03/15 15:07:05
C++の名前空間がうんこなのは仕様です。

569 :デフォルトの名無しさん:05/03/15 15:22:24
>>577
それは既に>>561で本人が気づいてる

570 :デフォルトの名無しさん:05/03/15 15:39:47
>>577
やーいばーか

571 :デフォルトの名無しさん:05/03/15 15:41:58
>>577
とんだ災難だとは思うがよろしく頼む。

572 :567:05/03/15 16:15:53
俺が>>577>>567と同じ内容を書いて大団円。


573 :デフォルトの名無しさん:05/03/15 20:56:32
>>572
お前おもしろいな

574 :デフォルトの名無しさん:05/03/16 01:00:29
574

575 :デフォルトの名無しさん:05/03/16 01:01:00
575

576 :デフォルトの名無しさん:05/03/16 01:01:41
576

577 :デフォルトの名無しさん:05/03/16 01:03:40


578 :デフォルトの名無しさん:05/03/16 01:08:34
>>577
ネタもないのに書くなYO!

579 :567:05/03/16 03:04:40
>>587
ソースコードが間違ってます。

冒頭で、

using namespace std;

とするか、std::coutとするのが今ん流儀です。

それ以外は処理系依存の動作。

って書こうと思っていたのにッ…orz


580 :デフォルトの名無しさん:05/03/16 03:08:27
もうこのくらいでやめとこうや。
な?

581 :デフォルトの名無しさん:05/03/16 04:20:47


582 :デフォルトの名無しさん:05/03/16 11:16:00
age

583 :デフォルトの名無しさん:05/03/17 16:47:56
gdb でデバッグするために
gcc で -g をつけてデバッグ情報つきの
オブジェクトファイルを作ってから
リンクしました.

ところができた実行ファイルを gdb しても
デバッグできません.
たとえば list しても

No symbol table is loaded. Use the "file" command.

とでます.

-g をつけるとたしかに .o ファイルはサイズが増えていますが,
最終的にリンクすると,できた実行ファイルは -g を
つけようとつけまいとなぜか変わらないんです.

なぜでしょうか?


584 :デフォルトの名無しさん:05/03/17 16:53:20
リンクするときに-gをつけてないとか。


585 :583:05/03/17 16:58:50
>>584
リンクするときに -g つけてもつけなくても結果は同じです

586 :デフォルトの名無しさん:05/03/17 17:10:29
リンクするときに-sをつけているとか。


587 :583:05/03/17 17:21:53
>>586
たしかにリンクに -s がついていて
これをはずすとデバッグできました
他人が書いたソースなもんで

man 見たところ -s に対する説明がありませんね
-S はありますが.
これはなんでしょうか?

588 :デフォルトの名無しさん:05/03/17 17:34:29
少しは上の方を見ろよ。

589 :429:05/03/17 20:46:23
>>587
> man 見たところ -s に対する説明がありませんね
% man ld
<snip>
-s
--strip-all
Omit all symbol information from the output file.

-S
--strip-debug
Omit debugger symbol information (but not all symbols) from the
output file.

<snip>
って, 書いてあるが...


590 :デフォルトの名無しさん:05/03/17 20:48:22
わかりにくいなあ
なあ!

591 :デフォルトの名無しさん:05/03/17 21:14:43
Solaris のコンパイラ (Forte, Sun ONE Stuido) のマニュアルには
ちゃんと書いてあるよ。

     -s   Removes all symbolic debugging information from the
          output object file. This option is passed to ld(1).
          This option cannot be specified with -g.

gcc 場合、マニュアルには確かにないねえ。
しかし gcc の info を見ると実は書いてある。
GNU 系の場合、これはありがち…
だから GNU は(ry


592 :デフォルトの名無しさん:05/03/17 21:19:38
>>591
> gcc 場合、マニュアルには確かにないねえ。
> GNU 系の場合、これはありがち…

おれは, 一時期, gcc だと obsolete になったのかと思って,
-Wl で ld に渡してたぞ.

だから GNU は(ry


593 :デフォルトの名無しさん:05/03/17 21:23:07
>>591-592

594 :デフォルトの名無しさん:05/03/17 22:16:12
1から100までの自然数を素因数に分解して出力しなさい

誰かC言語でプログラム書いてもらえませんか?

595 :デフォルトの名無しさん:05/03/17 22:18:19
>>594
俺様に命令するな!!!

596 :デフォルトの名無しさん:05/03/17 22:19:29
たのみますm(__)m

597 :デフォルトの名無しさん:05/03/17 22:25:36
>>594
最高速なアルゴリムを示そう。

int main()
{
fputs("2: 2\n"
"3: 3\n"
"4: 2, 2\n"
... 自分で埋めろ
, stdout);
return 0;
}




(1も素因数分解できるんだっけ?素因数ってもう忘れた)

598 :デフォルトの名無しさん:05/03/17 22:34:54
うちの gcc の man page には書いてあるんだが…

> -s Remove all symbol table and relocation information from the exe-
> cutable.

gcc-3.3.3 です。





599 :デフォルトの名無しさん:05/03/17 22:39:41
>>597
それって stdio のせいで遅くね?

600 :デフォルトの名無しさん:05/03/17 23:00:46
writeはエラー処理がめんどくさい。
全部書けなかった時とか、EINTRとか。


601 :デフォルトの名無しさん:05/03/17 23:09:51
#include <stdlib.h>
#include <stdio.h>
#define BUF_SIZE 256
int main(void)
{
int i;
char buf[BUF_SIZE];

for (i = 1; i <= 100; i++) {
snprintf(buf, BUF_SIZE, "factor %d", i);
system(buf);
}

return 0;
}


602 :デフォルトの名無しさん:05/03/17 23:14:47
>>598
うちはgcc-2.95.3ですた。
gcc-3 になって心を入れ換えた?

603 :デフォルトの名無しさん:05/03/18 00:16:34
>>600
fputs() でも一緒だと思うが...。

604 :デフォルトの名無しさん:05/03/18 01:20:27
うんにゃ。
少なくとも全部書けなかった場合については、
fputs() は、内部で再試行してくれます。

むか〜しの SVR4 が、これをやってくれなくて欝だった
ような覚えがあるが。


605 :デフォルトの名無しさん:05/03/18 02:55:44
>>604
初期のSVR4はsignalの振る舞いが、
defaultではBSD風じゃなくて、SVR3風だった。すぐに変ったけど。
だからsystem call中に、signalを受けると、エラーで失敗した。
ライブラリもsystem callに再入せず。(BSDセマンティクスだとする)


606 :じじー:05/03/18 04:17:10
>>605
> defaultではBSD風じゃなくて、SVR3風だった。すぐに変ったけど。
これは、今でもそうじゃない?
signal(3) はデフォルトでは SA_RESTART しない筈。

で、ここで書いた write(2) の再試行ってのはシステムコール
リスタートの話じゃないの。それならまだ許せる。
初期の SVR4 では、write(2) が第3引数よりも少ない正の値を
返した場合 (つまり partial write の場合)、残りを単に捨て
ちゃってたような気が… つまり完全にバグ。


607 :じじー:05/03/18 04:18:58
補足。
partial write の残りを捨ててたのは stdio ライブラリね。

608 :デフォルトの名無しさん:05/03/19 12:45:25
>> 592 さん
gcc の man には こう書いてありますが。

The information in this man page is an extract from the
full documentation of the GNU C compiler, and is limited
to the meaning of the options.

This man page is not kept up to date except when volun­
teers want to maintain it. If you find a discrepancy
between the man page and the software, please check the
Info file, which is the authoritative documentation.

609 :デフォルトの名無しさん:05/03/20 00:43:02
>>601
え  れ  が  ん  と(ニコリ

610 :デフォルトの名無しさん:05/03/20 02:47:45
標準C言語スレで聞いたら怒られたのでこちらで質問させてください。
mmapの動作に関する質問です。

//#include *は省略
#define SIZE 536870912
int main() {
void *map;
int fd = open("tmp_file", O_RDWR);
size_t size = (SIZE / getpagesize() + 1) * getpagesize();

map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_FIXED, fd, 0);
munmap(map, SIZE);

return 0;
}

というプログラムを動かすとバスエラーになってしまいます。
また、変数sizeを使わずにSIZEを使うとセグメントエラーになります。
mmapはファイルをメモリに全部読み込まずに必要な分だけキャッシュする
とmanに書いてあるように読めたのですが、間違いでしょうか。
環境はFreeBSD 5.3R, gcc 3.4.2です。メモリは512MBです。

611 :デフォルトの名無しさん:05/03/20 03:15:56
商用UNIXだったら分かるんだけどなー。

612 :デフォルトの名無しさん:05/03/20 03:45:13
>>610
mmapに渡してるsizeとmunmapに渡してるSIZEは同じなのか?
つーかちゃんとエラーチェックしろよ。
とりあえずstraceでもしてみれば?

613 :デフォルトの名無しさん:05/03/20 04:06:01
>>610
> #define SIZE 536870912

これって二進で100000000000000000000000000000、30bitじゃん。

幾らなんでもでかいだろ。
そのカーネルはユーザ空間どれくらいとれるの?
詳しいところ調べるの無理だったら、UNIX板のFreeBSD質問スレが良いかも。

614 :デフォルトの名無しさん:05/03/20 06:18:36
問題は>>613>>612が指摘している点もあるが、それ以前に、
第一引数が 0 なのに MAP_FIXED を指定している点もある。
0番値から連続で512MBも置き換えたら、現在実行している
プログラムからなにから全部置き換えになるから、そりゃ
コアダンプもするだろ。

それから、flags には、必ず MAP_PRIVATE か MAP_SHARED
のどらかか片方は指定するようにしろ。

あと、>>612 が言うように、システムコールがエラーで返って
ないか調べて、エラーだったら perror() なりerr() する習慣
をつけろ。基本中の基本。

これだけ短いプログラムに、なんでこんなにたくさんバグを
入れられるのかが謎だ。もっと人の書いたちゃんとしたプログラム
を読んで真似する習慣をつけるべき。


615 :デフォルトの名無しさん:05/03/20 06:57:39
どっかのクズサンプルをつかまされたのだろうきっと

616 :デフォルトの名無しさん:05/03/20 10:47:37
バグと言っていいかどうか微妙だなw

617 :610:05/03/20 11:46:33
>>612
あ、SIZEはtypoです。実際は両方ともsizeを指定してます。
あと、エラーチェックもperrorを実際は入れてます。
長くなると迷惑かと思って省略してしまいました、ごめんなさい。

>>613
その辺をうまくよきに計らってくれるのがmmapだと認識してたのですが・・・
間違いでしたか。

>>614
flagsにMAP_PRIVATEを入れたら行けました。
何か勘違いしてるみたいなのでもちっとじっくりmanを読んでみます。
ありがとうございました。

618 :デフォルトの名無しさん:05/03/20 12:35:43
仮想メモリ空間が足りないのに良きに計らうもクソも無いだろ

619 :デフォルトの名無しさん:05/03/20 13:37:38
>>613
>>610 ではないだが
> 30bitじゃん。
> 幾らなんでもでかいだろ。
なんで?
ふつうに,
mmap(0, 1024L*1024L*1024L, ...)
って, 使えてるが.
FreeBSD でも Solaris でも IRIX でも...
CPU アーキテクチャにもよるだろうけど, 32bit あれば
2G のユーザ空間確保できるのが普通じゃねぇの.


620 :デフォルトの名無しさん:05/03/20 13:42:05
>>619
> CPU アーキテクチャにもよるだろうけど, 32bit あれば
> 2G のユーザ空間確保できるのが普通じゃねぇの.

なことはない。

621 :デフォルトの名無しさん:05/03/20 13:47:05
>>620
> なことはない。
だから, なぜだか教えてほしいって言ってるじゃん.
backing store に指定容量以上ののファイルとか,
十分な量の swap 持ってきてもだめなの?


622 :デフォルトの名無しさん:05/03/20 13:55:44
よくあるケースは、
・32bitアドレス空間を、半分カーネル空間
・ユーザ空間の半分をテキスト領域
・残りをスタック領域とデータ領域
・sparseであることを仮定したmmap設計
などなど

x86はセグメントありますから、32bit全部データ領域は可能。

623 :デフォルトの名無しさん:05/03/20 14:02:45
UNIX userはやたらとalphabetで書きたがるね。

624 :デフォルトの名無しさん:05/03/20 14:04:35
それが UNIXer quality

625 :621:05/03/20 14:08:40
>>622
> よくあるケースは、
> ・32bitアドレス空間を、半分カーネル空間
mips あたりだと CPU が, そうゆう設計ですよね.

> ・ユーザ空間の半分をテキスト領域
こんなのって本当にある? バイナリの仕様次第か?
FreeBSD とか, 昔の SunOS-4 なんかだと
2^32/2 - text+maxdsiz+maxssiz が,
mmap で使用可能な空間ですよね?

> ・sparseであることを仮定したmmap設計
> などなど
64bit ならまだしも 32bit でやるかなぁ???

> x86はセグメントありますから、32bit全部データ領域は可能。
トロくなりませんか, OS が?


626 :621:05/03/20 14:11:15
> mmap で使用可能な空間ですよね?
ごめんなさい,
mmap(NULL, ..., /*MAP_FIXED ではない*/)
の話.


627 :デフォルトの名無しさん:05/03/20 15:58:01
そもそもmmap自体がポータブルじゃないので
良きに計らえとか言ってると火傷します

628 :デフォルトの名無しさん:05/03/20 16:38:42
Windows使うのが安全。

629 :デフォルトの名無しさん:05/03/20 17:10:23
同意。
わざわざ面倒なことする必要もない。

630 :デフォルトの名無しさん:05/03/20 17:13:25
FreeBSD/i386 を含め、386BSD から派生した OS は
i386 上だと、VM_MAXUSER_ADDRESS=3G くらいだから
512MB くらいなら mmap できることが多いよ。
KVM を広げるようにカーネルを config してたり、
他にいろいろ mmap してたりすると 別だし、
0番値から MAP_FIXED で mmap してたらまずいけど。
>>617 は MAP_PRIVATE を入れただけじゃなくて、
MAP_FIXED は取り除いたんじゃないかな。

m68k 用 NetBSD は、カーネルとユーザ空間に別の
仮想空間を使っているので、ユーザ空間だけで 4GB
使えたり。

ユーザー空間が 4GB/2=2GB って OS は多いけど、
text に 2GB/2=1GB も割り当てるなんてもったいない
ことしてる OS はないと思う。text は、実行ファイル
に含まれている分しか確保されない。むしろ、
ヒープと stack の中間に shared library 用の mmap
領域があったりすることが問題。

631 :デフォルトの名無しさん:05/03/20 17:13:47
>>627
mmap は、いまや POSIX.1:2004 に含まれているので、
そこそこポータブルですが、なにか?
Linux や *BSD など、POSIX.1:2004 をフル実装して
ない OS でも、mmap に関しては、ほぼ POSIX.1:2004
の仕様を満たしているよ。もっとも、定義されている
のは、各 OS の最大公約数程度の機能だけど。

632 :デフォルトの名無しさん:05/03/20 17:15:24
>>628
Windows のメモリマップドファイルって、ローカル
ファイルシステムはマップできるけど、リモートに
ある奴は駄目という不便な仕様だった記憶があるけど
今では直ったの?
UNIX の場合、当然そんな制限はありません。

633 :デフォルトの名無しさん:05/03/20 17:28:28
>>631
POSIXに含まれている=ポータブルではない。
「そこそこポータブル」って何だよ。

> mmap に関しては、ほぼ POSIX.1:2004 の仕様を満たしているよ。
本当に?A LinuxとB LinuxとC LinuxとD LinuxとFreeBSDで使えても
ポータブルとは言わないよ?

634 :デフォルトの名無しさん:05/03/20 17:32:10
わははは!
ペイントハウスで思いのままだ!

635 :デフォルトの名無しさん:05/03/20 17:37:57
>>633
> 本当に?A LinuxとB LinuxとC LinuxとD LinuxとFreeBSDで使えても
> ポータブルとは言わないよ?

で、君は使えない処理系の一つでも挙げればいいんだけど、自分は何も知らないけど煽ってるだけと言うことでいいの ?

636 :デフォルトの名無しさん:05/03/20 17:46:23
>>633
POSIX.1:2004に書いてある仕様なら、Solaris, IRIX, Tru64, HP-UX,
AIX は使ってないので知らんが。これで現在でもメンテされている
商用UNIXはほぼ全部。ちなみにこの程度の範囲の仕様なら、いにしえ
の SunOS4 でも通用する。
mmap はシステムコールなので、別に A Linux, B Linux なんて
言わなくても全部の Linux で同じ動作だし、あの範囲の仕様な
ら、実際に Linux でも通用する。FreeBSD に限らず、全ての
4.4BSD 派生 OS でも通用する。

最初にまともな実装が登場した SunOS4 の時代ならともかく、
あれから 15年も経った今でもポータブルでないっていうのは
時代遅れだと思う。

637 :636:05/03/20 17:48:22
編集してたら文章が欠けた…

> POSIX.1:2004に書いてある仕様なら、Solaris, IRIX, Tru64, HP-UX,
> AIX は使ってないので知らんが。

POSIX.1:2004に書いてある仕様なら、Solaris, IRIX, Tru64, HP-UX は
少なくとも満たしている。AIX は使ってないので知らんが。


638 :デフォルトの名無しさん:05/03/20 18:21:48
611の言ったとおり、やっぱり商用UNIXじゃないとな。

639 :デフォルトの名無しさん:05/03/20 18:32:28
>>638
だったらAIX以外ならOKよ。
AIXは、mmapは大丈夫かもしれんが、そもそもOSが変態だから
やめた方がいいかもしれん。

640 :デフォルトの名無しさん:05/03/20 18:34:24
> A LinuxとB LinuxとC LinuxとD Linux
ワロタ

641 :デフォルトの名無しさん:05/03/20 18:45:28
ここで質問すると、かならず無駄に互換性の話まで拡大するのな。
大抵の質問者が環境書かないからだと思うけど、
今回は環境かいても無駄だった。

642 :デフォルトの名無しさん:05/03/20 18:55:20
で、件のFreeBSDでは動くのかというと、正確な所は誰も知らないと言う・・

643 :デフォルトの名無しさん:05/03/20 18:58:03
POSIX.1:2004 の範囲ならFreeBSDでも動くよ?
元々の610のプログラムはバグバグなので、どのOSでも動かん。


644 :デフォルトの名無しさん:05/03/20 19:13:13
たぶんWindowsなら動くんだよ。

645 :デフォルトの名無しさん:05/03/21 02:25:57
特定のUNIXモドキ、しかも商用UNIXじゃないんだから
正確なところが分からなくても仕方ないと思う

646 :デフォルトの名無しさん:05/03/21 03:22:59
basename()が引数の指す先を変更することってあるんですか?

647 :デフォルトの名無しさん:2005/03/21 03:49:09(月)
>>610
どこの本やサンプルを見たらあんなコードになるのか興味深い
駆逐したいのでどこを参考にしたのか教えて欲しい。

648 :デフォルトの名無しさん:2005/03/21(月) 09:16:03
>>646
ttp://www.linux.or.jp/JM/html/LDP_man-pages/man3/basename.3.html
>path の内容を変更することがある。
だそうだ。

649 :デフォルトの名無しさん:2005/03/21(月) 09:43:42
ちゃんと嫁

650 :デフォルトの名無しさん:2005/03/21(月) 11:50:10
>>648
どちらかに決まってないんじゃ、呼び出した後free()すべきか
どうかどうやって決めればいいんでしょう?

651 :デフォルトの名無しさん:2005/03/21(月) 12:21:58
free() ?
自分が確保したものは自分で free() するのが基本。
strdup() みたいに、ライブラリ内で確保するやつもいるけど、そういうやつはマニュアルに書いてある。

652 :デフォルトの名無しさん:2005/03/21(月) 12:35:46
>>650
> dirname および basename は、静的に割り当てられたメモリへのポインタを
> 返すことがあり、これらの領域は後の関数呼び出しで上書きされるかもしれない。
…の部分に対する疑問?

それなら、

char * path = "foo/bar";
char * path_dup = strdup(path_dup);

char * path_dir = dirname(path_dup);

して、

free(path_dup);

すればいいだけだと思うが。

path_dup = dirname(path_dup);

みたいにすると、path_dup が strdup で確保したメモリじゃない可能性があるから、
free() するべきかどうか分からなくなるがね。


653 :デフォルトの名無しさん:2005/03/21(月) 13:07:56
>>651
gethostbyname(3)なんかは、「*で返すのはstatic dataだべ」って書いてある。

http://www.opengroup.org/onlinepubs/007908799/xns/endhostent.html
のAPPLICATION USAGE



654 :デフォルトの名無しさん:2005/03/21(月) 13:09:13
>>652
> char * path = "foo/bar";
> char * path_dup = strdup(path_dup);
>
> char * path_dir = dirname(path_dup);

ここでpath_dirの指す先がpath_dupの中かもしれないので

> free(path_dup);

ここでfree()してしまうとpath_dirが使えなくなりませんか?
何かすごくおかしいことを言っているのだろうか・・・

655 :デフォルトの名無しさん:2005/03/21(月) 13:12:18
>>654
おまえ読解力ゼロ

656 :デフォルトの名無しさん:2005/03/21(月) 13:26:42
>>654
付け加えると、path_dirは必要ならすぐに自前の領域にコピーしておくこと。
∵basename()を再度呼び出すと上書きされるから。

657 :デフォルトの名無しさん:2005/03/21(月) 14:02:44
>>652
> char * path_dup = strdup(path_dup);
< char * path_dup = strdup(dup);

通りすがりに、取り合えず訂正しておくわ


658 :デフォルトの名無しさん:2005/03/21(月) 14:03:51
>>657
m9(^Д^)プギャー

659 :デフォルトの名無しさん:2005/03/21(月) 14:05:50
>>657
< char * path_dup = strdup(path);

間違えたわ…ハズ

660 :デフォルトの名無しさん:2005/03/21(月) 18:31:51
>>652
「静的に割り当てられたメモリ」ってのはライブラリがstaticに持ってるバッファだと
言ってるように読めるんだが(バッファじゃないがerrnoみたいな)。
であるとすれば、free()するとおかしなことになるよな。
>>651が言ってるのはそういうことじゃないの?

661 :デフォルトの名無しさん:2005/03/21(月) 18:34:51
strdup1つでここまで引きずるとは、さすがUNIX

662 :デフォルトの名無しさん:2005/03/21(月) 18:42:03
>>660
だから basename の返り値を free しなきゃいいわけで、
basename に与えたポインタを free するのは問題ないだろ?

663 :デフォルトの名無しさん:2005/03/21(月) 18:58:49
ここは小学生の溜まり場かよ。

152 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)