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

UNIXプログラミング質 ..

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はバカチョンだしね。

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

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

次ページ