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

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

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

1 :デフォルトの名無しさん:03/06/09 07:21
UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド

前スレ:
UNIXプログラミング質問すれ
http://pc2.2ch.net/test/read.cgi/tech/992057422/

>>2 関連スレ

2 :デフォルトの名無しさん:03/06/09 07:21
関連スレ
Cygwin使っている人いますか? その8
http://pc.2ch.net/test/read.cgi/unix/1047489645/
Cygwin使っている人いますか? Part2
http://pc2.2ch.net/test/read.cgi/win/1052361218/

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

3 :デフォルトの名無しさん:03/06/09 07:22
3

4 :デフォルトの名無しさん:03/06/09 07:30
http://www.twc-wrestle.com/inoki.html

5 :デフォルトの名無しさん:03/06/09 11:38
乙。
無理に埋立することもなかったんじゃないかとは思うけどな。

6 :デフォルトの名無しさん:03/06/11 23:42
初歩的な質問で恐縮ですが質問させてください。m(_ _)m
gccでのCのプログラムを書いてるのですが、ログインユーザのホームディレクトリと、
実行ファイルのあるディレクトリパスを取得したい場合どのようにすればよいのでしょうか?
# チルダをつけるとホームのファイルを開けるのかと思ったのですが駄目でした…。


7 :デフォルトの名無しさん:03/06/12 00:00
環境変数HOMEから取得

8 :6:03/06/12 00:15
>>7さん
環境変数HOMEで取得できました。
実行ファイルの方は自分で調べようと思います。
レスありがとうございました。m(_ _)m

9 :デフォルトの名無しさん:03/06/12 00:51
>>8
> 実行ファイルの方は自分で調べようと思います。

1. argv[0]がfull pathかどうか?
  yes → それ
2. argv[0]が'/'入りでかつ相対パスか?
  yes → getcwd と それ を連結
3. $PATHの中を順番に、argv[0]を探す。
found → それ

確か、GNU dldはこんなことをやっていた。(そこからcodeを盗んでもいい)

10 :デフォルトの名無しさん:03/06/12 14:49
>>9
Unix系じゃ100%確実な取得方法はないね。

execve(2)の引数で簡単に嘘付けるし、
/proc見たとしてもマウントされてない可能性もある。
chroot(2)なんかした日にゃ、そもそもパスが無意味。

そんなの気にする必要はまったくないがw

11 :デフォルトの名無しさん:03/06/13 08:18
FAQ的には、「気ニスルナ!」が正解。
どっかのFAQにそんな記述があった。


12 :ヽ(´ー`)ノ:03/06/13 11:05
てーか、フルパスが知りたい時ってどんな時?


13 :デフォルトの名無しさん:03/06/13 20:15
Windowsと勘違いした香具師がプログラミングしてるとき、かな。

14 :デフォルトの名無しさん:03/06/19 19:17
C++のライブラリをdlopenから使いたいんですが、
クラス関数の呼び出し規約とか載ってるサイトないですか?

15 :デフォルトの名無しさん:03/06/20 00:10
>>6
getpwnam(3)


16 :デフォルトの名無しさん:03/06/20 00:20
C++のsource codeで、
extern "C" T1 F(T2 arg1) {
    // C++を呼び出すんじゃー
};
とwrapper関数を定義して、Cのprogramから使う。

Cのsource codeで、
    extern "C++" {
        // C++を呼び出すんじゃー
    }
とlinkageを指定して呼び出す。

いじょ

あ、それスレ違いな。

17 :デフォルトの名無しさん:03/06/20 16:44
>>16
> Cのsource codeで、
>     extern "C++" {
>         // C++を呼び出すんじゃー
>     }

できんだろ。

18 :デフォルトの名無しさん:03/06/20 23:14
extern "Lisp" {
     // Lispを呼び出すんじゃー
}


19 :14:03/06/21 17:28
C言語での方法は知ってます。


20 :デフォルトの名無しさん:03/06/21 17:32
extern "Java" {
     // Javaを呼び出すんじゃー
}
extern "C#" {
     // C#を呼び出すんじゃー
}

なんか最強だなおい

21 :デフォルトの名無しさん:03/06/22 01:25
>>12
SIGHUP を受けたときに再起動して、設定ファイルを読み直すとき。

22 :デフォルトの名無しさん:03/06/22 11:06
>>21
execve("自分のパス", ...);とかやるわけ?

23 :デフォルトの名無しさん:03/06/23 01:56
UNIXでは設定ファイルのパスは通常ハードコードだよ
必要ならconfigureのオプションで変更。
そもそも設定ファイルはバイナリとはかけ離れた位置にあるのが
普通なのに自分の位置なんかわかって役に立つのか?

24 :デフォルトの名無しさん:03/06/23 05:12
>>21
それもやっぱり絶対パスでハードコード推奨だろうな。
とくにsuidなんかだと、ファイル名のような外部から与えられるものは危なすぎる。

25 :ヽ(´ー`)ノ:03/06/23 09:14
>>21
そういう使い方は目からウロコだった。アリガトン。


26 :デフォルトの名無しさん:03/06/23 10:05
>>23
あんた何言ってんの?


27 :デフォルトの名無しさん:03/06/23 17:16
curses ライブラリについて質問なんですが、標準入力をパイプでつなぐと
getch がパイプから入力をとってきてしまいます。
しかし less は標準入力からデータをもらいつつ、かつキーボードからも入力を
受け付けますよね。こういうことは curses ではできないのでしょうか。

28 :デフォルトの名無しさん:03/06/23 21:04
>>27
まずlessってパイプとキー入力を同時に受けつけてるの?
main()
{
 int buf;
 while((buf=fgetc(stdin))!=EOF){
  fputc(buf,stdout);
 }
}

これだけでも、パイプからの入力中にいくらキーボード叩いても、
ごちゃまぜにはならんが。

29 :デフォルトの名無しさん:03/06/23 21:12
>>28
moreの逆戻りが出来る版ですよ。

30 :27:03/06/23 21:22
>>28
パイプとキー入力を同時に受けつけてるか分かりませんが(tail -f file | less
とかやるとちょっとおかしくなる)、パイプつないでキー入力を受けつける方法が
分からないんです。

31 :デフォルトの名無しさん:03/06/23 21:25
dupでうまくできないかな?

32 :デフォルトの名無しさん:03/06/23 21:35
less は別途 /dev/tty を開いてるんじゃないの?

33 :デフォルトの名無しさん:03/06/23 22:56
ごちゃごちゃ言う前にソース見るのが早い気がした。

34 :デフォルトの名無しさん:03/06/23 23:02
つーか、/dev/ttyじゃなくて、stdinを入力対象とするcurses library,
そんなもん存在するの? 一体なぜ???

>>28
あんた、何言ってんの?

35 :27:03/06/23 23:18
>>34
よく分かりませんが getch って stdin 読むものじゃないんですかね。
echo j | ./a.out
で ./a.out して j 押したのと同じ状態になります。その後キー入力効きませんが。

36 :デフォルトの名無しさん:03/06/23 23:40
>>35
ごちゃごちゃ言わんとソース読め。嫌ならUNIXなんぞさっさと止めてしまえ。

37 :デフォルトの名無しさん:03/06/26 13:21
>>35
getch()なんて関数どこにある?

38 :デフォルトの名無しさん:03/06/26 17:15
>>37
cursesて知ってる?

lessのソース眺めたけど、やっぱ/dev/ttyを開いてたね。

39 :デフォルトの名無しさん:03/06/28 00:44
陰湿

40 :デフォルトの名無しさん:03/06/28 02:49
ファイル入出力でやっている
カーネルバッファリングのバッファサイズを0にするために,
ioctl関数をどのように使用すればいいですか?

41 :デフォルトの名無しさん:03/06/28 03:08
OSによる。環境書けよ。

つうかioctlでread/writeのバッファサイズの変更なんてできるのか?
そもそもファイルシステムに依存するぞ。

もしstdioのことを言ってるならバッファリングはカーネルでなく
ライブラリがやってる。man setbuf すれ

42 :デフォルトの名無しさん:03/06/28 03:25
>>41
すいません.

OS: Redhat 9.0

ユーザバッファリングではなく
カーネルバッファリングです.

ioctlでできるそうなんですが
以下のサイトでできると書いてあるんですが
やりかたがわからないんです.
ttp://search.luky.org/linux-users.6/msg07811.html

43 :デフォルトの名無しさん:03/06/28 03:37
fflushする代わりにって言ってるんだからstdioのことで、
setbufで必要十分だろ。ioctlなんて使わないよ。
何がしたいの? なぜioctlにこだわるの?

44 :デフォルトの名無しさん:03/06/28 03:53
>>42
まずカーネルバッファリングとか不明確な単語は使わないほうが良い。
それからファイル入出力じゃなくて端末出力でしょ。
さらにioctlはドライバ毎に用意されるものでドライバI/Fを調べるのが普通。

で、TTYドライバに対する設定はlinuxの場合は以下のURIでできるようだが
バッファサイズ変更の機能は見つからない。
http://www.linux.or.jp/JM/html/LDP_man-pages/man3/termios.3.html
元ネタが嘘?

45 :デフォルトの名無しさん:03/06/28 08:50
>>26
日本語が読めないんですか?

46 :デフォルトの名無しさん:03/06/28 10:27
>>44
元ネタはinをrawにすれって事じゃないのか?


47 :デフォルトの名無しさん:03/06/28 11:02
>>45
>>21,22の意味が分からないの?

48 :40:03/06/28 12:50
>>43 43
うちの師匠がioctlでできるはずだから
やっておけって言われたものですから.

目的はwrite/readは
カーネルでバッファ(ブロック?)に溜めて,
溜まったら出力しますよね?
そのバッファサイズを0にすれば使用するマシンの
ファイル入出力に掛かる正確な時間が計れるのではと言われました.
わかりにくい文ですいません.

49 :デフォルトの名無しさん:03/06/28 14:03
O_SYNCとかそういう話か?

50 :デフォルトの名無しさん:03/06/28 14:27
writeした後にfsyncでもすれば?

51 :40:03/06/28 14:52
>>49 50
それも考慮しましたが,
師匠がいってるのでioctlにこだわりを.
すいません.

52 :デフォルトの名無しさん:03/06/28 14:54
師匠にいわれたら死ねるのか?

53 :40:03/06/28 15:57
>>52
それはいいすぎでしょう.

54 :デフォルトの名無しさん:03/06/28 15:58
>>51
と、言うか普通に師匠に聞けばいい話だと思われ。

55 :デフォルトの名無しさん:03/06/28 16:43
>>48
言ってること滅茶苦茶だな。
ファイルIOなら >>49 がお望みのものじゃないの?
ただし、それで計った値に意味があるかは別だけどな。
師匠も師匠なら弟子も弟子・・・。

56 :デフォルトの名無しさん:03/06/28 19:38
>>48
> そのバッファサイズを0にすれば使用するマシンの
> ファイル入出力に掛かる正確な時間が計れるのではと言われました.

fsyncにしてもO_SYNCにしても、
いつもの入出力のやり方と違うわけだが、そんな調査でもいいのか?


57 :40:03/06/29 01:41
マシンごとにバッファのサイズが違うために
マシン毎の性能を性格に計測するためには
バッファサイズを同じにしなければならないらしいです.


58 :デフォルトの名無しさん:03/06/29 02:01
C++のライブラリをdlopenから使いたいんですが、
クラス関数の呼び出し規約とか載ってるサイトないですか?
知りたいのはC++製のsoライブラリへのアクセス方法で、
Cの場合については判ってます。


59 :デフォルトの名無しさん:03/06/29 02:03
シングルユーザーモードにして、
巨大ファイルコピー;syncを数回実行して平均を出すべきだろうね。
# cp TESTDATA /mnt/target;sync;sync
実使用とかけ離れたドライブ単体の性能を測るのであれば。

実使用状態ではHDDとプログラムはできる限り並列に動作させようとして
カーネルががんばっちまう結果、
書き込み終了より先にプログラムが終了しちまう。

60 :デフォルトの名無しさん:03/06/29 02:21
>>58
シンボルの変換方法、仮想関数テーブル、例外処理、static initializerの扱い
などがコンパイラベンダ毎にマチマチなので、コンパイラとバージョン限定
しないと話にならんと思うよ。

61 :デフォルトの名無しさん:03/06/29 03:04
指定したディレクトリのファイルを列挙するプログラムを教えて?

※いや、サクっとできそうで本当にできなかった。カレントDirなら
列挙できたのだけど、その下がなぜか、かからない・・・libc5使ってるのだけどね。

おしえてちょ。



62 :デフォルトの名無しさん:03/06/29 04:02
> libc5使ってるのだけどね
(´-`).。oO(…価値のある情報だろうか?)

63 :デフォルトの名無しさん:03/06/29 08:16
>>61
再帰。スタックあふれに注意。

64 :デフォルトの名無しさん:03/06/29 08:40
>>57
マシンごとに違うのは、バッファだけじゃないのに、
バッファだけ同じにするのは意味がわからんな。
実メモリが多いマシンには不利な条件だ。
# I/O cacheへのmemory割り当てが可変のOSに限るが。

>>58
extern "C" {
宣言;
}
した、Cのwrapper関数を定義。

>>61
FILE *f = popen("find . -print");
Cで完結したければftw(3)を。
opendir/readdir/closedir(3)使って駄目なのは、頑張れとしか(ry


65 :デフォルトの名無しさん:03/06/29 12:07
>>64
popenの引数はひとつなの?

66 :デフォルトの名無しさん:03/06/29 12:11
違うよ、御免よ。"r"を付け足してねん。

67 :デフォルトの名無しさん:03/06/29 14:02
現在、無線LANでクライアントPCから数ミリsecでリアルタイムにデータ受信をしていますが、
サーバPCからキー入力をして無線LANを使ってクライアントPCに文字信号を送信したいと思っています。
どのようにしたらリアルタイムキー入力ができるのか教えてください。
ちなみにsysytem("stty raw");関数を使ったらキー入力待ち状態になりリアルタイムデータ受信が止まってしまいました。
OSはlinuxです。よろしく御願い致します。

68 :デフォルトの名無しさん:03/06/29 14:19
>>67
RealtimeのOSに変えたらどうだ?


69 :デフォルトの名無しさん:03/06/29 14:36
>>67
・O_NONBLOCKでopenする
・poll/selectでデータがある事を確認する
・スレッドで入力待ち

>>68
単純に変えても同じ事になるぞ。


70 :デフォルトの名無しさん:03/06/29 14:52
>>69
数ミリsecでリアルタイム処理できないOSだと指摘してるだけでしょ。
受信処理だけでたまたまリアルタイム処理できていたとしても
送信処理が入ることでダメになる可能性もある。

71 :デフォルトの名無しさん:03/06/29 14:58
リダイレクトを取得する方法は?
たとえば ls とうって、その結果の標準出力を受け取る方法。

自分は今のところ、泥臭い方法で
system( "ls > ./tmp" ); みたいにテンポラリに吐き出して
それをあとから参照する方法使ってるけど、なんだかねぇーという
感じで

72 :デフォルトの名無しさん:03/06/29 15:01
>>71
>>64-65

73 :デフォルトの名無しさん:03/06/29 15:09
>>68=>>70
恥ずかしいやつ

74 :デフォルトの名無しさん:03/06/29 18:03
>>47
>>23,24が読めないんですね。

75 :デフォルトの名無しさん:03/06/29 18:06
>>71
>>64-65

をー!そうやってやるのか!サンクス

76 :デフォルトの名無しさん:03/06/29 18:38
ソフトリアルタイムとハードリアルタイムの違いが分からないんですな。

77 :デフォルトの名無しさん:03/06/30 15:09
>>42
結局URLにあるioctlのやりかたって
どうやるの??

78 :デフォルトの名無しさん:03/06/30 15:51
>>77
脳内

79 :age:03/06/30 17:08
質問です。
Linux gcc で実行ファイル(自分自身)があるディレクトリを
知りたいんですが、どうやるんでしょうか。

80 :デフォルトの名無しさん:03/06/30 18:14
>>79 無理。

81 :デフォルトの名無しさん:03/06/30 18:24
>>79
procfsが有効なら、/proc/self/exeをreadlink(2)してdirname(3)。

82 :77:03/06/30 21:25
>>44
おそらく端末i/oじゃなくて
ファイルi/oだから違うでしょ
システムコールに関する本を読むと
カーネルバッファリングって記述はあって
やりたいことはわかるけど、
どうやるかは不明。

83 :79:03/06/30 22:04
>>81
大変遅くなりました。
あっしも >>80 さんと同じに考えてましたが
教えて頂いた方法でできました。
ありがとうございました。


84 :デフォルトの名無しさん:03/07/01 09:45
こんなコードがあったもので、質問です。

fd = open("/dev/hdc1", O_RDWR);

fdatasync(fd);

これで/dev/hdc1の全てのキャッシュされたファイルについて同期がとれますか?


85 :デフォルトの名無しさん:03/07/01 10:02
PerlかRubyでシェルもどきを作りたいのですが、
いい例、解説サイトはありますか?

86 :デフォルトの名無しさん:03/07/01 10:52
Perlの例は知らないが、Rubyだとirbshってのがある。

87 :デフォルトの名無しさん:03/07/01 11:07
PerlやRubyをなめるな。もどきじゃなくて本物がつくれる。

88 :デフォルトの名無しさん:03/07/01 11:11
>>84
ファイルつーかファイルの中身な。ファイルの属性の同期はとれない。
実装されてないシステムもある。(関数は呼び出せるのに:-)

89 :84:03/07/01 12:59
>>88 サンクスです。
動くかどうか気いつけて使え、ということですな。
つーことは、一般的には使わんほうがええですな。

90 :85:03/07/01 20:59
自作のツリー状データ構造上でcdとかlsをしたいのですが
ファイル名に空白が入っていた時の対処とかいろいろ行き詰まってしまって・・・

91 :デフォルトの名無しさん:03/07/01 21:01
'や"で囲んで入力させればいいと思うけど

92 :デフォルトの名無しさん:03/07/01 22:04
ふつう、カーネルにバッファリングされたくなかったら raw デバイスを
使うでしょ。これなら、どの UNIX でも通用する。
linux も kernel 2.4 以降なら、raw コマンドを使って raw デバイスを
割り当てられるよ。
もっとも、パーティションを直に読み書きすることになるから、書き込み
書き込みに関しては、未使用のパーティションがないとテストできないが。

あと、xfs なら O_DIRECT も使えるかもしれん。


93 :84:03/07/02 09:21
>>92
私に対するレスですよね?
バッファリングされたくないというのではなくて、
任意時点で同期をとる意図をもった他人のコードにああいう記述があったので、
質問してみたわけです。

とはいえ、>>92のレスは私にとっての示唆に富んでいました。
ありがとうございます。

94 :質問age:03/07/04 01:34
質問です。
Linux g++ で pthread を使ってみたいんですが、
thread の実装(C++化?)ってどうやってます?
すでにあったらメンゴです。

95 :デフォルトの名無しさん:03/07/04 01:52
腐るほどあるんじゃない?

96 :デフォルトの名無しさん:03/07/04 02:47
>>94
#include <boost/thread.hpp>

97 :94:03/07/04 09:49
>>96
boost ライブラリですか。
検索してもあまり見つからないですね。
RedHat 用 rpmがあったんで、ちょっと試してみます。
ありがとうございます。

98 :デフォルトの名無しさん:03/07/04 18:03
Linuxのシステムコールって、int呼び出しだったのか!
ちょっと昔のMSDOSを思い出して感動した!

99 :デフォルトの名無しさん:03/07/04 18:54
ユーザモードからカーネルモードにする手段は限られてるから、
まぁ大抵intになると思うが。

#BSD/OSはillegal instruction使ってたかも。

100 :デフォルトの名無しさん:03/07/04 20:11
>>98>>99
WindowsもFreeBSDもINT呼び出しだよ。引数の扱いがLinuxと違うけど。

Windows NT/2000/XPがINT 2EHで、FreeBSDがLinuxと同じINT 80H。

SolarisやUnixwareはコールゲート。

101 :デフォルトの名無しさん:03/07/04 21:02
はつみみです

102 :デフォルトの名無しさん:03/07/04 21:09
>>100
ではINT 2EHでどのようにして呼び出しているのかコードを書いてください(w

103 :デフォルトの名無しさん:03/07/04 21:44
お願いですからintと書かないで下さい。なんのこっちゃと思ったよ・・・。

やはり基本はINT86x()でつか?

104 :デフォルトの名無しさん:03/07/05 00:09
>>102
http://www.sysinternals.com/ntw2k/info/ntdll.shtml
http://www.securityfocus.com/library/1584
http://www.securityfocus.com/data/library/ntkern.doc (Word形式)
あたりを参照。

105 :デフォルトの名無しさん:03/07/05 00:35
>>104
http://www.securityfocus.com/data/library/ntkern.doc (Word形式)
これ、Word形式じゃないじゃん。

補足しておくと、Native APIというのがUNIXのシステムコールに相当するもの。
Native API(ntdll.dll)を使ったプログラムの例は
http://www.sysinternals.com/ntw2k/info/native.shtml

106 :デフォルトの名無しさん:03/07/05 08:37
INT と int じゃ激しく違うと思うんだがどうか。

107 :デフォルトの名無しさん:03/07/05 08:47
>>106
INTRRUPTとintegerだからなぁ

108 :デフォルトの名無しさん:03/07/05 08:49
INTRRUPTってしらねーなあ。INTERRUPTなら知っているが。

109 :デフォルトの名無しさん:03/07/05 12:25
揚げ足鳥揚げ

110 :デフォルトの名無しさん:03/07/05 13:11
腹減った

111 :デフォルトの名無しさん:03/07/06 12:39
>>100
Solarisで、kernel にトラップするのは ta 命令。
Solaris for x86 は知らん。


112 :デフォルトの名無しさん:03/07/06 14:08
>>98>>100
Linuxは、標準では、引数を直接レジスタに入れてINT 80Hを呼び出す形で
システムコールを実装しているけど、Linuxには実行ドメインという概念と
personalityというシステムコールがあって、プロセス単位でソフトウェア
割り込みやコールゲートの扱いを変更できる。

BSDのLinuxエミュレーション機能の方が有名だし、最近はほとんど使われて
いないけど、LinuxにはiBCSというSolarisやUnixwareなどのバイナリを実行
する機能があって、それの実現のために使われている。

iBCSのサイトや
http://www.purplet.demon.co.uk/linux/ibcs/
Linuxのソースの
linux/kernel/exec_domain.c
linux/include/linux/personality.h
あたりを見ると面白いかも。

113 :デフォルトの名無しさん:03/07/08 03:25
初歩的な質問で恥ずかしいのですが、
UNIXでファイルの削除をする方法(プログラム)がわかりません。

ご教授おねがいします。


114 :デフォルトの名無しさん:03/07/08 03:40
>>113
man unlink

115 :デフォルトの名無しさん:03/07/08 04:24
>>114
ありがとうございます。
あまりに盲目な自分がちょっと悔しいくらいです。

116 :デフォルトの名無しさん:03/07/08 05:15
>>115
ちなみに、removeならCの標準関数だからUNIXに限らず使える。

117 :デフォルトの名無しさん:03/07/09 00:31
>>112

iBCS/Solaris/UnixWare(SVR4)互換機能も、実行ドメイン/personality に
相当する機構も、どちらも *BSD にだってあるだろ。
FreeBSD だと sysentvec (<sys/sysent.h>)、
NetBSD だと execsw (<sys/exec.h>) だな。

NetBSDもint 0x80なわけだが、実はFreeBSD/NetBSDが386BSDから別れた頃は、
コールゲートの方を使っていた。トラップゲートに切り替えた理由は、少な
くとも当時のマシンでは、コールゲートよりもトラップゲートの方が速かっ
たかららしい。これはFreeBSDでは1996年頃、NetBSDでは1994年頃の話。
当時からのcvsツリーが公開されているってのは便利だのう。


118 :デフォルトの名無しさん:03/07/09 01:02
Pen4からはsyscallですかねぇ

119 :デフォルトの名無しさん:03/07/10 04:15
最近C#をはじめたのですが、GDI+がWindowsXPでは遅いそうです。
LinuxではC#とGDI+はどのくらいの早さで動きますか?

120 :デフォルトの名無しさん:03/07/10 09:42
>>119
LinuxでC#とGDI+がサポートされているのかどうかを聞きたい。
てゆーか、動いているところを見てみたい。


121 :デフォルトの名無しさん:03/07/10 09:44
Lindows?

122 :デフォルトの名無しさん:03/07/10 11:32
GDI+はよくしらんが、LinuxでC#はできてると思うが。

123 :デフォルトの名無しさん:03/07/10 18:52
LinuxのカーネルがC#でかかれるのはいつぐらいになるだろう。
三年後ぐらい?

124 :デフォルトの名無しさん:03/07/10 19:00
Linuxのカーネルがjavaでかかれるのはいつぐらいになるだろう。

125 :デフォルトの名無しさん:03/07/11 02:25
で、そのVMを動かすために別なOSが必要になって…
それをC# or javaで実装して…
以下繰り返しとか。

そういえば、Linuxカーネルをjavaで実装するのはどこかで見たような記憶があるなあ。


126 :デフォルトの名無しさん:03/07/11 03:02
javaはjava CHIPが普及すれば可能と思ってるんだけどね

127 :デフォルトの名無しさん:03/07/11 05:54
でも、もはや利権の喰い物にしか見えないなぁ

128 :デフォルトの名無しさん:03/07/11 21:48
>>126
Java chip の OS って Java じゃないよ。(あたりまえだけど。)
まさか、Java chip って Java しか動かないと思ってるのか ?

129 :126:03/07/11 22:42
>>128
よう知らんけど、Linuxカーネルをjavaで実装って、それ以外にどうやってやんの?
Java chipってVMそのものだと思ったんだが・・・。

130 :デフォルトの名無しさん:03/07/11 22:45
>>128
>まさか、Java chip って Java しか動かないと思ってるのか ?

純粋なものだとそうだろうな。
バイトコード解釈できないCPUはJavaChipじゃないわけで。

なんか組込用VMと勘違いしてないか?


131 :デフォルトの名無しさん:03/07/11 23:12
>>129
VM 書いて、その上で動くカーネルソースを書けばいいだけだと思うけど。
もちろんメモリー管理とか、割り込み処理なんかは Java じゃ書けないけどね。
Unix だって、100% C ではない。
それとおんなじで、90% (値はてきとー) Java のカーネルとかなるんだろうな。

>>130
> バイトコード解釈できないCPUはJavaChipじゃないわけで。

これは、正しいけど、バイトコード (* も *) 解釈できる CPU だよ、普通の Java chip って。
100% Pure Java chip (=バイトコードしか解釈できない CPU) と言うのも作れるだろうけど、IO とかどうするの ?
自分だけじゃでブートもできないのは、ちょっと応用範囲が限られまくりだよね。

132 :デフォルトの名無しさん:03/07/11 23:37
>>131
>IO とかどうするの ?

出来ない理由が何かあったっけか?

133 :デフォルトの名無しさん:03/07/11 23:38
Inferno?


134 :デフォルトの名無しさん:03/07/11 23:48
>>132
もしかして...
println() ってやったら、出力できるやん。何が問題 ?
って言う理解なの ?

デバイスドライバって知ってるか ?

135 :126:03/07/11 23:52
>>131
なんか現状のJava chip実装に依存したこと書いてない?

メモリー管理や割り込み処理だってVMから下に実装すればいいだけで、
それをソフトウェアで実装する必要はないよね。
全部含めてJava chipとすれば、バイトコードのLinuxカーネルだって
動くと思うんだけどなあ。

136 :デフォルトの名無しさん:03/07/12 00:00
>>135
> それをソフトウェアで実装する必要はないよね。

ハードで実装しろと...、まあがんばってください。

まさか、μプログラムなんてソフトっぽい方法はとらないよね。
それなら、20年前に LISP でやったことあるから。
(μプログラムレベルで CG 動くと、割り込みも受けられないんだ...、よく考えたらあたりまえだけど。)

137 :126:03/07/12 00:12
ハードで実装する必要はないけどね。
クルーソーみたいな実装でもいいし。
pentiumだってソフトは載ってるし。

138 :デフォルトの名無しさん:03/07/12 01:03
>>137
天然なのかなぁ...。

> クルーソーみたいな実装でもいいし。

CMS の 'S' が何を意味するか知ってて言ってるのか ?
それとも、>>135 で「ソフトウェアで実装する必要はないよね。」と言ったことを忘れてるのか ?

139 :デフォルトの名無しさん:03/07/12 07:24
なんか非ノイマン型CPUが流行りだしても、ノイマンの常識で物を語ろうとするんだろうなぁ・・・

140 :デフォルトの名無しさん:03/07/12 07:47
UNIX系OSのカーネルって、「ここをこう直したら3%速くなりました。ヤター」
とかやってる世界なんだから、わざわざJavaで書き直して遅くするアホはい
ないと思われ…

と当たり前のことを言ってみるのはヤボですかそうですか。


141 :デフォルトの名無しさん:03/07/12 07:49
>>140
別に高速化の手段としてJavaを採用しているわけではないわけで。

じゃあ、JavaとかHSPでにちゃんねるビューア作った奴はアホなわけで。

142 :デフォルトの名無しさん:03/07/12 08:26
別に現在Javaが使われているような応用において、
Javaを否定してるわけじゃない。

> じゃあ、JavaとかHSPでにちゃんねるビューア作った奴はアホなわけで。

なんで? HSP とかビューアって、性能が第一に評価されるソフトウェア
じゃないでしょ?

UNIX系カーネルって、ほぼ同一の仕様で実装が異なるもの、わんさか
あり(Solaris,Linux,*BSD,...)、速度が遅いとあっさり見捨てられて
他に乗り換えられる運命にあるから、今のJavaには向かんよ。

JavaでCと全く同等の性能が出る時代になるか、カーネルの
性能なんてどうでもいい時代になったら話は別かもしれんが、
当分そういう時代は来ないだろうし、そういう遥か未来には、別の
言語が流行ってるんじゃないの?


143 :デフォルトの名無しさん:03/07/12 08:32
>>142
OSの評価基準はその上で動くソフトウェアやドライバがいくらあるかだと思われ。

144 :デフォルトの名無しさん:03/07/12 08:52
で、Java に書き換えたらどうなる?

利用可能なソフトウェアの数は変わらない。
カーネルの提供するインターフェース(システムコール)は
実装言語がCであろうとJavaであろうと同じだからね。

動くドライバの数は、書き換え作業の間は極端に減る。
デバイスドライバの場合、生のハードウェアにアクセス
するわけだから、Javaで書くよりも、Cで書いた方が
むしろ簡単だしな。アプリケーションと違って、Java
で書いても、バグがあればメモリ破壊とか簡単に起きる
ので、全然安全にならないし。

で、速度は、明らかに遅くなる。
そんなもの、誰が使うの?


145 :デフォルトの名無しさん:03/07/12 09:04
>>144
じゃあ、JavaとかHSPでにちゃんねるビューア作った奴はアホなわけで。

146 :デフォルトの名無しさん:03/07/12 09:08
C言語で既に存在するソフトウェアと、全く同じ仕様のものを、
JavaやHSPで書く奴は、アホかもしれんな。(勉強目的は除く)
遅くなるだけだから。

でも、JavaやHSPで書いたバージョンは、実は仕様が違う(使い
勝手が異なる)んじゃないのか?

UNIXカーネルの場合、仕様(システムコール・インターフェース)は
どのカーネルでもほぼ全く同じなの。POSIX.1で決まってるからな。


147 :デフォルトの名無しさん:03/07/12 09:17
>>146
>(勉強目的は除く)

では、Java-Linuxは肯定されるわけだ。


148 :デフォルトの名無しさん:03/07/12 09:19
勉強のためだけに100万行を越えるプログラムを書くほど
元気のある奴はおらんよ。(断言)

俺、これまで結構Javaを気に入っていたんだが、Java厨を
嫌う奴の気持ちがなんとなくわかってきてぞ。(wr


149 :デフォルトの名無しさん:03/07/12 09:31
>>148
独りよがり。

150 :デフォルトの名無しさん:03/07/12 09:46
>>139
はぁ ? もうちょっと具体的に言ってくれ。それとも単に話をはぐらかしたいだけなの ?

>>140
そういう側面もあるが、そういう方向は極論すればフルアセンブラでカリカリチューニングすればいい。

ってならないのは、当然移植性とかのバランスを考えてるからだよ。

どんなに速くたって、Cray-MP のみサポートと言われても困るだろ。

>>146
> C言語で既に存在するソフトウェアと、全く同じ仕様のものを、
> JavaやHSPで書く奴は、アホかもしれんな。(勉強目的は除く)
> 遅くなるだけだから。

速度はハードでカバー + どこでも動く (Sun の言うとおりなら...) → ウマー

を狙ってんでしょ。現実はなかなか厳しいものがあるけどさ。

151 :デフォルトの名無しさん:03/07/12 13:09
> 速度はハードでカバー + どこでも動く (Sun の言うとおりなら...) → ウマー
> を狙ってんでしょ。

「どこでも動く」ってのは、それ自体、ソフトウェアの仕様の一部だよ。

C で書かれていて、かつ、Java が動く全てのプラットフォームで
動作する 2ch ブラウザがあるなら、それと全く同じものを Java で
書いても、単に遅いだけで、メリット・ゼロじゃん。

話を戻すと、UNIX カーネルの場合、Java で書いても、どこでも
動くなんてことにはなりえない。というのは、Java がどこでも動くの
は、Java VM が機種依存性を吸収してくれるからだが、OS のカーネル
の仕事のかなりの部分が機種依存性の吸収に割かれているわけだから、
もしカーネルモードで動く Java VM に機種依存性を吸収させるので
あれば、結局、カーネルのかなりの部分を、Java で書いたパートで
はなく、Java VM の一部として書かざるを得なくなる。すなわちカーネル
のかなりの部分は、結局 C で書く (実用 Java VM のほとんどは C で
書かれているよな?) ことになっちまうからだな。

スピードは遅い、どこでも動くわけでもない、じゃ、いったいメリット
は何なんだい?


152 :デフォルトの名無しさん:03/07/12 19:08
selectでうまくゆきました。ありがとうございました。

153 :デフォルトの名無しさん:03/07/12 19:43
なんか一人だけデムパがいることがわかった

154 :デフォルトの名無しさん:03/07/12 22:04
まあ、プログラマだしな。
自分がバカなのを知らないんだろ。

155 :デフォルトの名無しさん:03/07/12 23:20
いつものJava厨の妄想ってことで。

156 :デフォルトの名無しさん:03/07/13 00:11
123と124が異なる人物だとすると、デンパは1人じゃなくて2人
かもしれん。ガクガクブルブル

157 :デフォルトの名無しさん:03/07/13 09:19
>>156
お前も含めて3人だ。

158 :デフォルトの名無しさん:03/07/13 18:07
JavaOSってのは、既存のframeworkにのっとったOSを、
単にJavaで書いたものではなくて、
class verifierとかappletとかservletとかJiniとか、
そういった概念で新しいOS frameworkを編み出すものなので、
そこんとこよろしく。


159 :デフォルトの名無しさん:03/07/13 19:25
大容量ファイルを読み込むためには
どうすればいいですか?
2G以上ぐらいだとhexdumpでもfopenでも見れないんですけど.
Cでどうすればいいですか?

160 :デフォルトの名無しさん:03/07/13 19:54
>>159
またここにも・・・
いまどうやっているのかな?
OSは?ファイルフォーマットは?使っている関数は?
また見れないとはどういうことなのかな?
fopenで失敗する、freadd失敗する?
そのときのerrnoは?
とにかく状況を細かく分析することが大事です。

161 :デフォルトの名無しさん:03/07/13 20:16
>>159

それって、Linux カーネルを C#/Java で書き直すって話とは
直接関係ないのでは?

>>160

ここ参照。
http://ftp.sas.com/standards/large.file/x_open.20Mar96.html

簡単に言うと、cc のオプションに
`getconf LFS_CFLAGS` `getconf LFS_LDFLAGS` `getconf LFS_LIBS`
をつける必要がある。ただし、リンクする全てのモジュールの
コンパイルオプションにつけておかないと悲惨な目に会いかねない
から注意。
(single quotation じゃなくて back quotation であることにも注意。
それから、Tru64と*BSDは、オプションなしで最初から2GB以上の
ファイルをオープンできるため、このオプションは存在しない。)

あと、もしもOSがLinuxで、カーネルが2.2以前の場合、カーネルの
2.4以降に更新する他ないので、諦めるしかないこともある。


162 :159:03/07/13 21:58
>>160 161
どうもありがとうございます.
OSは Red Hat Linux 9.0です.

とりあえず試してみます.

163 :159:03/07/13 22:29
>>160
書き忘れましたが,
errnoの確認してませんが,
fopenの時点でNULLが返ってきます.


>161
gcc `getconf LFS_CFLAGS` `getconf LFS_LDFLAGS` `getconf LFS_LIBS` foo.c
みたいな感じですか?
Mac OS X (10.2.6)で試したんですけど
getconfがないみたいです.
またRed Hatで試したら報告します.

164 :160:03/07/14 10:37
>>159
LFS(Large File Summit)の対応は各UNIXによって違うようですね。
RedHatのサポートに聞くのが一番早いと思うのですが。
要は従来ファイル内のオフセットをlong(int)で持っていたのだが、
これだと最大オフセットが2^31=2Gで、それを超えるサイズのファイル
はアクセスできない。なんかファイルサイズの2000年問題みたいですね。
パッチとかも必要そうだし、やっぱりベンダーに聞くのが一番かな?
参考turbolinux
http://www.turbolinux.co.jp/knowledge/public/360.html

165 :デフォルトの名無しさん:03/07/14 11:32
>>164
サポートを受けられるとは限らないと思うけど・・・

166 : :03/07/14 13:18
>>159

fopen系の関数を全てラージファイル対応にするには、-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
あたりのオプションをつけてコンパイルすべし。ファイルオフセットは long じゃたりなくなるので、
fpos_t ね。

既存のコードとのコンパチビリティ等が気になるなら、必要な部分だけ fopen64 とか fread64 とか
使っても良い。

167 :デフォルトの名無しさん:03/07/14 13:20
>>166
sageてください

168 :デフォルトの名無しさん:03/07/14 17:31
64bit値をprintfしたいんですけど、どうすれば?

169 :デフォルトの名無しさん:03/07/14 17:33
man printf

170 :デフォルトの名無しさん:03/07/14 23:16
>>163
MacOS XのUNIX部分は、*BSD系だと聞いているから(使ったことないけど)
何もオプションをつけなくても、2GB以上のファイルが使えるんじゃない
かな。

>>163,164
RedHat 9.0 なら、161 の方法で大丈夫な筈。

>>166
それよりは、161の方が移植性が高いんじゃないかな?
あと、細かいことを言うと、明示的に -D_LARGEFILE_SOURCE を指定する
必要があるのは、fseeko() と ftello() が使いたい場合ぐらいで、もし
この2つの関数が不要ならば -D_LARGEFILE_SOURCE は要らない筈。
(もっとも Solaris で `getconf LFS_CFLAGS` すると、デフォールトで
-D_LARGEFILE_SOURCE も有効になるけど。でも、こうならないプラット
フォームもある。)

で、もし -D_LARGEFILE_SOURCE と -D_FILE_OFFSET_BITS=64 の両方が
有効なプラットフォームなら、この2つを定義した段階で、off_t が
64ビットになるので、fpos_t を使わずに、fseeko() と ftello() に
off_t を渡すという手もある。

> 既存のコードとのコンパチビリティ等が気になるなら、必要な部分だけ
> fopen64 とか fread64 とか使っても良い。

このAPIを使いたい場合、cc のオプションに
-D_LARGEFILE64_SOURCE `getconf LFS64_CFLAGS` `getconf LFS64_LDFLAGS` `getconf LFS64_LIBS`
をつけないと、移植性がなくなると思う。
あと、この場合オープンなど全ての関数をfopen64()のように書き換えないと
まずいので注意。それに、標準入力が2GBを越えた場合の動作保証とかもない
んじゃないかな。


171 :デフォルトの名無しさん:03/07/15 00:44
>>170
Mac OS X 10.2.6は、

/usr/include/sys/types.h:typedef int64_t quad_t;
/usr/include/sys/types.h:typedef quad_t off_t; /* file offset */

で、/usr/include/stdio.hで、

#if !defined(_ANSI_SOURCE) && !defined(__STRICT_ANSI__)
typedef off_t fpos_t;
#else
typedef struct __sfpos {
char _pos[8];
} fpos_t;
#endif

よ。

172 :デフォルトの名無しさん:03/07/15 06:31
>、*BSD系だと聞いている
例えばNetBSDとFreeBSDは全くの別物ですが。


173 :山崎 渉:03/07/15 09:44

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

174 :159:03/07/15 22:21
みなさま激しい討論どうもです.

163で書いたように
gcc `getconf LFS_CFLAGS` `getconf LFS_LDFLAGS` `getconf LFS_LIBS` foo.c
でコンパイルしてみました.
最初の6バイトぐらいは読むことができましたが
それ以降はセクメントエラーになりまして,
なおかつ値が違っています.

使用した関数はfopenとfreadとfseekです.
-D_LARGEFILE_SOURCE と -D_FILE_OFFSET_BITS=64
をコンパイルオプションにしてfopen64, fread64の使用を試みましたが,
fread64が見つからず,
fopen64とfreadの組み合わせでも同じくセグメントエラーになりました.
ちなみにOSはRed Hat 9.0で試しました.

175 :デフォルトの名無しさん:03/07/15 23:21
> 例えばNetBSDとFreeBSDは全くの別物ですが。

おいおい。

NetBSDとFreeBSDが別れてからは、当然違いも出てきているが、
4.4-lite時代から引き継いでいる部分は同じだろ。それに別れて
からも、相互にimportしあっているため、同じ部分も多いだろ。
最近だと、rc.dとかrescueとかはNetBSDからFreeBSDへのimport
だし、逆にkqueueはFreeBSDからNetBSDへのimportだしな。

今回話題のoff_tが64bitである件については、4.4-liteからの
流れだから、NetBSD、FreeBSD、OpenBSD全てで同じ。また
171を見る限り、MacOS Xも、同じ流れを組んでいて、最初から
off_tが64bit。

つまり、この話題に関しては、NetBSDとFreeBSDはほぼ全く同じ
と考えれば良い筈だ。


176 :デフォルトの名無しさん:03/07/15 23:59
>>174
おかしいなあ。
RedHat-8.0 だが、下記のプログラムを
gcc `getconf LFS_CFLAGS` `getconf LFS_LDFLAGS` `getconf LFS_LIBS` -o hoge hoge.c
でコンパイルして、2GBを越えるファイルに対して
  ./hoge ファイル名 | cmp - ファイル名
したが、ちゃんと動いているぞ。
ちなみに、オプションなしでコンパイルすると
  ファイル名: File too large
になる。
Redhat-8.0→9.0で、バグが入ったとも思えんのだが。

#include <stdio.h>

main(int argc, char **argv)
{
 int i, c;
 FILE *fp;

 for (i = 1; i < argc; i++) {
  fp = fopen(argv[i], "r");
  if (fp == NULL) {
   perror(argv[i]);
   return 1;
  }
  while ((c = getc(fp)) != EOF)
   putchar(c);
 }
 return 0;
}

177 :デフォルトの名無しさん:03/07/16 06:02
>>174
まず1kBくらいのファイルで試してデバッグしろ。

178 :159:03/07/16 09:08
>176, 177
176とほとんど同じプログラムですよ。


179 :159:03/07/16 09:22
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[]) {
unsigned short s;
if (argc > 1) {
filename = argv[1];
if ((fp = fopen (filename, "rb"))==NULL) {
fprintf (stderr, "Can't open %s.\n", filename);
exit (1);
}

fread (&s, sizeof (unsigned short), 1, fp);
fprintf (stdout, "s = %d\n", s);
}
return (0);
}

バイナリなのでこんな感じです.

180 :デフォルトの名無しさん:03/07/16 09:27
バイナリってなんだ、、、

181 :デフォルトの名無しさん:03/07/16 09:30
>>179
> fprintf (stdout,

printfをしらんのか?

182 :デフォルトの名無しさん:03/07/16 10:53
>>180
主にCR+LF→LF変換抑止のための、"rb"の'b'ですよ。

183 :デフォルトの名無しさん:03/07/16 10:53
>>179
細かいツッコミはともかく、filenameとfpが未定義だし、
それを定義してもIA32なら2byteしか読まんあたり、
そのまんまのコードとは思えん。

184 :デフォルトの名無しさん:03/07/16 10:56
>>182
真性かよ

185 :デフォルトの名無しさん:03/07/16 11:05
glibcはbついてても無視するだけだから、この際関係ないはず。

186 :デフォルトの名無しさん:03/07/16 11:09
>>182
http://www.linux.or.jp/JM/html/LDP_man-pages/man3/fopen.3.html
知っててやってるならいいがな。

187 :159:03/07/16 13:01
>>183
確かに未定義でしたね。

hexdump -v -C ファイル名 | less
だと、
25 cc 00 ・・・。
とあったので 2バイトしか読んでないです。
本当はもっとfread以降も書いてますよ。

そして値は10進数に変換すると、
9676になるはずですが、
上のプログラムでは値が異なってました。

188 :デフォルトの名無しさん:03/07/16 13:30
glibc の fopen テキストモードは
`\r\n' を `\n' に変換しましたっけ…?

189 :デフォルトの名無しさん:03/07/16 13:34
もうネタはいいよ。勘弁してくれ

190 :デフォルトの名無しさん:03/07/16 15:30
>>159
OSを疑う前に、まず

unsigned short s;

unsigned char s[2];
に変更し、

fread (&s, sizeof (unsigned short), 1, fp);
fprintf (stdout, "s = %d\n", s);

fread (s, sizeof(s), 1, fp);
printf("s[] = 0x%02x:0x%02x\n", s[0], s[1]);
に変更して、試してみるように。

> 値は10進数に変換すると、
> 9676になるはずですが、
> 上のプログラムでは値が異なってました。

どうせ52261って表示されたんだろ? それで合ってるんだよ。
「big endian」と「little endian」でぐぐれ。

まず自分のミスを疑えっていうのは、プログラミングを
勉強する上での基本だ。


191 :159:03/07/16 20:47
>>190

そのとおりです m(_ _)m
ぐぐって解決します。

192 :デフォルトの名無しさん:03/07/16 21:35
ぐぐるよりまず、まともに動くプログラムでテストしろ。

193 :デフォルトの名無しさん:03/07/16 22:56
てっきり以前に(同じ環境で)short変数の中身をfwriteしたものを読んでいるんだと思っていた・・・

それにしても190がひっそりとprintfに直しているところにワラタ

194 :159:03/07/17 00:06
>>192
Macでは動いてたんで安易に考えすぎましたわ

195 :デフォルトの名無しさん:03/07/17 01:38
>>194
問題を理解できてるの? かなり不安な一行レスなんだけども…

MacでつくったデータをMacでよむのはOK,
Linux for x86でつくったデータをLinux for x86でよむのはOK.
全然over 2Gbyteの問題じゃない。Byte orderの問題。

196 :デフォルトの名無しさん:03/07/17 06:21
>>195
いつからバイトオーダの違うファイルが読めなくなったんだ?

197 :デフォルトの名無しさん:03/07/17 07:06
読めないんじゃなくて、正しく読めないと勘違いしたんだろ。159が

198 :デフォルトの名無しさん:03/07/17 07:56
いつまでも入門者をいじめるなよ・・・
↓次の質問どぞー

199 :デフォルトの名無しさん:03/07/17 23:08
188が、ネタなのか、それともUNIXでテキストモードとバイナリモードの
区別があると思っているのか、どちらなのか教えてください。おながい
します。


200 :デフォルトの名無しさん:03/07/17 23:32
とりあえず200

201 :デフォルトの名無しさん:03/07/18 00:56
linuxのgccでs-sjisのコードをビルドすることはできますか?
普通にやるとエスケープコードがどーたらこーたらという警告が出ます。

202 :デフォルトの名無しさん:03/07/18 00:59
コードは普通ASCIIで書くもんだ。

203 :デフォルトの名無しさん:03/07/18 01:04
>>202
文字列定数はコードの一部じゃないの?

204 :デフォルトの名無しさん:03/07/18 01:14
>>201
文字定数、文字列定数、コメントだけでいいですか?

./configure --enable-c-mbcharでcompileして、(gcc -vで確認可能)
環境変数LANGをC-SJISかな?

205 :201:03/07/18 01:40
>>204
>文字定数、文字列定数、コメントだけでいいですか?
これでいいですが、キーワードを検索したところ

ビルドオプション --enable-c-mbchar の仕様の問題
一部方面で「configureに --enable-c-mbchar を指定してmakeしなおしたgccを用い,
環境変数 LANG=C-SJIS を指定すると,gccをSJIS対応にできる」という情報がありますが,
これは限りなく誤報に近いです。
http://homepage1.nifty.com/kuuku/gcc-sjis/

とありますがどうしたものでしょう。警告箇所に\を入れて回るのが無難ですかね。

206 :デフォルトの名無しさん:03/07/18 01:53
プログラムの設定ファイルって、どこに置けば言いの?
できればプログラムをインストールした同じ所におきたいんですが。

あと、
fopen("~/hoge" "r");
とかしても開けないみたいです。こういう場合はどうするんですか?
(自分のホームの絶対パスが必要なのかな?)

207 :_:03/07/18 01:53
http://homepage.mac.com/hiroyuki44/

208 :デフォルトの名無しさん:03/07/18 01:55
>>206
~/hogeの~をなにが展開するか考えればできない理由がわかるはず。
ホームディレクトリならgetenv("HOME")で得られるんじゃないかな?

209 :デフォルトの名無しさん:03/07/18 02:27
>>205
どうでもいいけど差分を置いて欲しいよ。

210 :デフォルトの名無しさん:03/07/18 02:47
>>205
> http://homepage1.nifty.com/kuuku/gcc-sjis/
かなりad hocな改造だからこのまま取り込まれることはあり得ないだろうが、
対応は必要だろうな。

ただ、--enable-c-mbcharがあまり使われてないのは、文化がどうこうよりも
gettextizeの方が主流になって来てるからじゃないかと思う。


211 :デフォルトの名無しさん:03/07/18 02:56
めんどくさいから漏れはSJIS文字を\xxx\xxxと展開するフィルタを
かますだけにしてる。
includeとかは知らん。

212 :_:03/07/18 03:04
http://homepage.mac.com/hiroyuki44/

213 :デフォルトの名無しさん:03/07/18 06:08
>>206
> できればプログラムをインストールした同じ所におきたいんですが。
プログラムのある場所が自由に書けるなんてものすごい設定が標準の
Windowsににかぶれすぎ


214 :デフォルトの名無しさん:03/07/18 06:23
>>213
はいはい。日本語が話せないやつは帰った帰った。

215 :デフォルトの名無しさん:03/07/18 06:23
>>210
「どう考えても馬鹿げてる」のはソースに直接日本語文字列を
埋め込むことのほうだよな。
で、GNU信者が感情的だとか日本は三流の国だとかに至っては
ほとんどデンパだ

216 :デフォルトの名無しさん:03/07/18 06:24
>>214
日本語読めない奴は帰れ

217 :正しい日本語晒しあげw:03/07/18 08:11
プログラムのある場所が自由に書けるなんてものすごい設定が標準の
Windowsににかぶれすぎ
プログラムのある場所が自由に書けるなんてものすごい設定が標準の
Windowsににかぶれすぎ
プログラムのある場所が自由に書けるなんてものすごい設定が標準の
Windowsににかぶれすぎ
プログラムのある場所が自由に書けるなんてものすごい設定が標準の
Windowsににかぶれすぎ
プログラムのある場所が自由に書けるなんてものすごい設定が標準の
Windowsににかぶれすぎ
プログラムのある場所が自由に書けるなんてものすごい設定が標準の
Windowsににかぶれすぎ

218 :デフォルトの名無しさん:03/07/18 08:54
後々面倒だからEUCでやっちゃったほうがいい

219 :デフォルトの名無しさん:03/07/18 09:19
Windowsの場合も、

>>206
> プログラムの設定ファイルって、どこに置けば言いの?
> できればプログラムをインストールした同じ所におきたいんですが。

としてしまうと、multi user対応guildelineに適合しなくなってしまうわけだが…

220 :デフォルトの名無しさん:03/07/18 09:24
>>219
guildelineって何?

221 :デフォルトの名無しさん:03/07/18 09:35
ギルドの線。

222 :デフォルトの名無しさん:03/07/18 14:11
設定ファイルを配置するディレクトリの
定番はやはり$HOMEですかね

223 :デフォルトの名無しさん:03/07/18 14:15
~/Application Data/<APPNAME>/
が基本だろ。

224 :デフォルトの名無しさん:03/07/18 15:43
レジストリに入れるのはどうだろう?

225 :デフォルトの名無しさん:03/07/18 19:01
~/.gnome/apps/ か?

226 :デフォルトの名無しさん:03/07/19 05:34
>>219
Microsoftの方針はともかく、実運用レベルではいまだに
プライベートini派が勢力を保ってるんで。
http://pc2.2ch.net/test/read.cgi/software/1048216458/l50

227 :デフォルトの名無しさん:03/07/19 08:53
「2ちゃんのとあるスレでは」でしょ。

228 :デフォルトの名無しさん:03/07/19 11:36
Mac OS Xは、~/Library/Preferences/の下に、
例えばnet.2ch.tech.plistってXML plist fileだな。

229 :デフォルトの名無しさん:03/07/19 22:28
>>227
スレは例としてあげただけでレジストリ嫌い発言はいたるところで見かけるが
確かに母集団は偏ってるかもな

230 :デフォルトの名無しさん:03/07/20 18:00
Linuxにレジストリを導入しようという声が強いから、じきにSolarisとかでも
レジストリが使えるようになるよ、きっと。

231 :デフォルトの名無しさん:03/07/20 23:13
>Linuxにレジストリを導入しようという声が強いから、

初めて聞いた。


232 :デフォルトの名無しさん:03/07/21 00:46
>>230
ハハ

233 :デフォルトの名無しさん:03/07/21 00:51
ほんとになりそうで怖い。

234 :デフォルトの名無しさん:03/07/21 01:30
かんべんしてくれ

235 :デフォルトの名無しさん:03/07/21 12:54
それじゃあ、UNIXでも移動プロファイル導入ですね。

236 :デフォルトの名無しさん:03/07/21 14:42
>>230
AIXを使え。
ODMっていうレジストリっぽいのがあるぞ。

237 :デフォルトの名無しさん:03/07/21 15:16
真の革新は常にWindowsに有り。
Unix/Linuxは常に後追いだな。

238 :デフォルトの名無しさん:03/07/21 16:46
>>235
$HOMEをNFSマウントすりゃ、似たようなもんだろ。


239 :デフォルトの名無しさん:03/07/21 18:59
>>237
標準入出力はUNIXの方が先ですが。

240 :デフォルトの名無しさん:03/07/21 20:56
>>238
やっぱり設定ファイルだけログオン/ログオフ時にコピーしないと…
同じ不具合が楽しめません。

241 :デフォルトの名無しさん:03/07/22 07:13
Windowsがいつも最初と思ってるとは
おめでたいにもほどがありますな

242 :デフォルトの名無しさん:03/07/22 11:57
標準入出力が革新だと思ってるとは
おめでたいにもほどがありますな

243 :デフォルトの名無しさん:03/07/22 13:52
Linux + gccなんですが、
コマンドラインでargv[1]に"*"を渡すと、なぜか"2m"という文字列が入ります。
どうしてですか?

244 :デフォルトの名無しさん:03/07/22 13:54
そのディレクトリに2mという名前のファイルがあるから

245 :デフォルトの名無しさん:03/07/22 13:55
>>243
> argv[1]に"*"を渡すと、

渡していない。

246 :243:03/07/22 13:58
>>244,245
すんません、ワイルドカードを忘れていたとは...恥ずかしい

247 :デフォルトの名無しさん:03/07/22 13:58
./command '*'

248 :COBOLer:03/07/22 21:17
>>242
えっ何を言ってるんですか
革新的に決まってるじゃないですか

249 :デフォルトの名無しさん:03/07/22 21:36
*って誰が展開するの?スタートアップルーチン?

250 :デフォルトの名無しさん:03/07/22 21:39
シェル

251 :デフォルトの名無しさん:03/07/22 21:42
>>249-250

ワラタ

252 :デフォルトの名無しさん:03/07/23 01:42
どこが面白いんだ?

253 :デフォルトの名無しさん:03/07/23 13:21
たぶん>>251の顔。

254 :デフォルトの名無しさん:03/07/25 03:36
デーモン型のようなサーバプログラムは、どうやって作るのが一般的なのでしょうか?

ぱっと思いついたのは、
起動後system関数を用いて常駐専用のプロセスを起動、
以後はパイプ経由でその常駐プログラムを操作・・といった形式なのですが、
ぶっちゃけ、これで良いのでしょうか?






255 :デフォルトの名無しさん:03/07/25 10:45
regexを使っているのですが、"^"を使っても文字列の先頭にはマッチしますが、
行頭にはマッチしてくれません。行頭にマッチさせる方法はないものでしょうか?

256 :デフォルトの名無しさん:03/07/25 10:58
REG_NEWLINE

257 :255:03/07/25 11:13
非常に申し上げにくいのですが、間違ってregexecにREG_NEWLINEと書いていました。
regcompの方にちゃんと書いたら当たり前のように動きました。
どうもありがとうございました。

258 :デフォルトの名無しさん:03/07/25 11:56
>>254
daemon自身がfork()し、親はすぐ終了。子は養子縁組に出されて動き続ける。
controling terminalをdetachする。
/tmp,/dev,/var/run辺りにあるnamed pipeを使う。(e.g. lpd, syslog)
が古典的。

259 :デフォルトの名無しさん:03/07/25 12:32
>>254
自分で fork() などせずに daemontools にまかせるのが djb 信者的

260 :デフォルトの名無しさん:03/07/25 12:38
daemon()呼ぶ

261 :デフォルトの名無しさん:03/07/25 12:53
daemonを殺す関数、amon()。

262 :デフォルトの名無しさん:03/07/25 12:55
常駐型のサーバプロセスってデーモンにした方がいいんですか?
デーモンにすると何が嬉しいんですか?

263 :デフォルトの名無しさん:03/07/25 13:14
amen()じゃなかったっけ。


264 :デフォルトの名無しさん:03/07/25 14:20
端末にぶらさがってたら不便だろう。

265 :254:03/07/25 14:45
>>258-262

さんきゅー、とりあえずキーワードを元に色々調べて見ます。



266 :デフォルトの名無しさん:03/07/25 19:08
>>261,263
abon()

267 :デフォルトの名無しさん:03/07/26 00:22
>>264
ふつー inetd 経由で起動させるか、スタンドアロンにするかの選択だろう。


268 :デフォルトの名無しさん:03/07/26 00:26
>>267
スタンドアロンにした時に、
コントローリング・ターミナル持ったままだとうざいことを>>264は言ってんでしょ?
シェルのジョブ・コントロールか何かと勘違いしてませんか?

269 :デフォルトの名無しさん:03/07/26 00:40
/bin/daemonize はどうよ?


270 :名無しさん@Emacs:03/07/29 17:29
XIMがらみのプログラムをC++でいつかは創りたいなぁと思ってるのですが、
GUIのライブラリはどれが便利なんでしょうか?

gtk, qtはなんか使いたくないので、
そうするとMotif, Xtあたりしか残ってないですかねぇ?


271 :デフォルトの名無しさん:03/07/29 18:19
お、釣りだ。

272 :デフォルトの名無しさん:03/07/29 18:41
>>270
http://pc2.2ch.net/test/read.cgi/tech/1052481777/

273 :デフォルトの名無しさん:03/07/29 22:54
>>270
Fox wx

274 :デフォルトの名無しさん:03/07/30 01:36
>>270
http://home.pacbell.net/atai/guitool/
http://sal.linet.gr.jp/F/5/index.shtml

275 :山崎 渉:03/08/02 02:12
(^^)

276 :デフォルトの名無しさん:03/08/05 21:56
前スレがなくなっとる・・・

277 :デフォルトの名無しさん:03/08/08 07:32
999999999番以下のスレッドは倉庫行き処理のバグで行方不明になります

278 :デフォルトの名無しさん:03/08/08 09:40
読めるぞ。
と思ったらnavi2chのキャッシュか。

279 :デフォルトの名無しさん:03/08/08 13:27
>>278
アップきぼーん

280 :デフォルトの名無しさん:03/08/08 15:21
>>279
俺もあるがどこへしたらいい?
ウプロダとか言うところにウプすればいいのか?

281 :デフォルトの名無しさん:03/08/08 19:43
>>280
それでよろしく頼みます。
http://link.ziyu.net/html/uplink.html

282 :デフォルトの名無しさん:03/08/09 20:17
PCゲームってのはコア層がやるもんだよ。
過去の現象見ても、事務機としての普及が第一だろうね。

はっきり言ってLinux/UNIXは汎用的な事務機としてはロクなもんじゃない。
基本的に計算機の玄人が使うようにできてるからな。
事務屋にゃ扱える代物じゃねーんだよ。

ただ、つけいる隙はあると思うね。
Linux/UNIXはUIの取り換えがきくから、専用機として作り込むのにはWindows
なんかより断然いいだろう。
そこらへんのじじばばが何気に街角で触ってる機械が実は誰も知らないけど
Linuxでしたなんて現象はこれからどんどん増えるだろうね。
事務機としてもマルチウィンドウが必要なところってのは実はあんまり無い。
その証拠にほとんどのWindowsユーザはアプリケーションを最大化して使って
るじゃない。
Xなんか使わなくてもDOS時代のUIを思い出せば充分使えるものになるだろうね。
むしろその方が混乱が無いだろう。アクティブウィンドウが切り替わっただけ
で「パソコン壊れたー!」ってパニック起こす連中を嫌と言うほど見て来た。

パソコンとしてもそれに適したUIが出て来れば使う人はいるだろうね。
そのへん頑張ってるのがKDEやGnomeだが、こっちはさほど利点が無いから難し
いな。
NECや富士通が気合い入れて自社UIを作って出しゃいいんだがな。KDEやGnome
ベースでもいいからさ。




283 :デフォルトの名無しさん:03/08/09 20:37
>282
>Linux/UNIXはUIの取り換えがきくから、専用機として作り込むのにはWindows
作ってから言え

>Linuxでしたなんて現象はこれからどんどん増えるだろうね。
作ってから言え



>282
作ってから言え

284 :デフォルトの名無しさん:03/08/09 20:46
>>283
コピペにマジレスですか?

285 :デフォルトの名無しさん:03/08/09 20:51
>284
どこのコピペだよ

286 :デフォルトの名無しさん:03/08/09 20:52
>>285
Linux板
UNIX板にもコピペされている

287 :デフォルトの名無しさん:03/08/09 20:54
>286
コピペにレスしたって別にいいじゃねーか
いちいち反応すんなボケ

288 :デフォルトの名無しさん:03/08/09 20:55
>>287
ごめんね

289 :デフォルトの名無しさん:03/08/09 21:44
コピペにマジレスと指摘されて「どこの」と絡むも、
あっさり反論されたので開き直った287に萌え

290 :デフォルトの名無しさん:03/08/10 01:28
ある意味、男らしい。

291 :デフォルトの名無しさん:03/08/10 05:17
>NECや富士通が気合い入れて自社UIを作って出しゃいいんだがな。KDEやGnome
>ベースでもいいからさ。
悪夢。


292 :デフォルトの名無しさん:03/08/10 10:24
童夢君。

293 :デフォルトの名無しさん:03/08/11 01:46
たまにはあげるか。

294 :278:03/08/11 01:55
>>280
アップした?

295 :デフォルトの名無しさん:03/08/11 04:47
>>291
誰も使わないです。

296 :デフォルトの名無しさん:03/08/11 05:03
★★★★★★★★★★★★★★★★★★★★
★  激安アダルトDVDショップ   ★
★  お買い得セール1枚500円〜!急げ!★
★★★★★★★★★★★★★★★★★★★★
        激安でDVDをGET!
      http://www.get-dvd.com
   何と! 1枚 500円〜 セール中!

   インターネット初!「きたぐに割引」
  北海道・東北の皆様は送料も激安!!
      http://www.get-dvd.com
       ゲットDVDドットコム!
   
    今すぐアクセス  Let's go !!!!!!!


297 :_:03/08/11 05:32
http://homepage.mac.com/hiroyuki45/hankaku03.html

298 :_:03/08/11 06:15
http://homepage.mac.com/hiroyuki45/

299 :デフォルトの名無しさん:03/08/12 07:41
>>276
●板で捜索願いを出したらhtml化してもらえました。
http://pc2.2ch.net/tech/kako/992/992057422.html

300 :デフォルトの名無しさん:03/08/12 20:19
>>299
激しく感謝します。

そのフォーマット(?)にしたがってURLをつくれば行方不明のスレッドも見つけられるのか。


301 :デフォルトの名無しさん:03/08/12 23:17
html化されてなきゃ無駄。

302 :山崎 渉:03/08/15 15:46
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

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

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

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)