|
>ん、gzip で圧縮して送って、向こうで伸張できたのですか? >なら最大ファイルサイズは関係なかったですね。 ファイルサイズですが、FreeBSD 4.1-RELEASE で 6GB 以上の報告も あるようです。6GB のディスクを dd コマンドでファイル化した なんて話がどこかで書いてありました(URI は失念しました)。 推測の域を出ませんが、2GB で引っかかったというので思い付いたのですが…。 まさかとは思いますが、singed int でファイルサイズを保持しているような 状況だとエラーが出るでしょうね。プログラムのバグかも知れません。 >grep −−− dir/* というのがありますが >これでよいのでしょうか。 この質問は答えにくいですね。dir 以下のディレクトリツリーを トラバースするのなら、これじゃ不足です。 find . -type f -exec grep PATTERN {} \; ですかね。GNU grep 使っているのなら、 grep -r PATTERN * でもすみます。ただし、シンボリックリンクがループしていると死にますね。 質問をみるとファイル名だけが表示されれば良いようにも読めるので、 そういった場合だと、 grep -rl PATTERN * かな？ >適当なデータを作って、実験してみましょう。sort できる >限界までいったら、swap の状況を見つつ、sort のせいなのか >メモリが足りないのか見極めましょう。 GNU sort の場合 TMPDIR みていますね。ルートパーティションを 小さめにとっているシステム( 32MB とか 64MB )だと、メモリがあまっているのに ファイルシステムがあふれたりして。256MB メモリのあるマシンで実験したら、 こんな感じです。 % la -alF total 40330 -rw------- 1 root wheel 36666584 Dec 10 05:51 hoge % sort hoge /: write failed, file system is full sort: write error: No space left on device ちなみに、ルートパーティションは 64MB で、のこり 17 MB でした。 >perlが存在するパスは？ 蛇足ですが、CGI スクリプトを win から binary mode で転送すると パスが正しくてもアウトですね。一行目が #!/usr/bin/perl^M とかなりますから。^M って CR のことです。つまり ascii の 0x0d |
|
> GNU grep 使っているのなら、 > grep -r PATTERN * あれ、今の GNU grep って recursive option あるんですか。 と思って ChangeLog 見たら、-r が追加されたのは 1998/08/18 でした。結構前なんですね。 |
|
nac と申します。ネットワークプログラミング大変参考になりました。 私も、POP３ クライアントを作ってみて疑問がでてきました。 rfc1939 を読んでみると pop3 サーバーの返答は ５１２文字まで と書いてありました。そこで、一行が５１２文字以上のメールを pop3 から落してくると、次のように hogehoge...hoge!CRLF hogehoge....hogeCRCF 途中で ！ マークが入っておりました。rfc1939 を読む限りこの、！ に ついては言及されていないようですが、これはどこで規定されているのでしょうか。 (もし、rfc の中で書いてあるようでしたら、理解不足です、すいません) |
|
> rfc1939 を読む限りこの、！ については言及されて > いないようですが ちらっとしか見てませんが、512 ってレスポンス行 (+OK とか +ERR) の最大長であって、メールの1文の長さとは 無関係じゃないでしょうか? とはいえ、! で fold されていたというのは気になりますね。 現在 IMAP 環境しかないので試せませんが、その POP3 サーバアプリケーションの名前を教えてください。qpopper ですか? |
|
一応インストールは成功しているみたいです。GNOME+enlightenmentで「サウンドを有効にする」ボタンを押したらでは正常に動いたのですが、その後デスクトップのタスクバーが出なくなり、仕方なく再インストールして一からやり直したんですが、GNOM＋Sawmillでは無理なんでしょうか？ PCはNECのLAVIE「LV16CWS」（ノート型）です。サウンドカードはESS社 ES1869Sで、動作確認の取れたOSSの最新版ファイルをインストール済みです。ディストリビューションは、Turbo Linux６．０です。 音だけじゃなくて、スクリーンセイバーもKDEだと動くのにGNOMEではプレビューでは見れても、実際には動きません。ウィンドウマネージャーとの愛称って在るんですかね？？？誰かアドバイスお願いします。 あとメモリーの自動認識ができないのですが、方法ありますか？解れば教えて下さい。96MBなのでデフォルトでは認識しないようです。宜しくお願いします。 |
|
skel.103Mさん @hayataです。 No.1437でのアドバイスありがとうございます。 出張でこちらの掲示板を見落としてしまいました。これからアドバイスに沿って再挑戦してみます。 成功しましたは報告いたします。 ではでは |
|
1430の回答、ありがとうございました。 すぐに応答くださったのに、質問を投げた私が、反応が鈍く、 大変失礼いたしました。 「ヘルスチェック」という言い方は、どうやら「職場方言」のようですが、 68userさんの御推測の通りのものです。 回答いただいたうちの、３、及び４を、使用してみようと思っています。 ありがとうございました。 また、なにかの折りには、よろしくお願いいたします。 |
|
>とはいえ、! で fold されていたというのは気になりますね。 qpopper の場合一行の最大は \0 込みで 1024 bytes です。 ソースを見ると早いでしょう。 /* Send the header of the message followed by a blank line */ while (fgets(buffer, MAXMSGLINELEN, p->drop)) { if (!strncasecmp(buffer, "Content-Length:", 15) || !strncasecmp(buffer, "X-UIDL:", 7)) { /* Skip UIDLs */ continue; /* Content-Length is MTA dependent, don't send to MUA */ } \0 込みと言うのは、fgets 使っているための仕様です。 もしも、512 文字というのが 2 バイト文字の意味で、512 文字なら ちょうどこの制限に引っかかります。\0 込みなので、iso2022-jp なら 途中出来られると ! なんていくらでも出て来ます。iso-2022-jp なら 「。」なんて「!#」とかなりますから。 ただ、普通は困りませんね。rfc で決められている一行の推奨値は 70 bytes + αですから。 問題は本当に POP3 サーバだけの制限なのかということです。 実験の際に使った MUA や MTA の制限も関係あります。 sendmail 8.11.1 のソースを見たら行の長さ関係は 2048 bytes でした。 また POP3 サーバなどをinetd を通している場合 inetd 自体の制限も あります。8192 bytes かな? FreeBSD の inted の場合。ヘッダーしか見て いないので断定できませんけど。 もっとも、自分で /var/mail/ のファイルにメールらしきものを手動で append して実験した場合は話は別ですが。 他にも実験を telnet でやったのなら、telnet などの制限も考えられます。 FreeBSD なら ring buffer 使っているので、 そういう制限はありませんが、OS のベンダによってこの実装は変わるでしょうね。 |
|
> qpopper の場合一行の最大は \0 込みで 1024 bytes です。 それはヘッダの出力で、本文はその下の /* Send the message body */ while(fgets(buffer, MAXMSGLINELEN, p->drop)) { /* Decrement the lines sent (for a TOP command) */ if (--msg_lines <= 0) break; pop_sendline(p,buffer); if (hangup) return(pop_msg(p, POP_FAILURE, "SIGHUP or SIGPIPE flagged")); } でないでしょうか。で、pop_sendline は pop_sendline(POP *p, char *buffer){ char * bp; /* Look for a <NL> in the buffer */ if (bp = index(buffer,NEWLINE)) *bp = 0; /* Send the line to the client */ (void)fputs(buffer,p->output); /* Put a <CR><NL> if a newline was removed from the buffer */ if (bp) (void)fputs ("\r\n",p->output); } となっているので (一部略)、fgets で得たデータに改行が 含まれない場合も、余計な改行は付加されないように思う のですがどうでしょう # 改行なしだと bp==NULL になって fputs("\r\n") は実行されない。 rosegarden さんは qpopper-2.x 系列を見ておられるよう ですが、僕が見たのは qpopper-2.2 (ってこりゃまた古いな) の pop_send.c です。 |
|
>rosegarden さんは qpopper-2.x 系列を見ておられるよう >ですが、僕が見たのは qpopper-2.2 (ってこりゃまた古いな) >の pop_send.c です。 私が見たのは、qpopper-2.3 のソースですね。古いことにはかわりないんですが…。 確かに、 >それはヘッダの出力で、本文はその下の > /* Send the message body */ > while(fgets(buffer, MAXMSGLINELEN, p->drop)) { は御指摘の通りです。本質的にソースに差異はありません。でも、 これも結局 #define MAXLINELEN 1024 #define MAXMSGLINELEN MAXLINELEN なんで、結果的には同じですね。ただし、結果的に同じだっただけで、 私の間違いは間違いです。御指摘ありがとうございます。 なお、上のは同じバージョンの popper.h の define です。 >となっているので (一部略)、fgets で得たデータに改行が >含まれない場合も、余計な改行は付加されないように思う >のですがどうでしょう まず、fgets は man 3 fgets すると >The fgets() function reads at most one less than the number of characters >specified by size from the given stream and stores them in the string str. 最大で size で指定された文字から一文字少ない文字をバッファに読み込む とあります。これは \0 をappendしないといけないからです。 サンプルプログラムを次のようにします。 #include <stdio.h> int main( int argc, char **argv ) { FILE *fp; char buff[256]; if( argc != 2 ){ fprintf( stderr, "usage : fgets FILENAME\n" ); exit(1); } if( ( fp = fopen( argv[1], "r" ) ) == NULL ){ fprintf( stderr, "Cannot read %s\n", argv[1] ); exit(1); } while( fgets( buff, 10, fp ) ){ puts(buff); } exit(0); } さらにこれを gcc -g -O -o fgets fgets.c としてコンパイルして gdb で buff の中を見ます。 (gdb) break 18 Breakpoint 1 at 0x8048604: file fgets.c, line 18. (gdb) set arg fgets.c (gdb) run Starting program: /home/user/tmp/fgets fgets.c Breakpoint 1, main (argc=2, argv=0xbfbff740) at fgets.c:18 18 while( fgets( buff, 10, fp ) ){ (gdb) display buff 1: buff = "\201\203 (ゴミのため略) (gdb) n 19 puts(buff); 1: buff = "#include \000\005( 以下ゴミ ) (gdb) q こんな感じですね。 ># 改行なしだと bp==NULL になって fputs("\r\n") は実行されない。 これは違うと思います。bp == NULL なら単に \r\n を append するだけ で bp != NULL なら \n を \0 で潰してから、\r\n を append だと 思います。良く見てください、元のコードを *bp = '\0' となっています。 bp は index が拾って来た \n のあるところのポインタです。 |
|
ん? 失礼しました。 >># 改行なしだと bp==NULL になって fputs("\r\n") は実行されない。 >これは違うと思います。bp == NULL なら単に \r\n を append するだけ これ間違いですね。 >/* Put a <CR><NL> if a newline was removed from the buffer */ > if (bp) (void)fputs ("\r\n",p->output); bp == NULL だと確かに \r\n は付かないですね。 あと、 >となっているので (一部略)、fgets で得たデータに改行が >含まれない場合も、余計な改行は付加されないように思う 改行がつかないのは確かですね。 すると長い行の場合は次の行と連結するんですかね？ 大変失礼しました。 ただ指定のバッファサイズより一文字減るのは確かです。 なんかそれを言おうとして、論点ずれた挙げ句に大量のゴミみたいな メッセージを書き込んでしまい申し訳ありませんでした。 |