サービス一覧
レンタルサーバー
ドメイン取得
SSL証明書

メンバーメニュー

ようこそ、ゲストさん

■ トップ > カテゴリ一覧 > 各種プラン > 簡単なテキストファイルの書き込みだけですが、動きません。

質問

  • ライト

    簡単なテキストファイルの書き込みだけですが、動きません。
  • 本文：

    #!/usr/bin/perl --


    print "Content-type: text/html; charset=UTF-8\n\n";

    #
    open(IN, "counter.txt");
    $count = <IN>;
    close(IN);

    #
    $count++;

    #
    open(OUT, "> counter.txt");
    print OUT $count;
    close(OUT);

    print <<EOL;
    <html>
    <body>
    <p>あなたは $count 人目のお客様です</p>
    </body>
    </html>
    EOL

    さっきの回答でソースと書いてあったのでソースを出しました。ただソースはgeoで動くので、全く問題ないと思います。

    このソース　counter.cgi　のパーミッションは755で
    counter.txt　のパーミッションは666です。

    Windows Serverのほうが手間が掛からない分いいですね。

  • 緊急度：通常投稿者：blueseabluemoonさん投稿時間：2018/10/09 02:56
質問に対する回答は締め切られました

回答 No.7625

  • この回答がベストアンサーです

  • 本文：

    > Shift-Jisになってしまいます。UTF-8にしてもです。LFはちゃんとなってますが、これが原因の可能性があります。

    ファイルの最後に、改行がないのが原因。


    % od -c counter.txt | tail -4
    0000600 ** ** お ** ** 客 ** ** 様 ** ** で ** ** す **
    0000620 ** < / p > \n < / b o d y > \n < /
    0000640 h t m l > \n E O L
    0000651

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 12:29
質問者からのコメント

そんなの知らないよ、後から、perlのexeをコンパイルして、その理屈付けたのでは?
最後にリターンが無いとか、何それ、何処の時代、でもリターンを全部入れたハズなんだけど、コピペするときに間違えたか?
くだらなすぎる・・・こんな低次元の仕様、とても耐えられない。
それで今度はBBS4.cgiが動かせない。
動かすプログラムが限定されてるとか?ここまで考える必要はない?

回答 No.7618

  • 本文：

    > Windows Serverのほうが手間が掛からない分いいですね。

    まあ、あなたが unix の約束事を守らないかぎり、perlで書こうが、php や ruby python で書こうが、一生動かないですよ。


    テキストファイルを実行ファイルとして扱いたいときに、ファイルの先頭の2バイトが 2321(16進) (ASCIIだと、#! )でないといけないのは、unix の約束事で、

    https://ja.wikipedia.org/wiki/マジックナンバー_(フォーマット識別子)

    BOM付のファイルだと、この約束事が守れないので、テキストファイルでなく、binaryファイルだと解釈されるせい。


    スクリプトファイルが、# で始まるのは、単に shell でコメント記号だというだけの理由ではありません。

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 04:44
質問者からのコメント

約束事ですか?　
一応「#!」を外してみましたが動きません。
偉そうな事を諭して、全く回答になってないですね。ゴミ、クズ、死ね、タコ w
と軽くジャブを入れておいて、怒んないでね。w
シェアウェアのテキストエディッタで書いて、FTPで上げてみます。
Web上のメモボックスの入力にリターンキーの動作に不具合があるので、LFがちゃんとしてない可能性を考えました。

回答 No.7619

  • 本文：

    古い話だけれど、昔、ロータスの表計算ソフトと、マイクロソフトの表計算ソフトが市場を争っていたときに、マイクロソフトがWindows上で、ロータス123が動かなくなるようにするために、123が使っていた拡張子を、windowsの予約拡張子に変更して、ロータスの使っていた拡張子では、123が動かなくなるようにした、という話もありますね。

    Windowsのメモ帳が、BOMをつけてテキストファイルを作成するのもWindows標準のエディタで作ったファイルが、unix上では動かなくなるようにするための、マイクロソフトの陰謀であって、
    >Windows Serverのほうが手間が掛からない分いいですね。
    まんまと、その策略に乗っかってしまっただけ。

    そんなにwindowsがいいなら、aspが動くサーバーを借りればいいのでは？


    # それから、同じ話題で、いくつものスレッドをたてるのは、止めたほうがいいですよ。

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 05:25
質問者からのコメント

ロータスどうしてしまったのでしょうかね?　いいソフトでしたよね。今はEXCELが主流ですが、

回答 No.7620

  • 本文：

    > 一応「#!」を外してみましたが動きません。

    馬鹿か？
    「#!」をいれるのが、unixの約束事だといっているのに。

    BOMをいれると、先頭の2バイトが、efbb になって 2321でなくなるから動かないんだよ。

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 05:59
質問者からのコメント

BOM
EF BB BF という３バイトのバイナリデータ?なんで見えもしないのに解るのですか?こんな仕様、頭オカシイというか、手間を掛けさせて時間を泥棒するのが目的?

#!を入れるのがUNIXの約束事?　だから初めから入ってますよね!
それをわざわざ説明する意味は?

回答 No.7621

  • 本文：

    > EF BB BF という３バイトのバイナリデータ?なんで見えもしないのに解るのですか?

    見えないから、素人はよく躓くのでね。

    最初から、

    > 〇 counter.cgi は、ちゃんと BOM無しのUTF8 で保存していますか？
    > TeraPadのような高機能なものを使用すると、改行コードも文字コードセットも、変換したり指定して保存したりすることが可能です。

    と書いているし、

    >ファイルを保存するときに、BOM付で保存しているせいか、パーミッションが違うせい。
    >(Windowsのメモ帳以外のエディタを使った方がいい)

    メモ帳は勝手にBOMをつけるからやめたほうがいいといっているのに、

    それを試しもせずに、
    > BOMなんて付けてません。
    みたいな頓珍漢な回答をしているし、

    > こんな仕様、頭オカシイというか、手間を掛けさせて時間を泥棒するのが目的?

    バイナリファイルとテキストファイルを同じ仕組みで動かすための仕組みですよ。
    https://ja.wikipedia.org/wiki/マジックナンバー_(フォーマット識別子)
    を読み直してみて、他によい方法があるなら提案してみれば？


    > #!を入れるのがUNIXの約束事?　だから初めから入ってますよね!
    それをわざわざ説明する意味は?

    〇最初の2バイトに入っていないと、マジックナンバーとして機能しない。
    〇BOMが入っていると、4〜5バイト目に移動するので、単なるコメントにしかならない。
    〇単なるコメントだと、それに続く /usr/bin/perl もコメントの一部なので無視される。
    〇2行目以降が、shell(=/bin/sh)のスクリプトと解釈される。
    〇shの文法に違反しているからエラーになる。


    ちなみに、TeraPadなら、保存するときの文字コードは、UTF-8 でなく、UTF-8N がBOMが付かない方。

    BOMはその名前の ByteOrderMarkが示すように、複数バイトのエンコーディングをする際に高位バイト-低位バイトの順に記録されているか、低位バイト-高位バイトの順に記録されているかを区別するための印であって、本来1バイトのエンコーディング体系のUTF-8 では不要なもの。
    UTF-8に付加しても規格上は間違いではないが、普通は付加しない。

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 07:04
質問者からのコメント

BOMのチェックを外してもダメでした。
始めっからBOMのチェック付いてませんでした。

回答 No.7622

  • 本文：


    > BOMのチェックを外してもダメでした。
    > 始めっからBOMのチェック付いてませんでした。

    判定してあげるから、ファイル名を counter.cgi から、counter.txt に変更してアップロードしてごらん。

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 08:39
質問者からのコメント

counter.txt　にしました。
もとあった　counter.txt　番号を記入するファイルは　counter2.txt　になってます。

ちなみに　コードを　UTF-8　にしたのは　秀丸の最新版を使いました。

番号を入れるファイル　counter.txt　現在　counter2.txt　は　秀丸で上書きしてもどうしても、Shift-Jisになってしまいます。UTF-8にしてもです。LFはちゃんとなってますが、これが原因の可能性があります。

回答 No.7626

  • 本文：

    > そんなの知らないよ、後から、perlのexeをコンパイルして、その理屈付けたのでは?
    > 最後にリターンが無いとか、何それ、何処の時代、

    ま、多分、正確には、「ファイルの終りに改行がない」が原因ではなくて、Here Document の識別子(ここではEOL)が、改行で終わっていないことが原因だから、NetOwlのサーバーの問題ではなくて、Perlの仕様の問題。

    どこのサーバーにいっても同じファイルならエラーになるのが正しい挙動。

    それであなたがperlを嫌いになっても、それはあなたの勝手だけれど。


    > でもリターンを全部入れたハズなんだけど、コピペするときに間違えたか?

    でしょ。
    秀丸なら、改行とかファイルの終りとかは、目に見える形で表示できるのでは？

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 14:14
質問者からのコメント

>どこのサーバーにいっても同じファイルならエラーになるのが正しい挙動。
ジオシティーズでは、これも問題なく動いていた。
>秀丸なら、改行とかファイルの終りとかは、目に見える形で表示できるのでは？
秀丸をダウンロードしたのは、多分Webブラウザで改行を入れてた後、そもそもファイル終わりの改行なんてあんまり気にしてない。

やっぱりファイルごとにアドミンじゃなくてUNIXのSUか?何かが、実行権限を与えてないのでは?
counter.cgiを聞かれたから、counter.cgi　と　counter.txt　に権限与えたのでは、
counter.cgi　の　counter.txtを見に行く所に　サブフォルダの/cgi_private/counter.txt　に指定したら、数字が増えない、書き込みの権限が無いみたい、もちろんトップフォルダのcounter.txtは数字が増える。

すげー権限まわり怪しい。

なんでジオシティーズでは簡単に動くのに、ここではこんなに大変なの?
他のサーバーでは簡単でもこのサーバーはかなり大変ですと書いてくれればいいと思う。こんな事ならここを選ばなかったよ。

回答 No.7628

  • 本文：

    ＞なんでジオシティーズでは簡単に動くのに、ここではこんなに大変なの?

    『同じファイル』といいながら、実は「コピーペーストしたファイル」だって自分で言っているではないですか・・・
    「コピーペーストしたときに選択する範囲を間違えた」とか、コピーペーストの段階で同じファイルができると思っているなんて、なんておめでたいんだ・・・

    ネットオウルにアップロードしたファイルをそのまま(コピーペーストではなく)FTPでジオシティにアップロードしてみてごらん。

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 14:51
質問者からのコメント

>「コピーペーストしたときに選択する範囲を間違えた」とか、コピーペーストの段階で>同じファイルができると思っているなんて、なんておめでたいんだ・・・
　同じファイルができると思ってます。選択する範囲の間違いなんて殆どないですよ。

>ネットオウルにアップロードしたファイルをそのまま(コピーペーストではなく)FTPで
>ジオシティにアップロードしてみてごらん。
どんな意味があるのですか? UTF-8だから文字化けですかね。

回答 No.7629

  • 本文：

    ちなみに、Perlの文法では、here document の識別子は、次のように書かれている。

    http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Operators

    If the construct is a here-doc, the ending delimiter is a line that has a terminating string as the content. Therefore <<EOF is terminated by EOF immediately followed by "\n" and starting from the first column of the terminating line. When searching for the terminating line of a here-doc, nothing is skipped. In other words, lines after the here-doc syntax are compared with the terminating string line by line.

    抄訳すると、「<<EOF を使ったときは、終わりの EOF の次の文字は\n でなければいけない」んですよ。
    そうなっていない場合は、perlとして文法的に間違っているので、エラーとなって当然。エラーにならない方がむしろおかしい。

  • 投稿者：ジョバンニさん 投稿時間：2018/10/09 15:27
質問者からのコメント

perlは知らないです。文法のうんちく出されても、はいそうですか?としか、

回答 No.7631

  • 本文：

    > >「コピーペーストしたときに選択する範囲を間違えた」とか、コピーペーストの段階で
    > > 同じファイルができると思っているなんて、なんておめでたいんだ・・・
    > 　同じファイルができると思ってます。選択する範囲の間違いなんて殆どないですよ。

    すべて選択してコピー＆ペーストするだけでしょうから、
    選択する範囲を間違えるということまでは起こらないでしょうけれど、

    いわゆるコピペだと、見た目には同じテキストとして読めます。
    けれども、改行や空白文字などは、秀丸エディタとかの特別な環境でないと判別困難です。
    だから、ファイルの末尾の改行の有無が変わってしまうということも起こりうるのです。

    また、コピペして別のファイルを保存するとなると、その保存したときの環境で、同じファイルにならない可能性があります。

    手元の環境がWindowsではなくてUNIX系風OSだったならば、 diff かなんかすれば違いがすぐ判るんですけれど。

    ちなみに、元はたとい同じファイルであったとしても、
    FTPで転送するといった過程で自動変換されるということも起こりるので、完璧に同じファイルになるとは限りませんけれども。

    だから、手元に本番環境のWindows Serverがあって、そこに直に触れられるのであれば、たしかに手間はかからないのだろうと思います。

    完璧ではないものの、同じかどうかを判断する一つの手段としては、
    ファイルのサイズが1バイト単位で同じかどうかを確認する手はありますね。


    あと、Perl でプログラムを書くつもりならば、たといWindowsであったとしても、
    Perlの仕様には従う必要があります。
    ただの薀蓄ではなくて、実際にこうしてトラブルが起こっている話ですし。
    言語に対して敬意すらもてないようであれば、その言語を習得していけないのではないでしょうか。

    結局は最終的には、自宅に常時接続のWindows Serverを設置したら全部解決するかもしれません。
    そうでなければ、OSや設定の相異や、データ転送の問題や、好きなプログラミング言語が使えない（コンパイラ/インタプリタとかが入っていない）ということがあっても、しかたありません。

  • 投稿者：ayaguchiさん 投稿時間：2018/10/09 16:37
この回答に対してコメントする