|
>>3811 68user >>3810 どら 富士通のコンパイラも入っていそうだという事が気になるのですが・・・ /usr/ccs/bin/ucbcc は Forte へのシンボリックリンクになってますか？ |
|
>>3812 zsh > 富士通のコンパイラも入っていそうだという事が気になるのですが・・・ /opt/FSUNf90/bin とかですか? Fortran のコンパイラと見たので 特に関係はないかと判断したのですが、どうなんでしょうね。 |
|
>>3811 68user お手数をおかけしてすいませんでした。 説明がわかりやすくてうれしかったです！！ PATHから/usr/ucb/ccを削除してみました。 そしたらいままでの警告文はなくなりました！！ありがとうございました。 しかし今までになかった警告文がでました。 ------------------------------------------------------------------- "ex3-1.c", 3 行目: 警告: 指令中に無効な空白文字があります ------------------------------------------------------------------- というものでした。今まではこんな警告もなかったし、3行目の空白も見当たりません。 この前載せたプログラムと同じものなのですが、＃includeと<stdio.h>の間の空白を消してみましたが同じでした。 またなにか問題なのでしょうか？他の例題に関してもまったくおんなじ警告文がでます… この形の警告文はたいていプログラムの問題だったので、プログラムをいじれば解決していたのですが… あと、もしよろしければ、gnuplotの使い方も教えていただければうれしいのですが… いろいろなホームページ上の例題をやってみたのですが、どれもうまくいかなくて… (特に、Cのプログラムをgnuplotに出力させたいのですが、gnuplot本体を置くディレクトリの場所とか、リンクの仕方とか…) もし時間があればでけっこうですので、少し教えていただけないでしょうか。よろしくお願いします。 |
|
>>3814 どら > "ex3-1.c", 3 行目: 警告: 指令中に無効な空白文字があります ソースを少しずつ削って、この警告が出る場所を特定してください。 問題の行を特定したけれども原因がわからない場合は、 % od -cx < ex3-1.c (最小限まで削ったファイル) として、変な文字が入っていないか確認してください。 > もしよろしければ、gnuplotの使い方も教えていただければうれしいのですが… 質問がある場合は http://www.hyuki.com/writing/techask.html を熟読した上でお願いします。ただしこの掲示板ではこれまで gnuplot の話題が 出たことはないので、 Gnuplot Q&A 掲示板 http://ayapin.film.s.dendai.ac.jp/cgi-bin/trees.cgi などで聞いた方がよいかもしれません。適切な答えをもらうにはどこで 質問するのが効果的かを見極めた上でどうぞ。 それはそれとして > Cのプログラムをgnuplotに出力させたいのですが やればできるでしょうけど、gnuplot の使い方としては適切ではないような気がします。 |
|
>>3815 68user >> "ex3-1.c", 3 行目: 警告: 指令中に無効な空白文字があります >ソースを少しずつ削って、この警告が出る場所を特定してください。 includeの文を1行全部削ってみた所、正常に動きました。 しかし、includeの文はプログラムには絶対必要なものと思っていたのですが… include文が無くても動くということはありえるのですか？ 下に正常に動いたプログラムを書きます。 ----------------------------------------------------------------------- /* 【例題3.1】 rei3_1 */ main() { int a,b; printf("異なる2つの整数を入力してください--->"); scanf("%d %d",&a,&b); if(a > b) printf("%d --- BIG\n",a); } ------------------------------------------------------------------------ |
|
>>3816 どら > includeの文を1行全部削ってみた所、正常に動きました。 逆です。動くように削っていくのではなく、動かない最小限の部分を 突き止め、その原因を探る方法を教えたつもりです。 つまり #include に原因があることがはっきりしたので、 % grep include ex3-1.c | od -cx として、なぜ警告が出るのかを調べるべきです。 > include文が無くても動くということはありえるのですか？ いろいろありますが、初心者のうちは include 文は書くべきと 思っておく方がよいでしょう。 |
|
>>3817 68user この前のプログラムから、#includeと<stdio.h>の間の空白を削除してみましたが、やはり同じ警告が出ました。 それで、そのプログラムにgrepをかけてみました。どこに空白文字があるのかがわかりません… あるとしても最後の“\d\n”ぐらいだと思うのですが、これは指令とは関係ないし、必要なもののはずなのですが… 下に“grep include ex3-1.c | od -cx”の結果を書きますので、終えてください。よろしくお願いします。 -------------------------------------------------------------------------- 0000000 # i n c l u d e < s t d i o . h 2369 6e63 6c75 6465 3c73 7464 696f 2e68 0000020 > \r \n 3e0d 0a00 0000023 ------------------------------------------------------------------------- |
|
>>3818 どら > 0000020 > \r \n 改行コードが CR LF になっています。UNIX の改行コードは LF です。 CR が空白文字扱いされているのでしょう。 とりあえず CR を削るだけなら tr コマンドが使えます。 http://x68000.startshop.co.jp/~68user/unix/pickup?tr Windows で作ったソースを ftp などで UNIX 上に持ってきて いるなら、アスキーモードで転送しましょう。ただし、全て UNIX 上で開発するのがスキルアップへの道だと思います。 |
|
>>3819 68user trコマンドで\r\nを\nに変えてみるとうまく作動しました。 ためしに、ftpでの転送もアスキーモードに変えると うまく作動しました。 原因が改行コードとは…気づきませんでした。 いろいろとありがとうございました。 |
|
初めて掲載しますが．．．．、 ソケット通信で、select()を使用した非同期通信をさせているのですが、 select()で検知した当該FDを(例としてFD=10と設定)recv()したら、 FD=10のrecv()返値が０(CLOSE？)となることがあります。 recv()返値が０の場合は、相手側がCLOSEしたものと認識はできるのですが、 疑問に思う動作でそれは、通常FD=10ならFD=10を介して送受信を行い、 select()監視しさせて、何かイヘ゛ント発生があればrecv()の動作に遷移する 動きを正常にしているのですが、突然的に（不規則と言うか、不確定と言うか） FD=10で送信後そのFD=10で受信するのに、select()からの戻りが数十秒 （ほとんど決まって、24〜25秒経って）経って検知され、recv()したら 返値が０であると言う動作があります。 このような動作になる原因が解らず、何かヒントや調べる手立てとかありませんか？？？。 （これって、ネットワーク障害／ネットワーク負荷とか、相手側マシンのＨＷ的障害 などの影響も考えられますか．．．．？？？） ．．．記述表現が的確でありませんが、ご了承ください。 |
|
いまここのHTTPクライアントを参考にして POSTをCGIへ仲介するCGIを作っているのですがうまくいきません； GETのところを print SOCKET "POST / HTTP/1.0\r\n"; print SOCKET "Content-Length: $size\r\n"; print SOCKET "\r\n"; print SOCKET "$buffer\r\n"; として $buffer = $ENV{ 'QUERY_STRING' }; $size = length $buffer; を追加してみたのですが・・・。お知恵を拝借できませんでしょうか？ |
|
>>3821 マツマツ > FD=10で送信後そのFD=10で受信するのに、select()からの戻りが数十秒 > （ほとんど決まって、24〜25秒経って）経って検知され、recv()したら > 返値が０であると言う動作があります。 よく理解できませんが、 1. send し、select で待つ。 2. 相手側はデータを受信後、すぐに close しているはず。 3. ところが select で 24〜25 秒待たされ、その後に読み込み可能になる。 4. recv すると 0 が返ってくる。 ということであれば、 a. ネットワークの質が悪く、TCP の再送タイマが働いている b. 2 で相手が 24〜25 秒かけて何かを処理してから close している くらいしか思いつきませんでした。パケットダンプしてみては。 >>3822 ユウキ そんな複雑なプログラムを書くのはやめて、まずは単純に POST する プログラムを書くべきでしょう。もし、そういうプログラムは既に作成済 ということであれば、うまくいく場合とうまくいかない場合のリクエストを 見比べればわかるでしょう。 あと、質問をする前に http://x68000.startshop.co.jp/~68user/cgi-bin/wwwboard.cgi?howtouse を読んでください＞質問者の方々 自分の使っている環境すら書かない人、回答してもわかったのかどうか返事さえ 書かない人が多くて、少々うんざりです。 |
|
申し訳ないです；少し安易に書き込んでしまいました。。。 単純にPOSTしてみます。深夜なのに申しわけなかったッス |
|
●コメント／アドバイスの程ありがとうございます。 （個人的に多忙な面もあり、有意な内容が書かれていることに対して、 返事が遅れた点は、お許しください） 後追いの記載ですいませんが、使用しているマシンはSUNのSC2000 （OS:Solaris2.4）と、SVR4ベースOSを使ったマシン（ここでは相手側） です。(LANのスペックは10BASE) ＜＝両者とも今ではかなり古いものですが．．．。 またあえて言わしていただきますと、下記の3，4が発生するのは SVR4ベースOSを使ったマシン側です。 > FD=10で送信後そのFD=10で受信するのに、select()からの戻りが数十秒 > （ほとんど決まって、24〜25秒経って）経って検知され、recv()したら > 返値が０であると言う動作があります。 よく理解できませんが、 1. send し、select で待つ。 2. 相手側はデータを受信後、すぐに close しているはず。 3. ところが select で 24〜25 秒待たされ、その後に読み込み可能になる。 4. recv すると 0 が返ってくる。 ということであれば、 a. ネットワークの質が悪く、TCP の再送タイマが働いている b. 2 で相手が 24〜25 秒かけて何かを処理してから close している くらいしか思いつきませんでした。パケットダンプしてみては。 ●まずは、LANアナライザーを噛まして見たいと思います。 ちなみにTCPの再送タイマってものが働いている場合、そのタイマは 24〜25秒の値なのでしょうか。 >>3822 ユウキ そんな複雑なプログラムを書くのはやめて、まずは単純に POST する プログラムを書くべきでしょう。もし、そういうプログラムは既に作成済 ということであれば、うまくいく場合とうまくいかない場合のリクエストを 見比べればわかるでしょう。 ●そうですね。（基本的なことから行うべきですね） |
|
>>3825 マツマツ > ちなみにTCPの再送タイマってものが働いている場合、そのタイマは > 24〜25秒の値なのでしょうか。 「詳解 TCP/IP Vol.1」によれば、RTT (往復時間) がほぼ 0 な LAN 上では、 再送間隔は 1秒・3秒・6秒・12秒・24秒… で、これを最初の送信からの経過時間で表すと 1秒・4秒・10秒・22秒・46秒… だそうです。 ただし RTT にそれなりの時間がかかる場合は、上記の通りには なりません (計算式が難しくてよくわかりませんが)。 なお、上記の事柄が Solaris 2.4 や、同時代の SVR4 にも当て はまるかどうかはわかりません。 |
|
> ちなみにTCPの再送タイマってものが働いている場合、そのタイマは > 24〜25秒の値なのでしょうか。 「詳解 TCP/IP Vol.1」によれば、RTT (往復時間) がほぼ 0 な LAN 上では、 再送間隔は 1秒・3秒・6秒・12秒・24秒… で、これを最初の送信からの経過時間で表すと 1秒・4秒・10秒・22秒・46秒… だそうです。 ●ありがとうございます。 （TCP/IPプロトコルについて、技術的な専門知識が分っていないため、 今後は勉強したいと思います。） で、少々また不仕付けなお話ですみませんが、再送タイマが発生していると した場合に、その原因／要因には、何があるでしょうか。 ”ネットワークの質が悪く、TCP の再送タイマが働いている” の部分で気になり、どちらかのマシンのＨＷ不調（LAN・I/Fカードや CPUボード等）とか、LANケーブル、HUB、トランシーバなどの 不調の影響で発生することとか考えられるでしょうか？。 （パケットトレースで確認することは必要なのですが、発生していると 分った時の発生原因を特定する上で、まず想定できる可能性のものがあれば と思った次第からです） （HW回りを疑って見るべきかどうか、何とも言えないのですが．．．） ただし RTT にそれなりの時間がかかる場合は、上記の通りには なりません (計算式が難しくてよくわかりませんが)。 なお、上記の事柄が Solaris 2.4 や、同時代の SVR4 にも当て はまるかどうかはわかりません。 |