|
おひさしぶりです。困ったときばっかり登場してすみません。 たぶんあけましておめでとうございます。 ここ５年ぐらいメンテしてる CGI なんですが、 根本的な改革を迫られました。 A.cgi が生成するページにおいて、 ボタンを押したら（可変パラメータ付きで） B.cgi が生成するページに進み、 リンクを押したら（可変パラメータなしで） C.cgi が生成するページに進むという実装になっています。 ところが、ここで C.cgi にも A.cgi で選択入力する可変パラメータを渡さなければ ならなくなったのです。 A、B、C 非常に肥大化していて、安易な解決法が欲しい状況です。 CGI のみで解決できればうれしいですが、 場合によっては JavaScript でもかまいません。 なにかあればご教示願えれば幸甚です。よろしくお願いします。 |
|
>>3560 ふくし これを機にリファクタリングした方が、のちのち幸せになれると 思いますよ。 …というのは十分承知しておられると思うので、その場 しのぎな案を 2つばかり。 1. B.cgi で受けたパラメータを print qq(<input type=hidden name="param_from_a" value="$ENV{QUERY_STRING}">\n); などとまるごと C.cgi に渡す。 2. 隠しフレームを作っておいて、A.cgi で選択されたら onClick などでフォーム内容を隠しフレームに転記して おき、(B.cgi は無修正で) C.cgi がその隠しフレームを読む。 |
|
アクセスが遅くなり申し訳ありません。瀧上です。 丁寧なご回答ありがとうございます。 工程別のユーザの切り分けは私の方でも近い形で考えており、ご回答に近い形で定めようと思っています。→開発環境ではユーザを分けますが。 とりあえず考え方に大きなずれが無い事が判明してほっとしています。 ディレクトリですがConfの概念は無くこれはこちらを参考に構成を考えようと思います。CVSはシステム標準で構成管理ツールとして使用することが決定しています。デバッグモードの考え方は、色濃く方式に出そうです(^^;) ところで申し訳ないのですがもう少し勉強させてもらいたい事がありまして、お言葉に甘えていくつか質問させてください。 →たとえばログイン時に「.cshrc」から「環境変数設定ファイル」をSourceしたとして、この時「環境変数設定ファイル」から設定した環境変数は、サーバDOWNかそれを書き換えるまで確実に保証されるのでしょうか？ →LIBがmakeInstall時に取り込まれるものだとしたら、 動的なライブラリはUNIXにおける開発ではあまり使用しないものなのですしょうか？システム共通部品等は動的ライブラリから呼び出すのが一般的かなと思っているのですが。 /COMMON/bin/xxxxx.so←拡張子も「.so」一般的なのか疑問ですが、 dllでは無いと思うので。。。 もしくは実行ファイルとしてbinに持つ？ |
|
>>3651 68user すいません、題意を間違えて伝えたかもしれません。 これでよかったです。 A.CGI start_form(action="B.CGI"); フォーム要素１; end_form; start_form(action="C.CGI"); フォーム要素２; end_form; 要は B と C に別の可変要素を渡すのなら、これでできたんですね。 昨日それでできるんじゃないカナと思ってたんですが、 コードにバグをつくっていました。 なお、ボタンを submit にしないで、name をつけ、 name を JavaScript で読み取って切り分ける、という方法も あるようです。これならフォーム要素を共有できるな。 http://webmaster.hatena.ne.jp/1069376628 ★ 事情を説明すると、５年越しということでおわかりいただけると 思いますが、FileMaker で作っていた経理システムが 2000 年問題で 止まる（私製のテンプレートがダサくて）という話があり、 その時個人的に見積書を CGI で出していたことがバレ、 2000 年の 3 月にはちゃんとした業者ウェアを入れるから それまでそれっぽいものを動かしてよ、と言われました。 で、2000 年の 3 月に、業者ウェアの日本語対応ができないと分かり （ガイシ系なんで・・・） その年いっぱい動かすことになりました。 以下、同じことが 200年、2001年、2002年、2003年に起こりました。 いよいよ今年の５月にこのシステムが正式に引退させることが 決定した（・・・）のですが、その前にどうしても大きな山を 乗り越えるためにプログラムを改造することになったのです。 でも「どうせ５月に引退すると決まっているシステムに大金を 投じるわけにはいかない」ので、それだけに長い時間を避けないんです。 人生いろいろですね：） |
|
教えてください。 指定したポートを開放するために必要なinetd.confの設定方法を教えてください。また、他に必要な設定が必要でしょうか。 ご教授お願い致します。 |
|
>>3562 瀧上 > たとえばログイン時に「.cshrc」から「環境変数設定ファイル」を > Sourceしたとして、この時「環境変数設定ファイル」から設定した > 環境変数は、サーバDOWNかそれを書き換えるまで確実に保証される > のでしょうか？ setenv で更新したら変更されます。.cshrc を更新しても、 明示的に source したり、ログインしなおさないと反映 されません。 よって、プログラムの先頭で source するか、cron であれば * * * * * . /home/hoge/env.sh && /home/hoge/bin/foo としておくのがよいでしょう (JP1 でも何かしら環境変数を 指定するような設定があるのではないかと想像します)。 > LIBがmakeInstall時に取り込まれるものだとしたら、 そういう意図ではなく、実行時に必要ないろいろなファイルの 置き場所、として書きました。 もし動的ライブラリを使うなら lib/ に置くことになる でしょうね。 でなくて、静的にリンクするなら、ライブラリは src/ の 下だけ置いて、アプリのmake install 時にリンクしmasu. ライブラリ自体は lib/ に make install しません (実行時 には必要ないので)。 で、それはそれとして > 動的なライブラリはUNIXにおける開発ではあまり使用しない > ものなのですしょうか？ についてですが、わたしの場合は静的にリンクする方法を 好みますが、別に動的リンクがダメと言うほどではないです。 業務系では多少のメモリ使用量の多寡ははどうでもよいので、 構成管理のやりやすさだけを考慮すれば構わないと考えます。 で、例えば、 1. ライブラリ関数 func をプログラム A・B・C が使用している。 2. プログラム A に不具合が発生。すぐに修正版をリリース しなければならない。 3. 原因は func であることが判明。しかし func の呼び出し方の 違いから、プログラム B・C ではこの現象は発生しない。 という状況を考えます。 静的にリンクしている場合、もし人的リソースに余裕があり、 func 修正時にプログラム A・B・C のテストをすることができる なら、修正版 func のリリース時にプログラム A・B・C を再 コンパイルすることができます (これが最も望ましい)。 しかし、プログラム B・C をテストする余裕がない場合、 func を修正して再コンパイルし、プログラム A を再コンパイル とすることで、プログラム B・C に影響を与えず func を修正 するという選択肢をとることができます。 ただしこれは プログラム A が使用している func と、プログラム B・C が使用している func が異なる という管理しづらい状況になるため、次期リリース時に全てを 再コンパイルするまでの時間かせぎです。 つまり、静的リンクの場合、 目の前のリスクを少なくしたいなら → プログラム A のみを再コンパイル 構成を単純にしたいなら → プログラム A・B・C を再コンパイル と、状況に応じた選択が可能です。 しかし動的ライブラリだと、動的ライブラリを入れ替えて、 プログラム B・C に不具合が出るかもしれないリスクを負う という選択肢しかありません。 よって、わたしは静的にリンクする方を選びます。 ただし静的リンクの場合、再コンパイル忘れなどで各プログラムが 使用しているライブラリのバージョンが異なる、という状況が発生 する可能性がありますが、この対策として、定期リリース時に商用 環境の - 全ソース・全プログラムを削除 - 最新版のソースを全て再コンパイル - 全プログラムを make install とすれば OK でしょう (最上位ディレクトリで make && make install すれば全アプリ入れ替え完了)。 # 仮に動的リンクを選択したとしても、上記の「定期リリース # ごとに全部インストールしなおす」というやり方は強く # おすすめしておきます。 |
|
>>3564 たけ > 指定したポートを開放するために必要なinetd.confの > 設定方法を教えてください。 質問が曖昧すぎて答えられません。inetd のマニュアルと /etc/inetd.conf にある他の設定例を見てください。 それでもわからなければ、何がしたいのかを明記した上で 再度質問してください。 |
|
はじめまして。初心者ですが、コマンドはどこに打てばいいんですか？ |
|
以下のようなファイルからaddとmodとdelのerrrorがある行を 取り出したいのですが、 ------ ここから ----------- ---- server1 ---- add:yamada:success add:saito:error mod:yamamoto:success mod:ikeda:error del:yamaguchi:success del:butou:error ---- server2 ----- add:yamada:success add:saito:error mod:yamamoto:success mod:ikeda:error del:yamaguchi:success del:butou:error ------ ここまで ---------- grep -v "\-\-\-" ファイル名 | grep -v success で一応とりだせるのですが、改行の２行が含まれて しまいます。空改行を含まず１回の処理でやりたいのですが どうすればよいのですか。 |
|
>>3568 すすむ 環境を書き忘れました。 SunOSで、Bシェルです。 |
|
>>3568 すすむ errorを取り出したいなら素直に grep ":error" filename とすれば良いのでは？ まぁ名前にerrorが含まれる人がいると引っかかってしまうので 正規表現使うべきなんだろうけど。 |
|
>>3568 すすむ 賢いかはわかりませんが、 grep -v "\-----" ファイル名 | grep -v success | awk '{ if(NF != 0) print $0 }' でできませんか。 |
|
>>3568 すすむ 「success」と「error」と簡単に書きましたが、 成功の場合は、「success」で、失敗の場合は、エラーメッセージが でます。 「error」だけでは、引っ掛けられません。 |
|
>>3567 うこん あなたが置かれている状況がわからないので、回答できません。 >>3568 すすむ わたしなら egrep '^(add|mod|del):' | grep -v ':success$' とします。 |
|
>>3572 すすむ であれば、 egrep -v '^(-|$|.*:success$)' filename とか？ |
|
>>3573 68user >>3574 zsh zshさん、68userさん ありがとうございます。 egrepですか。 使用したことがないのですが、 「'^(-|$|.*:success$)' 」 の使い方につてい教えてください。 |
|
>>3561 68user > 1. B.cgi で受けたパラメータを > print qq(<input type=hidden name="param_from_a" > value="$ENV{QUERY_STRING}">\n); > などとまるごと C.cgi に渡す。 「などと」と書いてあるので, 細かいところは省略してあるのでしょうが このままの記述ですと, パラメータの区切りが「&」という前提にて パラメータの名前が「copy」や「reg」だった時に悲しい結果が待ってます。 理由はこのへん http://www.ne.jp/asahi/minazuki/bakera/html/opinion/ampersand |
|
>>3565 ご回答ありがとうございます。 ライブラリの考え方は参考になります。 要件が無ければ原則禁止にしてしまおうかななんて。。。検討中です。。 ところでshellでバッチを走らせる時はユーザ設定を行わないようにするのがいいのですね。UNIXの部屋にある↓を見て気づきました。 「#!/bin/csh -f というのをよく見かけるが、その場合ユーザ独自の ~/.cshrc は読まれないので、エイリアスやシェル変数は使用できなくなる。」 なので今回はshellの構成は下記の様にするつもりです。ご報告まで。。。 ---------------------------------- #!/bin/csh -f #------------------- #shell # #------------------- source COMMON.src #→システム共通のパス(oracle等)や文字指定(LANG等) source 環境.env #→システム共通環境変数設定等 処理・・・・ ----------------------- |
|
Makeの環境について教えて下さい。 現在下記のディレクトリを作成して開発環境としようと考えていました。 /src /* makefileとsrcを保管 */ /obj /* make時の中間ファイルを保管 */ /bin /* 実行ファイルを保管 */ するとあるガイドに「.oと.cを別ディレクトリに置くとmake時のタイムスタンプの比較が困難になるのでやめるべきだ」、と書いてありました。 「個々の依存関係をいちいち指定しなければならない。」ともあり、「いちいち」等と書かれると非常に非効率な事の様に感じるのですが。。。 「.cと.oは同一ディレクトリに持つ」が一般開発業務で用いられる主要な方式なのでしょうか？ 単体環境だと不特定多数の人間が多様なsrcファイルを作るのであまり余計なファイルを置いてごちゃごちゃさせたくないと言うのが理由で分けてるだけなので同一ディレクトリも特に問題は無いのですが。。。(消されても問題は無いファイルですし。。) 依存関係をmakefileに指定して別ディレクトリ管理と言うのはやらないのですかね？ |
|
No.3568さんに似たような質問なんですが、 ファイルが以下のようにあったとします。 _________________________________________ aaa bb ccc 02/22 ddd e1.3 fff _________________________________________ その時に、実行するたびにe1.3の数字をe1.4、e1.5と実行 するたびに数字を0.1ずつ変更したいんですがＣシェルで そのような事をしたいのですが、どうしたらいいのでしょうか。 ご教授お願いします。 |