68user's page 掲示板

Prev< No. 3565〜3579> Next  [最新発言に戻る] [過去ログ一覧]
No. 3565 # 68user 2004/02/18 (水) 22:27:42
>>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
すれば全アプリ入れ替え完了)。

# 仮に動的リンクを選択したとしても、上記の「定期リリース
# ごとに全部インストールしなおす」というやり方は強く
# おすすめしておきます。

No. 3566 # 68user 2004/02/18 (水) 22:32:15
>>3564 たけ
> 指定したポートを開放するために必要なinetd.confの
> 設定方法を教えてください。
質問が曖昧すぎて答えられません。inetd のマニュアルと
/etc/inetd.conf にある他の設定例を見てください。

それでもわからなければ、何がしたいのかを明記した上で
再度質問してください。

No. 3567 # うこん 2004/02/19 (木) 20:31:09
はじめまして。初心者ですが、コマンドはどこに打てばいいんですか?

No. 3568 # すすむ 2004/02/19 (木) 23:45:42
以下のようなファイルから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

で一応とりだせるのですが、改行の2行が含まれて
しまいます。空改行を含まず1回の処理でやりたいのですが
どうすればよいのですか。

No. 3569 # すすむ 2004/02/20 (金) 02:12:12
>>3568 すすむ

環境を書き忘れました。
SunOSで、Bシェルです。

No. 3570 # zsh 2004/02/20 (金) 10:53:37
>>3568 すすむ
errorを取り出したいなら素直に
grep ":error" filename
とすれば良いのでは?

まぁ名前にerrorが含まれる人がいると引っかかってしまうので
正規表現使うべきなんだろうけど。

No. 3571 # つくも 2004/02/20 (金) 12:14:56
>>3568 すすむ
賢いかはわかりませんが、

grep -v "\-----" ファイル名 | grep -v success | awk '{ if(NF != 0) print $0 }'

でできませんか。

No. 3572 # すすむ 2004/02/20 (金) 12:17:41
>>3568 すすむ

「success」と「error」と簡単に書きましたが、
成功の場合は、「success」で、失敗の場合は、エラーメッセージが
でます。
「error」だけでは、引っ掛けられません。

No. 3573 # 68user 2004/02/20 (金) 12:54:19
>>3567 うこん
あなたが置かれている状況がわからないので、回答できません。

>>3568 すすむ
わたしなら
      egrep '^(add|mod|del):' | grep -v ':success$'
とします。

No. 3574 # zsh 2004/02/20 (金) 13:15:19
>>3572 すすむ
であれば、
egrep -v '^(-|$|.*:success$)' filename
とか?

No. 3575 # すすむ 2004/02/20 (金) 16:00:58
>>3573 68user
>>3574 zsh

zshさん、68userさん
ありがとうございます。
egrepですか。

使用したことがないのですが、
「'^(-|$|.*:success$)' 」
の使い方につてい教えてください。

No. 3576 # /tk 2004/02/20 (金) 16:06:04
>>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

No. 3577 # 瀧上 2004/02/21 (土) 19:01:34
>>3565 
ご回答ありがとうございます。
ライブラリの考え方は参考になります。
要件が無ければ原則禁止にしてしまおうかななんて。。。検討中です。。

ところでshellでバッチを走らせる時はユーザ設定を行わないようにするのがいいのですね。UNIXの部屋にある↓を見て気づきました。
「#!/bin/csh -f というのをよく見かけるが、その場合ユーザ独自の ~/.cshrc は読まれないので、エイリアスやシェル変数は使用できなくなる。」
なので今回はshellの構成は下記の様にするつもりです。ご報告まで。。。
----------------------------------
#!/bin/csh -f
#-------------------
#shell
#
#-------------------
source COMMON.src #→システム共通のパス(oracle等)や文字指定(LANG等)
source 環境.env   #→システム共通環境変数設定等

処理・・・・
-----------------------

No. 3578 # 瀧上 2004/02/22 (日) 18:22:17
Makeの環境について教えて下さい。
現在下記のディレクトリを作成して開発環境としようと考えていました。

/src /* makefileとsrcを保管     */
/obj /* make時の中間ファイルを保管 */
/bin /* 実行ファイルを保管     */

するとあるガイドに「.oと.cを別ディレクトリに置くとmake時のタイムスタンプの比較が困難になるのでやめるべきだ」、と書いてありました。
「個々の依存関係をいちいち指定しなければならない。」ともあり、「いちいち」等と書かれると非常に非効率な事の様に感じるのですが。。。

「.cと.oは同一ディレクトリに持つ」が一般開発業務で用いられる主要な方式なのでしょうか?
単体環境だと不特定多数の人間が多様なsrcファイルを作るのであまり余計なファイルを置いてごちゃごちゃさせたくないと言うのが理由で分けてるだけなので同一ディレクトリも特に問題は無いのですが。。。(消されても問題は無いファイルですし。。)
依存関係をmakefileに指定して別ディレクトリ管理と言うのはやらないのですかね?

No. 3579 # UNIX10ヶ月目 2004/02/22 (日) 21:19:06
No.3568さんに似たような質問なんですが、

ファイルが以下のようにあったとします。
_________________________________________
aaa bb ccc 02/22 ddd e1.3 fff
_________________________________________
その時に、実行するたびにe1.3の数字をe1.4、e1.5と実行
するたびに数字を0.1ずつ変更したいんですがCシェルで
そのような事をしたいのですが、どうしたらいいのでしょうか。
ご教授お願いします。

Prev< No. 3565〜3579> Next  [最新発言に戻る] [過去ログ一覧]