|
>>3552 恵美 - ($x{'k1'}, $x{'k2'}) は @x{'k1','k2'} と等価 (*1)。 - ハッシュのリファレンス $y のデリファレンスは $$y{'k1'} ($y->{'k1'} と同じ)。 をふまえた上で、今回は ($$y{'k1'}, $$y{'k2'}) を代入したい ので、*1 を素直に置き換えると @$hash{'a','c'} = @$hash2{'x','z'}; となります。 てゆーか、ハッシュスライスは使わない方がいいですよ。配列と 間違えやすいので、可読性低すぎです。わたしなら 2 項目であれば $hash->{'a'} = $hash2->{'x'}; $hash->{'c'} = $hash2->{'z'}; と 2行で書きます。 どうしても短く書きたい場合でも ($hash->{'a'}, $hash->{'c'}) = ($hash2->{'x'}, $hash2->{'z'}); とします。 項目数が多いなら my %map_table = ('x'=>'a', 'z'=>'c'); while (my ($fromkey, $tokey) = each %map_table){ $hash->{$tokey} = $hash2{$fromkey}; } とか。長くはなりますが、項目の対応がもっともわかりやすく、タイプ ミス ($hash と $hash2 を書き間違えるとか) の可能性も減ります。 |
|
こんにちは恵美です。 どうもありがとうです(^^)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 の代替品、程度の 認識しかありませんが)。やっぱり便利なんですかねぇ。 |