05/01/15 02:19:15
【POSiX】
The Open Group Base Specifications Issue 6
IEEE Std 1003.1, 2004 Edition
URLﾘﾝｸ(www.opengroup.org)
【必読書】
Advanced Programming in the UNIX(R) Environment
URLﾘﾝｸ(www.amazon.com)
Unix Network Programming
Vol. 1: The Sockets Networking API, Third Edition
URLﾘﾝｸ(www.amazon.com)
UNIX Network Programming
Volume 2: Interprocess Communications (2nd Edition)
URLﾘﾝｸ(www.amazon.com)
3:名無し募集中。。。
05/01/15 02:20:16
man on www
URLﾘﾝｸ(www.linux.or.jp)
GNU Make 日本語リファレンス
URLﾘﾝｸ(www.ecoop.net)
Unix Programming Frequently Asked Questions 日本語訳
URLﾘﾝｸ(www.adl.nii.ac.jp)
4:名無し募集中。。。
05/01/15 02:20:51
関連スレ追加
ネットワークプログラミング相談室 Port12
ｽﾚﾘﾝｸ(tech板)
マルチスレッドプログラミング相談室 その３
ｽﾚﾘﾝｸ(tech板)
5:名無し募集中。。。
05/01/15 02:22:57
/◇
oノハヽo /◇◇
从*･ ｡.･) / ◇ ◇ センター試験がんばってね
/o y/ |`ｐ
し!|||ii|||Ｊ
|||||||||
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
問題なし。
前スレのｽﾚﾘﾝｸ(tech板:944番)
GNUは仕様だけじゃなくて、こうしましょうってガイドラインも出してるよ。
URLﾘﾝｸ(www.sra.co.jp)
ちなみに--に決めた時は、(+って候補もあった)
メーリングリストで投票していた。ストの仕切りで。
12:デフォルトの名無しさん
05/01/15 17:16:03
ﾓｰｦﾀがUNIX使う時代なのか
13:デフォルトの名無しさん
05/01/19 15:11:41
ここら辺もテンプレに入れとかない?
Advanced Programming in the UNIX(R) Environment 和訳
URLﾘﾝｸ(www.amazon.co.jp)
Unix Network Programming 和訳
URLﾘﾝｸ(www.amazon.co.jp)
URLﾘﾝｸ(www.amazon.co.jp)
UNIX プログラミング環境
URLﾘﾝｸ(www.amazon.co.jp)
14:デフォルトの名無しさん
05/01/19 15:16:21
あと俺、これも好きなんだけどねえ。
UNIX システムコールプログラミング
URLﾘﾝｸ(www.amazon.co.jp)
古いから、今のとの相違点をマニュアルと比較しながらでないと
使えないんだけど。逆にそれができる香具師には、単純だった頃の
UNIX の姿から学習できるから、かえって入門に向いてる気がする
んだが。
15:デフォルトの名無しさん
05/01/19 15:30:05
ちなみに↑は去年新版が出たんだが(20年ぶりくらい?)
和訳の予定ってないんかなあ。
最近、原著で読み通すほどの暇と気力がない。orz
URLﾘﾝｸ(www.amazon.com)
16:デフォルトの名無しさん
05/01/19 21:06:44
ここ2,3年の間にUNIXのプログラミング題材にした書籍が
アメリカで何冊か出てるよね。
17:デフォルトの名無しさん
05/01/19 23:27:33
Linuxのみだけど、↓これもなかなかいい内容の本だったよ。
古典的なところをちょっと外れたのも盛り込んでいて。
新人さん向けの本を捜しての斜め読みだけどもね…
Linuxプログラミング―例題で学ぶUNIXプログラミング環境のすべて
URLﾘﾝｸ(www.amazon.co.jp)
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のドキュメントに載っている
(URLﾘﾝｸ(www.opengroup.org))
<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
Ｗ＝リチャード（故）の「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
もうしわけないです、どこの質問すればいいですか？
誘導願いしますｗ
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
元９５です。偽者発生してもうきけるふんいきじゃないですね。残念です。
man 英語だったんでうーんって感じだったんですけど
あとSHELLからコマンドで毎日定時に送るようにしたかったんですけど、
まあがんばって訳してみます。
結果あらしてすみませんｗ
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 ありが㌧ 調べてみまつ。
>>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流の設定ファイルの置き場のお作法はこうじゃ
URLﾘﾝｸ(www.sra.co.jp)
129:デフォルトの名無しさん
05/02/17 18:17:03
>>128
そんなに悪いものかな?
まあ、郷に入りては郷に従え、と。
130:デフォルトの名無しさん
05/02/17 18:33:07
そもそも１つのファイルは複数の場所に存在できるんだから、
「自身が置かれているディレクトリ」なんて特定できるわけがない。
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 守ってね。管理面倒になるから。
URLﾘﾝｸ(www.pathname.com)
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の欠陥の１つだよ
こいつ（>>138）こんなリンク張れば騙される奴がいるとでも思ってんだろうなｗ
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のヤバさが１つわかりましたね
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
まあ、ファイルがバラけるのを良しとしない人は多い気がする。
２ｃｈでそういう便利関数集めた汎用ライブラリ作らない？
主要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は専用マシンと一緒に買わせる抱き合わせ商法。
抱き合わせ商法が許されたのは２０年以上前の秋葉原ぐらいだが、
現在も生き残ってるベンダーは、今でもその商法で売っている。
まさに２０年前の思想。
当然ソフトウェアの保護にはものすごく疎い。
ぶっちゃげ自分のシステム以外の事はどうでもよく、問題を認識してすらいない。
ベンダーはマシンを買ってもらえれば元が取れるからわれ関せず。
不正ユーザーにとっては、動いているソフトは勝手にクラックしてください
と言わんばかりの無法地帯。
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。 一番、ｵﾓｼﾛｶﾀｰﾖ。
ﾐﾝﾅ、ｱﾘｶﾞ㌧
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のファイルシステムでは、
１このファイルに対してファイル名(パス)がいくつでもつけられるから、
実行ファイルのある場所は？っていう質問には無理があるのよ。
実行ファイルといっしょに置いた設定ファイルを使おうとした場合、
最悪でも今の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
URLﾘﾝｸ(homepage1.nifty.com)
215:デフォルトの名無しさん
05/02/18 14:01:26
>>209
そうなんだけどそれがわからん奴が多過ぎ。ム板にあるせいか
自分の無知からくる妄想的な優越感にかこつけて
昏いコンプレックスを晴らそうとする厨が絶えないね。
まあ元から知性に欠けるので馬脚を現しまくりなんだけど。
>>212
まとめは>>202-203だろ。
別にラッパースクリプトでしなければならない必然性はないけどね。
単にそれが手間がかからないからそうすることが多いってだけで。
あえて言えば、Cのコード書くより早いのと、動作を知るのに
特にドキュメントを探し回らなくても読めばわかるってのが利点だね。
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も読め。
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しかなさそうに見えるけど。