|
こんにちは恵美です。 どうもありがとうです(^^)v すっかり解決して嬉しいです。 リファレンスはいまいちよくわかってないけど... 複数行で記述するのを1行でって思ってずっと悩んでいたんだけど、心の中を読まれちゃったかな... なんか、すごすぎるページなのでちょくちょく見に来ます。 おやすみなさい。 今日はありがとう(^^) |
|
はじめまして、瀧上と申します。 現在UNIX環境でのバッチ処理方式・環境設計を行っています。 開発経験はあるのですが、環境構築からやるのは初めてで頭を悩ましています。宜しければ下記の点についてご教授下さい。 デバッグメッセージの出力有無の切替について教えて下さい。 開発言語はCシェル＆Cです。 以前のプロジェクトではC言語におけるデバッグメッセージを出力するしないを、環境変数で設定してしました。おそらく、これを見る事によりデバッグメッセージ出力用の共通関数にデバッグのON/OFFを切り替えさせていたのだと思います。 もし、上記以外に一般的な(適切)な方法があるなら教えて下さい。 レベルの低い質問で申し訳ないのですが、よろしくお願い致します。 ※UNIXの環境構築や、ジョブスケジューラにおけるNET設計の参考となる URLをご存知であれば教えていただきたいです。 |
|
>>3555 瀧上 > 上記以外に一般的な(適切)な方法があるなら教えて下さい。 しょせん決め事なので、一般解はありませんが、 - コマンドオプション (--debug や -d など) を指定する - make debug で、デバッグ用バイナリを生成する - make install すると ~/bin/ に通常バイナリを、~/bin/debug/ にデバッグ用バイナリを格納する などの方法があります。 どれでもいいので、いずれかをプロジェクトのルールとして決定して おくのがよいでしょう。 わたしの場合、 「デバッグモードは開発時のためのモードではなく、通常運用時や 後々のバグ追及時にこそ有用なもの」 という考え方なので、わたしが好む方法は以下の通りです。 - デバッグモードを実装する。デバッグモードの場合、rollback するなどして、データを一切更新しないようにする (まわりの環境に 一切影響を与えない) - デバッグモードとは別に、冗長なメッセージを出すだけの冗長 モード (verbose モード) を実装する。冗長モードの場合は、 通常どおりデータを更新する。 - エラー発生に気づきやすいよう、ログに吐いたメッセージは 標準出力・標準エラー出力にも吐くようにする。 - オプションでデバッグモード・冗長モードを切り替えられること。 例えば --debug でデバッグモード、--verbose で冗長モード、など。 デバッグモードの場合、自動的に冗長モードも有効にするようにする。 コード例は以下の通り。 int debug_flg = 0; int verbose_flg = 0; for ( i=1 ; i<argc ; i++ ){ if ( strcmp(argv[i], "--debug") == 0 ){ debug_flg = 1; verbose_flg = 1; } if ( strcmp(argv[i], "--verbose") == 0 ){ verbose_flg = 1; } } /* こんな感じで各種情報を出力 */ verbose("ほげほげ foo=[%d]", foo); .... if ( debug_flg ){ EXEC SQL ROLLBACK RELEASE WORK; } else { EXEC SQL COMMIT RELEASE WORK; } void verbose(char *fmt, ... ){ va_list ap; char buf[8192]; /* verbose モードでなければ、何もしない */ if ( ! verbose_flg ){ return; } va_start(ap, fmt); vsnprintf(buf, sizeof(buf-1), fmt, ap); va_end(ap); fprintf(stderr, "debug: %s", buf); } 使い方としては、 - 単に詳細なメッセージを表示したい場合は冗長モードを使う。 - まわりの環境に影響を与えず、とりあえずうまく動くか確かめたい 場合はデバッグモードを使う。 となります。 > UNIXの環境構築 UNIX の環境構築と言っても範囲が広すぎるので、なんともいえません。 > ジョブスケジューラにおけるNET設計 これは何でしょうか? JP1 とかの話? |
|
大変参考になります。 方式だけでなく、考え方とコードまで載せていただいたのは恐縮です。 参考例を深慮して方式を定めます。 ありがとうございました。 > UNIXの環境構築 UNIX の環境構築と言っても範囲が広すぎるので、なんともいえません。 →そうですね、すみません、主にUNIX環境でのバッチ処理におけるShellの置き場所や構成の最適な方式を調査できるHPを探していました。「コンパイラ等、ツールの環境(変数)設定ファイルは全て別で持つのが好ましいのか」、、とか、「バッチ処理起動shellでsourceする環境設定ファイルにディレクトリとOracleSIDを考えているが、これが最適なのか？」等です。。。開発、本番時に必要な要件を洗い出していけばおのずと出てくると思うので、考えてみます。 開発とUNIXでの開発経験が乏しいので、自分の知っている方式を、プロジェクトの標準として使っていいのか不安なのです(^^;) > ジョブスケジューラにおけるNET設計 これは何でしょうか? JP1 とかの話? そうです。本日書籍購入しました。上記と同じで、もし有効なHP等ご存知であれば教えてもらいたいと思ったので。。。。 |
|
>>3557 瀧上 > 主にUNIX環境でのバッチ処理におけるShellの置き場所や > 構成の最適な方式を調査できるHPを探していました。 そういうことを書いている web は見たことないですね。基本的に趣味で やってる人には関係ないし、それを知ってる企業は「ノウハウ」として 隠してしまいますので。 # しょーもないやり方を「ノウハウ」などと称しているところも # 多いわけですが。 ちょっと長くなりますが、まぁひととおり書いてみます。 まず、ユーザを複数作ります。例えばユーザ名が hoge なら、 hogedevel (開発環境) hogesi (SI (結合テスト) 環境) hogert (RT (受入テスト) 環境) の 3つくらい。それぞれのホームディレクトリは /home/hogedevel, /home/hogesi, /home/hogert などとします。 さらに DB が必要であれば、これも 3つ (hogedevel, hogesi, hogert) 作ります。 通常の開発は hogedevel を使います。hogesi や hogert は テストの段階で初めて使います。 「開発者は基本的に hogedevel しか使ってはいけない」 というシバリを入れるのもよいでしょう。 各ホームディレクトリの下には src/ ソース置き場。CVS などでソース管理すること。 conf/ 手で管理する設定ファイルなどを置く場所。 bin/ バイナリ置き場。src で make install すると作成される。 lib/ バイナリ以外の設定ファイルやデータファイルなど。 src で make install すると作成されるものに限る。 log/ ログファイル置き場 dat/ 生成するデータファイル・他から送られてきたデータファイル とします。 つまり src/ で make install すると bin/, lib/ が作成される わけなので、bin/ や lib/ は消しても src/ を元に再作成する ことができます。 しかし conf/ は手動管理の設定ファイル群なので、こちらは 消してはいけません (conf/ も CVS などで管理するのがよい でしょう)。 lib/ には、プログラムで生成する雛型のファイルとか、SQL*Loader 用に喰わせるファイルなど、devel, si, rt で共用のファイルを置き ます (実行形式のバイナリではないけど、プログラムの一部と見なして よいものを置く)。 で、環境変数は /home/hogedevel/conf/env.sh /home/hogesi/conf/env.sh /home/hogert/conf/env.sh に ORACLE_SID=hogedevel HOME=/home/hogedevel PATH=/home/hogedevel/bin ORACLE_HOME=... 書きます。 これを source して各アプリが起動し、 - DB の接続先は $ORACLE_SID とする - $HOME/log/ にログを吐く - $HOME/data/ にデータファイルを作成する とします。 というわけで、基本的には > バッチ処理起動shellでsourceする環境設定ファイルにディレクトリと > OracleSIDを考えているが、これが最適なのか？ それでよいと思います。 > コンパイラ等、ツールの環境(変数)設定ファイルは全て別で持つのが > 好ましいのか どういうファイルのことを指しているのかよくわかりませんが、 $ORACLE_HOME/precomp/lib/env_precomp.mk とかですか? 基本的に、この辺は共通でよいのではないでしょうか。もし、一部の プログラムで特殊なことをしたければ Makefile 内で上書きすればよい わけで。 あと、いくつか気をつけるポイントをあげておきます。 - ディレクトリやファイルは絶対に手で作成しない。 手で作成するとかならずミスするので、全て Makefile に 記述する。 - CVS などのソース管理ツールを活用する。 /home/hoge{si,rt}/src/ に手でソースを配置し、手で make install する、というやり方は極力避ける。CVS などでマスタ管理し、 毎日朝 AM6:00 に、自動的に ~hoge{si,rt}/src にソースを checkout し、make install などと、全てを自動化するのがベスト。 この他に何か質問があれば、もう少しポイントを絞って、具体例を あげてください。 >> これは何でしょうか? JP1 とかの話? > そうです。本日書籍購入しました。 非オープン系なアプリの場合、web 上からの情報収集は厳しいかと 思います。 JP1 は使ったことがないのでわかりません (わたしは cron の代替品、程度の 認識しかありませんが)。やっぱり便利なんですかねぇ。 |
|
>>3558 68user > しかし conf/ は手動管理の設定ファイル群なので、こちらは > 消してはいけません (conf/ も CVS などで管理するのがよい > でしょう)。 lib/ との違いがわかりづらい気がするので補足。 hoge{devel,si,rt} で異なる設定ファイルは conf/ に、そうでない ものは lib/ に置く、という意味です。 もちろん make 時に環境によって異なるファイルを lib/ にインス トールできれば conf/ などいらないのですが、それを実現するためにMakefile に複雑な細工をしなければいけないケースがあったりするので。 |
|
おひさしぶりです。困ったときばっかり登場してすみません。 たぶんあけましておめでとうございます。 ここ５年ぐらいメンテしてる 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」だけでは、引っ掛けられません。 |