Linuxでfor文やwhile文を実施したときに引数を自動で認識してくれます。
例えば・・・

---------------------------------------------
for i in 1 2 3 ; do
    echo ${i}
done
---------------------------------------------

するとプロンプトには
1
2
3
と表示されるので、for文に1と2と3が順番に入っていることがわかります。
と、いうことはfor文は「1」と「2」と「3」は別の文字であり、引数は3つと認識しているようです。
「1 2 3」というスペース混じりの一つの文字列とは認識されないんですね。

それでは「1」と「2」と「3」を別の文字だと区切っているものはなんでしょうか？
スペースですよね。
シェルはこの区切り文字をどのように認識されているのでしょうか？
それは$IFSという変数で持っています。
デフォルトではこんな感じ

---------------------------------------------
IFS=$' \t\n'
---------------------------------------------

スペースとタブと改行が入っています。
そのためfor文を実行したときに「1」と「2」と「3」は別々の引数として処理されました。

長くなりましたが、結論、区切り文字を変更したい場合は$IFS変数を変更すれば良いということです。

でわでわ

ubuntu 10.04 でnfsを使用するためには、nfsを利用するためのクライアントパッケージのインストールが必要みたいです。
CentOS5.x系だと最低限のパッケージ構成でもインストールされているので気づきませんでした。

インストールするパッケージは
nfs-common

およびその依存関係パッケージ
portmapなんかも入るみたいですが…

インストールはapt-getでインストールしてもsynapticパッケージマネージャでインストールしてもOK
mountでファイルシステムの指定が適切でない旨のエラーがでた場合、確認してみるのも良いと思います。

でわでわ

 Apache2(httpd)でVirtualHost毎、またはSubDomain毎などで実行するユーザを変更したい場合。
# ほとんどの片がホスティング業者の場合だと思いますが

「httpd.conf」に「SuexecUserGroup」ディレクティブを作成し、そこに実行ユーザとグループを記述します。
設定後反映のためにApacheを起動するのですが、
警告が発生する、または、実際に実行ユーザが反映されていないケースが発生します。


または、
tail /var/log/httpd/error_log
[中略](13)Permission denied: exec of '/usr/sbin/suexec' failed

こんな感じ。
起動に成功しているのでWEBは見れるのだけど特にCGIなどの実行系のプログラムが正常に稼動しない。
この場合suexecコマンドの実行権限、ないし、所有ユーザが違う場合がある。

# ls -la /usr/sbin/suexec

実行権が「-rwsr-xr-x」（4755）でないなら、権限を変更します。

# chmod 4755 /usr/sbin/suexec

再起動してエラーが発生しないことを確認します。

# /sbin/service httpd restart

Linux環境で処理時間の長いバッチや
中断すると再実行が難しい処理を行う場合に「nohup」コマンドはよく用いられます。

nohupはハングアップシグナルを無視するため、ログアウトしたり
ネットワーク回線の調子で通信が遮断された場合でも処理を続けることができます。

しかしながら、nice値やnohup.outの挙動についてはよく知りませんでしたね。
勉強になりました。

codezine.jp/unixdic/w/nohup/

でわでわ

備忘録？
postgresql のpg_dump(データベースのバックアップ)を実施しようと思ったらこんなエラーが発生しました。


$ pg_dump -t table_name database_name
pg_dump: server version: !; pg_dump version: 7.3.10-RH
pg_dump: aborting because of version mismatch (Use the -i option to proceed anyway.)
$

ちょいちょいよくわからないのでググッてみたところ、異なるバージョンのpostgresqlが複数インストールされているのが原因みたい。
バージョンの違いを無視するオプション(-i)をつけてみると…？

$ pg_dump -i -t table_name database_name
pg_dump: server version: !; pg_dump version: 7.3.10-RH
pg_dump: proceeding despite version mismatch
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: column "datpath" does not exist
pg_dump: The command was: select (select usename from pg_user where usesysid = datdba) as dba, encoding, datpath from pg_database where datname = 'database_name'

想定通りに動いてくれません（ｐ>□<ｑ*））
上位バージョンのpg_dumpで下位バージョンのダンプを実施するには問題なさそうだけど、さすがにその逆は厳しいみたい。
# 逆かどうかは詳細に調べてないけどね ^^;

なのでfindで検索してみよー

$ find /usr/ -type f -name 'pg_dump'
find: /usr/share/ssl/CA:
/usr/bin/pg_dump
/usr/local/src/postgresql-8.1.1/doc/TODO.detail/pg_dump
/usr/local/src/postgresql-8.1.3/doc/TODO.detail/pg_dump
/usr/local/src/postgresql-8.1.3/src/bin/pg_dump/pg_dump
/usr/local/pgsql/bin/pg_dump
find: /usr/local/pgsql/data:


おおー、出たわね（笑）
pathで通っている「pg_dump」は「version 7.3.10」だと叱られてしまいます。
下位互換ならありそうだということで、それ以上を探すのだからバージョン[8.x]系は怪しい。
けど、「doc」の中と「src」中ってことは…おそらく無い、というよりこの時点ではとりあえず除外。
そしてpathが通っているコマンドとは？

$ which pg_dump
/usr/bin/pg_dump

ふ～ん（笑）
念のため確認しましょ。

$  pg_dump --version
pg_dump (PostgreSQL) 7.3.10-RH
$ /usr/bin/pg_dump --version
pg_dump (PostgreSQL) 7.3.10-RH

と、いうことで一緒だと仮定しましょ。

それなら残る「pg_dump」は？
「/usr/local/pgsql/bin/pg_dump」
しかないと。
$ /usr/local/pgsql/bin/pg_dump --version
pg_dump (PostgreSQL) 8.1.3

うん、間違い無くこれっしょ ^^

実行してみると？
正常に動きましたー
やったねぇ

まぁ、コアなシステムではこんなこともあるから気を付けないとね
でわでわ