ファイルの更新とVimエディタ
ローカルで編集したファイルをアップロードしてからエラーに気づいても元に戻せないことがある。編集中のままエディタを開いていれば巻き戻してアップしなおしもできるが閉じてしまえばそれも叶わない。この頃は簡単な編集であればFTPクライアントの〝WinSCP〟上のエディタを使ってリモートのファイルを直接いじっている。動作に不具合がなければ編集したリモートファイルをダウンロードしている。バックアップの取り方が下手というか要領を得ない。なにかセオリーがあるのだろうけどその知識が無い。

パソコンで使っているエディタは窓の杜で落としたVimだ。高機能な〝普通の〟エディタだろうと高を括っていたらとんでもなかった。何にもできなくて手も足も出せない。難しい。初心者モードでようやく使えた。設定を変えるのも何日かかかったくらい。とにかく難しい。それでも乗りかかった船と思い、必死にしがみついて使っている。Vimの他に〝Crescent Eve〟というHTMLに特化したエディタもインストールしてあるが、こちらは文字化けをおこすので保留にしてある。私が文字コードをきちんと把握して正しい設定をすれば使いこなせるのだろう。今はそれができない。

Vimはあまりにも難しいのでやることなすこと失敗の連続だが、失敗の数が多いほどひとつひとつできることが増えていく。ウェブで初心者向けの解説を探してもプログラム知識があることが前提としての解説なので、そこに明るくない私にとってはほとんど解らない。初心者向けの設定情報があっても、その設定を変更する方法を知らないのだ。そもそも設定ファイルに文字を入力するのも保存するのもできなかった。そのうち管理者権限で設定ファイルを開くことと設定を入力する画面の見方がわかった。やっと設定を変えることができた。設定を変えると言ってもコード(コマンド?)の入力なので慣れない。

そうこうするうちにぼんやりと仕組みを捉えつつある。今使っているノートパソコンにはマウスが無いので、このVimに慣れるのが良いような気がする。うまく慣れるのか不安であるが。

話を元に戻すと、Vimでファイル編集するとundoファイルとバックアップファイルが自動で生成される。このファイルがあれば編集終了後も後々さかのぼることができるんだそうな。ただ、その生成先ディレクトリがファイルと同じ階層なのだ。フォルダに10のファイルがあれば、そこにundoとバックアップファイルがそれぞれ10ずつ合計20のファイルが増えてしまう。FTPクライアントの画面が大変なことになってしまう。拡張子をまとめて隠しファイルにしようとしてもできず。これに困っている人が世の中にいるということは拡張子ごとに隠しファイルにできないのかもしれない。これらの保存先を指定する設定があると知って試してみたが上記の通りえらい大変だった。設定変更のコマンドを間違えてばかりで四苦八苦してやっと設定変更を通すことができた。…のはずだが、保存先に指定したフォルダにファイルが生成されていない。ホームページに使うファイルと同じディレクトリには生成されなくなった。もやもやするけどひとまずよし。
jcodeモジュールとSUDO
■人工無能
前回変更したjcode周りの箇所は不具合が出ない様子なので同じコードをローカルで試してみたら500エラーだの何だの。デバッグ(というのか?)をすると「Perlにjcode.pmモジュールがインストールされてない」と表示される。CGIと同じフォルダの中にjcode.pmは入れてある。調べてみると〝モジュール〟のインストールをしなければならないらしい。
参考:「Perlのモジュールインストール方法

記事に従って進めると今度は「SUDOがオンになってない」という。Windows側の問題らしい。
参考:「このコンピュータではSUDOが無効になっています。

念のために管理者権限でPerlコマンドラインを起動しなおして進めた。途中(恐らくインストールが完了した時点で)CPANという命令?から抜け出せなくなった。CGIのデバッグをしたくてもどうにもならないのでそのままウィンドウを閉じて開きなおし、どうにかこうにかjcodeモジュールのインストールを完了できた。モジュールのインストールを促すメッセージは表示されなくなった。SUDOはまたオフに戻しておいた。
jcode.plのこと
動かない人工無能少女まりちゃんは500エラーが出ていた。この原因はjcode.plの古さにあった。見様見真似でこれをjacode.plに変更することで500エラーは起こらなくなった。欲をだしてjacode.pmというのに挑戦したがこれもまたエラーなのでひとまずjacode.plにとどめておく。

それからコードの中のjcodeにまつわる箇所にも難があるらしい。
参考:KENT-WEB サポートコーナー過去ログ〔0301〕

ただ、ここを変更してもしなくても文字化けはしていないので動かない直接の原因かどうかはまだ分からない。今の不具合は名前欄に入力してボタンを押しても会話(チャット)が始まらない状況。チャットに入室できないというか。過去ログは表示されている。どこが悪いんでしょうか…。相変わらず文法エラーは無し。


※記事に訂正箇所のコードを挿入すると投稿時に403エラーになってしまう。このブログにはWYSIWYG(ウィジウィグ)エディター「NicEdit日本語版」が備わっていてコードを入力して投稿できるはずなのだがうまく作用していない。これも課題。

jcodeとJcodeの大文字小文字のミスを訂正した。名前を入力するとログに現われるが会話の入力フォームが表示されない。しかし、まりちゃんが「何か入力してみてね」を返してくれるようになった。
Apache2.4とStrawberry Perl
動かない人工無能をなんとか自分で直したい。イチから勉強して自作するか、それとも原因を突き止めて修正するか。いろいろ調べた。CGIの不具合を直すには「Apacheの環境があるならば」「Perlが使えるなら」…そう書いてあることが常だ。物は試し、無知の怖いもの知らずでApacheとPerlをインストールすることに。

CGIを触るならPerlかなという発想からまず先にPerlをインストール。Strawberry Perlというのを選んだ。動かないCGIのデバッグについて書かれた記事を参考に触るとそれなりに反応が返ってくる。面白い。でもコードの表示だけで実動している様子がわからない。サーバをインストールする必要があるようだ。Apache2.4をインストール。ここからが大変だった。

CGIファイルの冒頭に記載するPerlへのパスがわからない。ひとまず数行程度のCGIファイルを作ってそれで練習することにした。インストールしたPerl.exeのパスC://云々をコピーして使うと表示される。見慣れたCGIは#! usr/local/bin/perl だ。自分もそうしたい。「てがろぐ」CGIをローカルPCで動かす方法という記事を読むと「AN HTTPD」というサーバを使うのが易しくできそうだ。〝玄人志向〟なApacheよりもやりいやすいらしい。これもインストールした。日本語で操作しやすそう。でも世の中のCGIに関する情報は圧倒的にApacheなので元通りApacheを使うことにした。

とにかくPerlへのパスが通らない。ファイルの場所が悪いのかスラッシュとバックスラッシュと¥マークの区別があるのか。Apacheのフォルダの中にルートディレクトリを指定したのがマズいのか。何もわからない。usr/local/bin/perlはどこを指すのか。localhost/test.cgiを参照しても403になる。自分で書いたCGIがダメなのか。動かないCGIを置いてみても403。四苦八苦してC:にusr/local/binを作ってそこにPerl.exeを置いたらやっとパスが通った。表示された。感動。これだけで一両日くらい時間を費やしてしまった。やっとPerlのパスが通って動かないCGIが500エラーに。思わず喜んでしまった。ちゃんとサーバが仕事している!レンタルサーバと同じエラーが返ってくる!エラー表示に喜んだのはこれが初めての経験だ。嬉しい。
ロリポップが昔のままだった
20何年振りにレンタルサーバを借りることになりどこのサービスにするか悩みそうでほとんど悩まずにロリポップを選んだ。利用していたことがあり馴染みがあったからだ。今やロリポップのサイトはすっかり様変わりして昔のキュートでポップなイメージは皆無。ビジネス向けの印象が強く少し寂しい感じもある。

アカウントを作り直してログインしたら、なんと、中身の外観は20年前のままのデザインなのだ。懐かしいやら驚くやら。FTP画面はロリポおじさんがいるではないか。これはどうしてだろう。デザインを変えるのは難しいだろうか。それとも何か思い入れがあってそのままなんだろうか。ロリポおじさんを見ていると若かりし頃のあれこれを思い出してしんみりしてしまう。あの頃楽しかったなあ。

altalt

ところで今回ロリポップを再開して昔と同じ苦労をしている。CGIのパーミッション設定に癖があってスタンダードな設定ではうまくいかない。ここで躓いて進めなくなった記憶が蘇る。今は懐かしい個人ホームページを作りたいので昔以上にCGIを色々使ってみたい。このブログもCGIを設置したものでパーミッション設定の間違いと思われるエラーが一部ある。管理画面からCSSファイルの編集をして保存すると403エラーになってしまう。ファイルを直接編集することで回避できているが、どうせなら管理画面から正しく扱いたい。


【追記】ロリポップのユーザページからWAF設定を切ったところ403エラーは解消された。このケースはCGIファイルに問題が含まれるそうで管理者自身で修正しWAFを有効にするのが推奨されるとのこと。
ロリポップ参考ページ「PHPやCGIでプログラムの記述変更をしたところ403errorが表示されます」
【追記】このエラーは管理画面上で編集したHTMLファイルを保存するときに起こっている。編集内容によってエラーにならないので、コードの何かがひっかかるのかもしれない。同じエラーになっていたCSSファイルの編集はうまくいくようになった。原因がわからない。

- CafeLog -