【訳注】 「シェルスクリプト作成のテクニック Part 3」の続きのエントリーです。

デバッグする

スクリプトを書き終えたら、プログラムを動かしてみる時間です。ところが、スクリプトを実行したところ、予期しないエラーが表示されてしまいました。原因はなんでしょう？この世の中に完全無欠な人なんていません。スクラッチからスクリプトを書き始め、エラーが出なくなるようにするまでに多くの時間と試行錯誤を要します。たいていの場合、文字が抜けていたり、間違った文字になっていたりしているのが原因で、どうしても見逃してしまうようです。それでもご安心下さい。AIXを含むUNIXやLinuxのシェルには、デバッグを助けてくれる機能があります。

Listing 10: エラーを含むスクリプトの例

#!/bin/bash

_X=1
while [[ ${_X} -le 10 ]]
do
  [[ ${_X} -lt 5 ]] && echo "X is less than 5!

  _Y=`expr ${_X) + 1`

  if [[ ${_Y} -eq 6 ]]
    echo "Y is now equal to ${_Y}"
  fi

  _X=${_Y}
done

しかし、最初にこのスクリプトを実行してむると、以下のようなエラーが表示されます。

# ./make_errors
./make_errors: line 11: unexpected EOF while looking for matching `"'
./make_errors: line 16: syntax error: unexpected end of file

あなたがすでに使っている可能性があり、それにも関わらずあまり知られていない優れたデバッグツールがVimです。Vimは強力なテキストエディターであると同時に、デバッグでも非常に役に立ってくれます。もし、あなたが.exrcや.vimrcファイルを設定し、特定のエラー状況をカラーで表示してくれるようにしているならば、Vimは図1で表示されるようにあなたの仕事の大部分をやってくれるでしょう。

図1: Vimでデバッグする

:::画像1:::

最初のエラー「line 11: unexpected EOF while looking for matching `"'」は、11行目で何かが起こっていると言っていますが、その行を見てみても、何が悪いかよく分かりません。それでは6行目を見てみましょう。ダブルクオーテーションマーク（"）がechoされている文字列の最後から抜けています。これはデバッグの際に実際にスクリプトを見ないといけないという典型的な例です。エラーとして表示される列が必ずしも実際のエラー発生行とは限りません。11行目がエラー発生行として表示されているのは、6行目でダブルクォーテーションで囲まれ始めて、11行目まで閉じられなかったからです。エラーを修正するには、6行目の最後にダブルクオーテーションを追加します。

それとは別にエラーがあると表示されているのは8行目です。ここでは、変数_Xの閉じる丸括弧「)」が赤くハイライトされています。ここではVimがあなたの代わりに何が悪いか表示してくれました。変数_Xは波括弧「{」で始まっているのに正しく閉じられていません。「)」から「}」に変更しておきましょう。

今のところ2つのエラーを修正するのによい仕事をしてくれています。それではスクリプトを再実行してみましょう。

./make_errors: line 12: syntax error near unexpected token `fi'
./make_errors: line 12: `  fi'

別のエラーがあるようです。エラーは12行目に問題があると言っていますが、そこにはif文を閉じるfiしかありません。何が駄目なんでしょうか？前のエラーの時はどんなだったか思い出して下さい。必ずしもすべてのエラーがシェルが問題があると指摘した行にあるわけではありません。シェルは単純にエラーが発生したと言っているだけで、実際のエラー原因はシェルが失敗を報告した行以前にある可能性があります。この小さなスクリプトではほぼ間違いなく、if文自体に問題があると思われます。シェルスクリプトの基本ロジックに立ち戻り、if文がifとthenとfiから構成されていることを思い出しましょう。それでは見直してみましょう。どうやらthenが抜けているようです。単純にthenをスクリプトに追加するだけです。それが完了すると、Listing 11のようなスクリプトになります。

Listing 11: Listing 10のスクリプトを修正したもの

#!/bin/bash

_X=1
while [[ ${_X} -le 10 ]]
do
  [[ ${_X} -lt 5 ]] && echo "X is less than 5!"

  _Y=`expr ${_X} + 1`

  if [[ ${_Y} -eq 6 ]]
  then
    echo "Y is now equal to ${_Y}"
  fi

  _X=${_Y}
done

それではもう一度スクリプトを実行してみましょう。

# ./make_errors
X is less than 5!
X is less than 5!
X is less than 5!
X is less than 5!
Y is now equal to 6

おめでとうございます！スクリプトは想定通りに動くようになりました。

set -xオプション

しかしながら、シェルスクリプトのトラブルシューティングの方法は上記の例のように単純にはいかないことがあります。予想外の失敗が発生し、壁に頭を叩きつけても、失敗の原因が分からない時、最終手段として銃を取り出すしかないのでしょうか。kshとbash、それ以外の最新のシェルにはsetコマンドに-xオプションが含まれています。このset -xオプションを使うことにより、展開や評価されるすべてのコマンドが標準出力に表示されるようになります。評価されたコードを標準出力に出力する際、set -xはPS4変数の値を使用し、すべての行が出力されているかのように表示します。大量のテキストが出力されるので、辛抱強く内容を追いかけないといけないことは覚えておいて下さい。

以前取り上げたスクリプト例のループカウント数を少し減らし、set -xをスクリプトの冒頭に追加し、コメントも付けてみました。その後、これを実行してみます。Listing 12が修正したスクリプトです。

Listing 12: set -xの例

#!/bin/bash

set -x

# loop through and display some test statements
_X=1
while [[ ${_X} -le 4 ]]
do
  [[ ${_X} -lt 2 ]] && echo "X is less than 2!

  _Y=`expr ${_X} + 1`

  if [[ ${_Y} -eq 3 ]]
  then
    echo "Y is now equal to ${_Y}"
  fi

  _X=${_Y}
done

スクリプトを実行する前に、PS4変数の値を標準出力に表示させたいものに変更します。

# export PS4="DEBUG => "

次に、Listing 13のようにおそらく有益であろう情報の爆撃を自分自身に向かって送り付けてあげましょう。

Listing 13: set -xの出力例

# ./make_errors
DEBUG => _X=1
DEBUG => [[ 1 -le 4 ]]
DEBUG => [[ 1 -lt 2 ]]
DEBUG => echo 'X is less than 2!'
X is less than 2!
DDEBUG => expr 1 + 1
DEBUG => _Y=2
DEBUG => [[ 2 -eq 3 ]]
DEBUG => _X=2
DEBUG => [[ 2 -le 4 ]]
DEBUG => [[ 2 -lt 2 ]]
DDEBUG => expr 2 + 1
DEBUG => _Y=3
DEBUG => [[ 3 -eq 3 ]]
DEBUG => echo 'Y is now equal to 3'
Y is now equal to 3
DEBUG => _X=3
DEBUG => [[ 3 -le 4 ]]
DEBUG => [[ 3 -lt 2 ]]
DDEBUG => expr 3 + 1
DEBUG => _Y=4
DEBUG => [[ 4 -eq 3 ]]
DEBUG => _X=4
DEBUG => [[ 4 -le 4 ]]
DEBUG => [[ 4 -lt 2 ]]
DDEBUG => expr 4 + 1
DEBUG => _Y=5
DEBUG => [[ 5 -eq 3 ]]
DEBUG => _X=5
DEBUG => [[ 5 -le 4 ]]

ご覧の通り、大量の情報が表示されます。すべてのコマンドが評価され、実行されています。また、デバッグ情報ではコメント行の内容が出力されていないことにも気付くはずです。これはコメント行の文字列といのは評価はされるけど、実行されていないからです。ありがたいことに、最初に修正して以降もスクリプトには問題はないようです。

一つだけ覚えておいて欲しいのは、set -xを使用した際、そのスクリプトに内部関数がある場合に、set -xオプションは子供の関数にも引き継がれるということです。しかし、set -xが内部関数にしか含まれない場合、その内部関数で実行されるコードとその子供の関数にしかデバッグオプションは引き継がれず、親のスクリプト部分には影響を及ぼしません。そのため、子供の関数が呼び出したルーチンが何をしているのか分からなくなります。

結び

私たちはシェルスクリプトであれ、Cであれ、Javaであれ、その他の言語であれ、プログラミング技術を向上させようとしています。コードは簡潔にし、明快かつ柔軟性を持ち、文書化を怠らないという基本ルールを守っていれば、あなたが学んだデバッグ手法から学ぶことがほとんどないような優れたシェルスクリプトを書けるようになるはずです。頑張ってください！

【訳注】 「シェルスクリプト作成のテクニック Part 2」の続きのエントリーです。

文書化、文書化、文書化

自分のキャリアを振り返ってみた時、この問題の犠牲にならなかった人がいないはずがありません。もしかしたらあなたも、すでに退職された方が書いた10年前のスクリプトを調べてもらえないかとお願いされたことはありませんか？その時、「ええ、いいですよ」と快諾出来ましたか？問題ない場合もあるでしょう。しかし、そのスクリプトが複雑だったり、あなたにとって馴染みのないコマンドが使われていたり、あなたが慣れ親しんだものとはまったく異なるスタイルだったり、単純に動かなかったりした場合、作者がスクリプトを作成した時に何を意図していたかヒントが記述されていれば、本当に助かるものです。あるいは、貴方がスクリプトを作成し、それは一回限りのもので二度と使うことはないとします。その場合も文書化は必要ないと言い切れるでしょうか。また、数週間の用途で巨大なスクリプトを作成し、あなたはその動作のすべてを把握している場合でも、他の人がそれを見ることになった場合、その人は困惑してしまうかもしれません。ここではスクリプトの文書化がユーザーだけでなく開発者にとっても重要である理由をいくつかの例から紹介していきたいと思います。

Listing 6: コメントのないスクリプトの例

confirm_and_exit() {
  [[ ${_DEBUG_LEVEL} -ge 3 ]] && set -x
  while [[ -z ${_EXIT_ANS} ]]
  do
    cup_echo "Are you sure you want to exit? [Y/N]  
        \c" ${_PROMPT_ERR_ROW} ${_PROMPT_ERR_COL}
    ${_TPUT_CMD} cnorm
    read ${_NO_EOL_FLAG:+${_READ_FLAG:-'-n'}} ${_NO_EOL_FLAG} _EXIT_ANS
    ${_TPUT_CMD} civis
  done

  case ${_EXIT_ANS} in
    [Nn])  unset _EXIT_ANS; return 0;;
    [Yy])  exit_msg 0 1 "Exiting Script";;
       *)  invalid_selection ${_EXIT_ANS}; unset _EXIT_ANS;;
  esac
  return 0
}

あなたがスクリプトに精通されている方なら、これを読むことが出来ると思います。しかし、スクリプトの勉強中の方がこれを見た場合、この関数が何をしているのか分からないかもしれません。数分間の時間を確保してスクリプトにコメントを追加するだけで、状況は一変します。Listing 7ではコメントを付けた同じ関数を表示しています。

Listing 7: コメントの付いたスクリプトの例

#########################################
# 関数名 confirm_and_exit
#########################################
confirm_and_exit() {
  # デバッグレベルが 3 以上に設定されている場合は、評価されたすべての行が標準出力に出力されます
  [[ ${_DEBUG_LEVEL} -ge 3 ]] && set --x

  # ユーザーが正しい回答を入力されるまで、プロンプトを表示し続ける
  while [[ -z ${_EXIT_ANS} ]]
  do
    # スクリプトを抜けるかどうかユーザーにプロンプトを表示する
    # 関数 cup_echo は tpu cup   をコールします
    # 構文:
    # cup_echo <表示させる文字列> <表示させる行番号> <表示させる列番号>
    cup_echo "Are you sure you want to exit? [Y/N]  
        \c" ${_PROMPT_ERR_ROW} ${_PROMPT_ERR_COL}

    # tput を使ってカーソルを通常に戻す
    ${_TPUT_CMD} cnorm

    # ユーザーが入力した値を読み取る
    # 変数 _NO_EOL_FLAG が設定されている場合は、_READ_FLAG の値か、"-n"を使う
    # 変数 _NO_EOL_FLAG が設定されている場合は、read から読み込まれた値を文字列として用いる
    # ユーザーが入力した値を変数 _EXIT_ANS に設定する
    read ${_NO_EOL_FLAG:+${_READ_FLAG:-'-n'}} ${_NO_EOL_FLAG} _EXIT_ANS

    # tput を使ってカーソルを非表示にする
    ${_TPUT_CMD} civis
  done

  # ユーザーが"n"を入力した場合は、リターンコード 0 を返し、コードの一個前のブロックに戻る
  # ユーザーが"y"を入力した場合は、スクリプトを抜ける
  # ユーザーがそれ以外の値を入力した場合は、関数 invalid_selection を実行する 
  case ${_EXIT_ANS} in
    [Nn])  unset _EXIT_ANS; return 0;;
    [Yy])  exit_msg 0 1 "Exiting Script";;
       *)  invalid_selection ${_EXIT_ANS}; unset _EXIT_ANS;;
  esac

  # リターンコード 0 を返して関数を抜ける
  return 0
}

こんな小さな関数に対してやるには極めて退屈で過剰な作業かもしれませんが、コメントに記載されている内容は、初心者のシェルスクリプターや関数の内容を調べる人間にとって極めて有益な情報と言えます。

他にシェルスクリプトのコメントの有効活用の例としては、リターンコードと変数の説明が挙げられます。

Listing 8はあるシェルスクリプトの冒頭部分です。

Listing 8: 文書化されていない変数の例

#!/usr/bin/bash
trap 'exit_msg 1 0 "Signal Caught. Exiting..."' HUP INT QUIT KILL ABRT
trap 'window_size_changed' WINCH

_MSG_SLEEP_TIME=3
_RETNUM_SIZE=6
_DEBUG_LEVEL=0
_TMPDIR="/tmp"
_SP_LOG="${0##*/}.log"
_SP_REQUESTS="${HOME}/sp_requests"
_MENU_ITEMS=15
LESS="-P LINE\: %l"
export _SP_REQUESTS _TMPDIR _SP_LOG _DB_BACKUP_DIR 
    export _DEBUG_LEVEL _NEW_RMSYNC _RMTOTS_OFFSET_COL

繰り返しになりますが、これらの変数が何を目的として、どんな値が入るのかを理解するのは極めて困難です。スクリプトを全部読んでみない限り、これらの変数だけでは何も分かりません。それに加えて、このスクリプトで使われているリターンコードに関する言及はありません。こうなるとシェルスクリプトのトラブルシューティングは必要以上に難しいものとなります。Listing 8にリターンコードの意味を説明したセクションを追加して、紛らわしさをなくしましょう。Listing 9を見て下さい。

Listing 9: 文書化された変数の例

#!/usr/bin/bash
#########################################################################
# trap
#########################################################################
# ユーザーがスクリプトを抜ける際のtrap
trap 'exit_msg 1 0 "Signal Caught. Exiting..."' HUP INT QUIT KILL ABRT
trap 'window_size_changed' WINCH                # ユーザーがウインドウをリサイズした時のtrap
#########################################################################

#########################################################################
# 定義済み変数/export された変数
#########################################################################
_MSG_SLEEP_TIME=3             	       # すべてのメッセージで使われる sleep の秒数
                                      # (未定義の場合、デフォルトは 3 秒になる)
_CUSTNUM_SIZE=6                       # この場所での顧客番号の長さ
                                      # (未定義の場合、デフォルトは 6 になる)
_DEBUG_LEVEL=0                        # デバッグメッセージをログする。ログレベルは累積
                                      # (例： 1 は 1、2 は 1 と 2、3 は 1 と 2 と 3 )
                                      # (未定義の場合、デフォルトは 0 になる)
                                      # ログレベル:
                                      #  0 = メッセージなし
                                      #  1 = 簡単なメッセージ (スクリプトの開始やエラーなど)
                                      #  2 = 環境の設定 ( set や env )
                                      #  3 = set -x を実行 (しつこいくらいメッセージが出る)
_TMPDIR="/tmp"                        # 作業ファイルや一次ファイルを格納するディレクトリ
                                      # (未定義の場合、デフォルトは /tmp になる)
_SP_LOG="${0##*/}.log"                # スクリプトファイルのログ
_SP_REQUESTS="${HOME}/sp_requests"
			               # 顧客レコード要求のファイル
                                      # 開始時に読み込まれる
_MENU_ITEMS=15                        # ページ単位に表示するアイテムのデフォルト数
                                      # (未定義の場合、デフォルトは 10 になる)
LESS="-P LINE\: %l"                   # 'less'プロンプトをフォーマットする。詳しくは MAN less を参照


# 上記で定義した変数を export する
export _MSG_SLEEP_TIME _CUSTNUM_SIZE _DEBUG_LEVEL _TMPDIR 
    _SP_LOG _SP_REQUESTS _MENU_ITEMS
#########################################################################

分かりやすくなりましたか？すべての変数が組織化と詳細化されたため、初めてこのスクリプトを読む人でもこのプログラムが何であるか判断しやすくなったはずです。

【訳注】 「シェルスクリプト作成のテクニック Part 4」に続きます。

【訳注】 「シェルスクリプト作成のテクニック Part 1」の続きのエントリーです。

スクリプトは柔軟に

初心者がプログラミングする際に直面する別の問題が、プログラムやシェルスクリプトの中に静的な値をハードコードしてしまうことです。これはスクリプトの柔軟性を損なってしまい、要するに悪いプログラミングだとみなされます。スクリプトを動かすためにシステム管理者や開発者がその都度スクリプトを修正するのではなく、他の値を与えた場合にもスクリプトが動くように、変数と引数をスクリプトや関数に追加しておきましょう。

Listing 3: 柔軟性のないスクリプトの例

#!/bin/bash

if [[ -f /home/cormany/FileA ]]
then
  echo "Found file '/home/cormany/FileA'"
elif [[ -f /home/cormany/DirA/FileA ]]
then
  echo "Found file '/home/cormany/DirA/FileA'"
else
  echo "Unable to find file FileA"
fi

このスクリプトは一つのファイルを2つの場所から探すことしか出来ない用途の限定的なスクリプトです。

もっと考え方を広げてみましょう。Listing 4では同じような動作をしますが、どんなファイルでも、どんな場所からでも探すことが出来るようにしてみましょう。

Listing 4: より柔軟性の増したスクリプト

#!/bin/bash

exit_msg() {
  [[ $# -gt 1 ]] && echo "${0##*/} (${1}) - ${2}"
  exit ${1:-0}
}

[[ $# -lt 2 ]] && exit_msg 1 "Usage: ${0##*/}  "

_FNAME="${1}"
_DNAME="${2}"

[[ ! -d "${_DNAME}" ]] && exit_msg 2 "Unable to read or find directory '${_DNAME}'"

if [[ -f "${_DNAME}/${_FNAME}" ]]
then
  exit_msg 0 "Found file '${_DNAME}/${_FNAME}'"
else
  exit_msg 3 "Unable to find file '${_DNAME}/${_FNAME}'"
fi

この例ではより柔軟になりました。ユーザーは探して欲しいファイルと探したい場所を入力できるようになりました。

オプションを追加する

シェルスクリプトを作成する際、ある人が「これがあれば便利だよね！」とか「これもやってくれるなんて凄いよね！」と言っている一方で、他の人はそんなものはいらないと思っていたり、そんな余計な動作はして欲しくないと思っていたりします。人々は選択出来ることを喜びます。それならば彼らにオプションを与えましょう。ビルトインされているシェルコマンドのgetoptはこの役割をしてくれます。

Listing 5は、AIXでgetoptがどのように動作するかを説明した例です。

Listing 5: getoptの例

#!/usr/bin/ksh

_ARGS=`getopt -o x --long xxxxx -n ${0##*/} -- "$@"`
while [[ $# -gt 0 ]]
do
  case "${1}" in
    -x|--xxxxx)  echo "Arg x hit!"; shift;;
            --)  shift; break;;
             *)  echo "Invalid Option: ${1}"; break;;
  esac
done

getoptを含むスクリプト（ここでは仮にopttestとします）を実行する際、-xまたは--xxxxxという有効な引数を与えると、getoptはswitch判定を行い、case switchの中のコードを実行します。

# ./opttest -x
Arg x hit!

今度は無効なswitchオプションを与えて実行してみます。

# ./opttest -a
Invalid Option: -a

【訳注】 「シェルスクリプト作成のテクニック Part 3」に続きます。

他のUNIXやLinuxと同じように、IBM AIXにはシステム管理者や開発者、そしてユーザーが日時タスクや業務の効率化に取り組む際に味方となる強力なツールが存在します。その一つがシェルスクリプトです。

とはいえ、UNIXと数年付き合い、シェルスクリプトに手を出してきた人でも、オペレーティングシステムの裏側については勉強中で、まだまだスクリプトをマスターとしたとは言えない人も多いと思います。この記事では、シェルスクリプトとは何かから始まり、より高度なスクリプトを書く方法をご紹介します。一般的なプログラミングの基礎から簡潔なスクリプトの書き方、より柔軟性のあるスクリプトの書き方、明快なスクリプトの書き方、スクリプト内のドキュメンテーション方法、そしてスクリプトのデバッグがその内容です。

シェルスクリプト学習の世界に入ってきた人々が直面する問題の一つが、すでにスクリプト内に記述した処理をもう一度記述しようとしてしまうことです。それらの処理をコピーして、ハードコードされた値を変更するのではなく、関数を作って両方の処理を扱えるようにすることで、スクリプトを簡潔にすることが出来ます。関数を一箇所に集めれば、スクリプトが標準化され、一定の形式を保つことが出来ます。スクリプトのある箇所から呼び出された関数が正常に動くならば、他の箇所から呼び出されても正しく動く可能性がある程度保障されます。

それでは例題です。Listing 1のスクリプトを凝縮させ、短くより明快なプログラムへと簡潔化させて下さい。

Listing 1: より簡潔に記述できるスクリプトの例

#!/usr/bin/ksh

if [[ $# -lt 2 ]]
then
  echo "Usage: ${0##*/}  "
  exit 0
fi

if [[ ! -f "${1}" ]]
then
  echo "Unable to find file '${1}'"
  exit 1
fi

if [[ ! -r "${1}" ]]
then
  echo "Unable to read file '${1}'"
  exit 2
fi

gzip ${1}
ls -l ${1}.gz


if [[ ! -f "${2}" ]]
then
  echo "Unable to find file '${2}'"
  exit 1
fi

if [[ ! -r "${2}" ]]
then
  echo "Unable to read file '${2}'"
  exit 2
fi

gzip ${2}
ls -l ${2}.gz

このスクリプトは本当にひどいと思います（有難いことにこれはただの例題です）。スクリプトは出来るだけ凝縮させましょう。読者の目の疲労も考えて、Listing 2ではより明快なバージョンのスクリプトを掲載します。

Listing 2: Listing 1のスクリプトを凝縮させたもの

#!/usr/bin/ksh

exit_msg() {
  [[ $# -gt 1 ]] && echo "${0##*/} (${1}) - ${2}"
  exit ${1:-0}
}

[[ $# -lt 2 ]] && exit_msg 0 "Usage: ${0##*/}  "

for _FNAME in $@
do
  [[ ! -f "${_FNAME}" ]] && exit_msg 1 "Unable to find file '${_FNAME}'"
  [[ ! -r "${_FNAME}" ]] && exit_msg 2 "Unable to read file '${_FNAME}'"

  gzip ${_FNAME}
  ls -l ${_FNAME}.gz
done

違いに気付かれましたか？メッセージの表示とリターンコードを返すための簡単な関数を追加しました。また、すべての引数をforループで処理させることにより、より簡潔で理解しやすくしました。

【訳注】 「シェルスクリプト作成のテクニック Part 2」に続きます。

ここ最近、ブログやTwitterやIMで私が議論してきたのは、新しくて流行っているものに人々がどれほど興味を惹かれるかということです。別にこれは批判しているわけではありません。むしろ私なんかがそんな傾向を持った人の最たるものですから。私の上司はこれを“ヒカリモノ症候群”と呼んでいます。「Freindsterを見てみろよ」「いや、これからはMySpaceだ。」「はぁ？Facebookだろ。」「これからはSecond Lifeの時代だよ。」「いやいや、Twitterでしょ。」なんてことを何度も何度も繰り返しているんです。Web 2.0の世界というのは、この「新しくてクールなもの」というミームで成り立っています。Go2Web2.0をちょっと見てください。私が何を言いたいか分かると思います。

先日のエントリーは、この現象をちょっと皮肉めかして書いたみたというわけです。もし今日、Lotus Notesが初めて発表されたとしたら、現在話題になっている機能なんて簡単に実現することが出来るんだよ、ということをちょっと強調して書いてみました（それに加えて、セキュリティ面やオフライン機能、複製機能、ディレクトリ機能などについても、今日まで発表されてきたどの製品よりも優れていると個人的には思っていますが、それはまた別の話ということで）。しかし、どの製品も成功するためには、話題性と勢いが必要です。私のIBMの同僚であるLauren Cooney（彼とはTwitterで知り合いました）が教えてくれた、ハーバードビジネスレビューのクチコミマーケティングに関する記事のように、製品の成功というのにはユーザの助けというのが不可欠なものです。

【訳注】原文はジョークに走ったところがあるので、後半部分は割愛し、それ以前のエントリーも訳者の意図で一部内容を再構成しています。純粋な翻訳ではありませんので、ご了承下さい。

TSMで「java.lang.OutOfMemoryError」が発生する原因については2つのシチュエーションが考えられます。

ケース#1：管理センターでヘルスモニターが選択されたタイミングで以下のエラーが表示される。

ケース#2：ISCコマンドラインで負荷の高いQuery（例えば「q content」）が発行され、以下のANR2963Wメッセージが表示される。

ANR2963W This SQL query may produce a very large result table, or may require a significant amount of time to compute. Do you wish to proceed ( Y/N )?

ここでYを選ぶと、発行したQueryはエラーになって終了してしまいます。

ISCインスタンスが占有していたメモリ領域が解放されます。ケース#1に関しては、ISCを再起動して、メモリを解放するだけで解決することが分かっています。しかし、ケース#2はこれだけでは直らないようです。

ケース#2の対応や、今度も同様の問題が起こらないようにするためには、上記の手順を参照してISCを停止させ、以下のコマンドを実行して下さい。

/Tivoli/dsm/bin/supportUtil.sh ISC_Portal [ISC管理者ID] [ISC管理者パスワード]

管理センターSupport Utilityメニューが表示されるので、“4”を選択し、管理センターが使用出来る最大メモリサイズを変更します。ヒープサイズのデフォルト値は128MBで、最大ヒープサイズのデフォルト値は512MBです。管理センターが使える領域を増やすために、最大ヒープサイズを1024MBに増やしましょう。1024MBは推奨値です。なお、AIXでは最大2048MB、それ以外のプラットフォームでは1536MBまで設定出来ます。

管理センターのセッションによるメモリ使用量を減らすために、“5”を選択して、管理センターのセッションタイムアウト値をデフォルトの30分からそれ以下に減らします。

以上の情報はこちらのIBM Technoteでも参照出来ます。

IBMの文書でもISCと管理センターはメモリ使用の大きい他のアプリケーションと同居させないように記述されています。必要なのはメモリで、プロセッサはそれほど必要ではありません。

IBM Technoteの「Replacing a damaged primary storage pool volume」では、破損したプライマリーストレージプールボリュームのデータを復旧するための手順がリスト化されています。最も重要な点は、“backup stgpool”コマンドを使ってデータをコピーストレージプールにコピーしている点です。これはどのTSM環境でも当てはまる点です。

私が見る限り、これは完璧な手順です。この文書では必要な手順が網羅されており、間違った手順によってデータを失う危険性を回避することが出来ます。

最後の#10はプライマリーストレージプールボリュームの削除を行っています。この手順が最後にリストされているのは、もし最初に“delete volume ボリューム名 discard=yes”を実行してしまうと、ボリューム上のデータをコピープールから復旧出来なくなるからです。

こういうことを書くと、何て馬鹿なこと書いてんだ、と思うかもしれませんが、こういうことを考える人も実際にいます。まずプライマリーストレージプールを削除して、それからコピープールからリストアしようと。なのでこのエントリーは注意事項だと思って下さい。

“del vol ボリューム名 discard=yes”をプライマリストレージプールボリュームに対して発行すると、コピープール上の対応するエントリーも削除されてしまいます。このコマンドを実行する時は必ず再確認して下さい。

この手順ではプライマリーストレージプールにコピーストレージプールが存在している必要があり、ボリューム上のデータが“backup stgpool”コマンドでコピーされている必要があります。破損したデータがコピーストレージプールにコピーされていなかったり、コピーの前にデータ破損が発生した場合は、データ復旧が出来なくなります。リストア出来ないファイルはクライアントから再度バックアップすることが出来ます。

1. 破損したボリュームをDESTROYEDとしてマークして、アクセスされないようにする。
   

   UPDATE VOLUME ボリューム名 ACCESS=DESTROYED

2. ボリュームをライブラリからチェックアウトさせる。RESTOREコマンドが実行されると、事前にチェックアウトしていない限り、DESTROYEDとなったボリュームはTSMデータベースから削除され、TSMから物理的にボリュームを削除出来なくなります。
   

   CHECKOUT LIBVOLUME ライブラリ名 ボリューム名

3. このコマンドではリストアのプレビューのみ行い、物理データの移動は行いません。これを実行することで、リストアで必要になるボリュームがリストアップされます。
   

   RESTORE VOLUME ボリューム名 PREVIEW=YES

4. 活動ログを確認し、オフサイトのストレージから戻さないといけないボリュームのリストを確認し、ライブラリにチェックインします。
   

   QUERY ACTLOG

5. 上記のステップで確認したボリュームをライブラリのBULK I/Oドアに配置し、ライブラリにチェックインします。BULK I/Oドアがない場合は、ライブラリ内の空スロットに配置し、SEARCHパラメータをYESにして下さい。
   

   CHECKIN LIBVOLUME ライブラリ名 SEARCH=BULK CHECKLABEL=BARCODE

6. チェックインされたボリュームは処理対象とならないようにREADONLYにマークしなければなりません。上記のプレビュー実行時にリスト化されたすべてのボリュームをACCESS=READONLYにすることは極めて重要なことです。
   

   UPDATE VOLUME ボリューム名 ACCESS=READONLY WHERESTGPOOL=コピープール名

7. 次のコマンドでボリュームのリストアが開始されます。“MAXPROCESS”の数は少なくとも2が必要です。1つはコピープールボリュームから読み取りを行い、もう1つは新しいプライマリーストレージブールボリュームに書き込みをするからです。十分な数のスクラッチボリュームがあることを確認しておいて下さい。
   

   RESTORE VOLUME ボリューム名 MAXPROCESS=プロセス数

8. リストアが完了すると、コピーボリュームはオフサイトに送り返す必要があります。まず、ステップ5で使用したすべてのボリュームをACCESS=OFFSITEに変更します。こうすることで、レクラメーション実施時にサーバーが使用することがなくなります。

   UPDATE VOLUME * ACCESS=OFFSITE WHERESTGPOOL=コピープール名

9. コピープールボリュームをチェックアウトします。これで安全な場所に配送することが出来ます。

   CHECKOUT LIBVOLUME ライブラリ名 ボリューム名 CHECKLABEL=NO

10. このコマンドは、破損したプライマリーボリュームにファイルがまだ存在するとTSMサーバが報告した時に、破損したボリュームにのみ実行する必要があります。これは、前回のバックアップストレージプールコマンドに問題があった場合や、このボリューム上のデータがまだコピーストレージブールにコピーされていなかった場合に生じます。これらのファイルがまだクライアントにあるのであれば、次回の増分バックアップ時にバックアップされてくるはずです。
    

    DELETE VOLUME ボリューム名 DISCARD=YES

【訳注】 「Kornシェルスクリプト入門 Part 2」の続きのエントリーです。

標準入力、標準出力、標準エラー

これらを理解するのは必須です。基本的に入出力には3つの出力元が存在します。AIXでは、STDIN、STDOUT、STDERRと呼ばれています。STDINは、キーボードを通じてあなたが入力した内容を参照します。STDOUTはコマンドが実行された時にスクリーンに表示される出力のことです。STDERRはコマンドが失敗した時にスクリーンに表示されます。STDINとSTDOUTとSTDERRファイルディスクリプターはそれぞれ、1、2、3という番号にマッピングされています。

コマンドの実行結果が成功か失敗かを確認したい場合は、Listing 9のようなやりかたをします。

$date  /dev/null 2>&1  # このコマンドのすべての出力を見られないようにする

if [[ $? = 0 ]]; then
      print "date コマンドは成功しました"
else
      print "date コマンドは失敗しました"
fi

このコードでは、AIXのdateコマンドを実行しています。STDOUT（ファイルディスクリプター1）またはSTDERR（ファイルディスクリプター2）の出力は見られないようにすることが出来ます。続いて、条件付きif文でこのコマンドのリターンコードを確認しています。以前に学んだように、コマンドが「0（ゼロ）」を返せば、成功です。ゼロ以外では失敗となります。

関数

Kornシェルスクリプトでは、functionという言葉は予約語になっています。関数はスクリプトをセグメントに分割するための手法の一つです。これらのセグメントは、関数をコールした時のみ実行されます。これまで作ってきたコードにエラーチェックの関数を作成しましょう。Listing 10をご覧下さい。

Listing 10: エラーチェック関数

##################
関数 if_error
##################
{
if [[ $? -ne 0 ]]; then # 関数に渡されたリターンコードをチェックする
    print "$1" # リターンコードがゼロより大きい場合にはエラーメッセージを出力し、処理を抜ける
exit $?
fi
}

もし、スクリプト内で単純にコマンド実行させたいと考えたならば、上記のように$?でエラーチェックするようなコードを簡単に作成することが出来ます。処理が失敗したかを確認したい場合は、その度にif_error関数を呼び出すだけで済みます。Listing 11をご覧下さい。

Listing 11: if_error関数をコールする

rm --rf /tmp/file #ファイルの削除
if_error "エラー: /tmp/file の削除に失敗しました"

mkdir /tmp/test #ディレクトリー作成
if_error "エラー: /tmp/testの作成に失敗しました"

上記のコマンドを実行する度に、if_error関数がコールされます。エラーチェックの際に特定のメッセージを表示させたい場合は、if_error関数にメッセージを渡すことも出来ます。これが優れている点は、一度シェルコードを書いてしまえば、何度も何度も同じエラーチェック機能を使いまわし出来る点です。こうすればシェルスクリプトの作成は早くかつ簡単になります。

case文

case文は、if文を使っていた場所に使うことが出来る別の条件判定文です。case文は、caseという文字で始まり、文字を逆さまにした「esac」という文字で閉じられます。case文を使えば、スクリプトを発展させ、他のタスクを実行させる際などに素早く開発することが出来ます。Listing 12はcase文の仕組みの例です。

Listing 12: case文

case 値 in 
"パターン1")
 値が「パターン1」と合致した際に実行されるコマンド
 ;; 
esac

それでは、同じ日の異なる時間にファイルを削除したいとします。現在時刻をチェックするための変数はこのように設定できます。

TIME=$(date +%H%M)

Listing 13で紹介しているコードは、午後10時と午後11時にファイルを削除してくれます。そのため、該当時間帯にこのコードが実行されると、$TIMEの現在時刻とcase文の時間が合致しているかを確認します。そして、時間が合致していればコードは実行されます。

Listing 13: 時間をチェックするcase文

case $TIME in
                 "2200") #午後10:00の意味
                  rm ?rf /tmp/file1
                        ;;
                  "2300")#午後11:00の意味
                  rm ?rf /tmp/file1
                        ;;
                    "*")
                        echo "何もしない" > /dev/null
                        ;;

esac

すべてのスクリプトを一つに

これまであなたが作ってきたスクリプトヘッダーと変数と式を組み合わせて、Listing 14のものを作ってみましょう。

Listing 14: Kornシェルスクリプトの例

$vi my_second_script.ksh
#!/bin/ksh
###################################################
# 作者： Jason Thomas
# 目的： ユーザーに初めてのスクリプトの作成方法を見せるためのスクリプト
# 2008年5月1日
###################################################

#変数定義
HOME="/home/jthomas" #ホームディレクトリー 
TIME=$(date +%H%M) # DATEにシェルコマンドのdateの出力結果と同じものを代入
HOSTNAME=$(hostname) # HOSTNAMEにhostnameコマンドの出力結果と同じものを代入する

##################
関数 if_error
##################
{
if [[ $? -ne 0 ]]; then # 式に渡されたリターンコードをチェックする
    print "$1" # リターンコードが0以外ならば、エラーメッセージを表示して処理を抜ける
exit $?
fi
}

if [[ -e /tmp/file ]]; then  #ファイルが存在するか最初に確認する
   rm ?rf /tmp/file #ファイルを削除する
   if_error "エラー： /tmp/fileの削除に失敗しました。"
else
   print "/tmp/fileは存在しません。"
fi

if [[ -e /tmp/test ]]; then
     mkdir /tmp/test #testディレクトリを作成する
     if_error "エラー： /tmp/testディレクトリの作成に失敗しました。"
else
     print "ディレクトリがすでに存在します。ディレクトリを作成する必要はありません。"
fi

case $TIME in
                 "2200")
                  rm ?rf /tmp/file1
                        ;;
                  "2300")
                  rm ?rf /tmp/file1
                        ;;
#スクリプト終了
esac

スクリプトを実行するには、単純に「./スクリプト名.ksh」とタイプするだけです。

$./my_second_script.ksh

コマンドラインからの入力内容をスクリプトに渡す

コマンドライン上であなたが入力した内容をスクリプトが受け取るようにすることが出来ます。Listing 15をご覧下さい。

Listing 15: スクリプトに入力内容を渡す

$vi scriptname.ksh
#!/bin/ksh

OPTION=$1

print "I love $OPTION"

$./scriptname.ksh milk
I love milk
$./scriptname.ksh tea
I love tea
$./scriptname.ksh "peanut butter"
I love peanut butter

スクリプトに値を引き渡す時、スクリプト名の後ろの最初のオプションは$1と呼ばれます。同じく2つ目以降のオプションは$2、$3と続きます。これを知っていれば、スイッチやオプションを持つUNIXコマンドと同じようにスクリプトを作成することが出来ます。

スクリプトからEメールを送る

スクリプトでいくつかの種類のレポートを作成するようにすることが出来ます。例えば、システムに新しいユーザーが登録されたかどうかを毎日トラッキングするスクリプトがあります。このスクリプトはファイルに結果を出力し、それをあなた自身に送信します。こうすることで、あなたは毎日、システムに追加された全ての新ユーザー情報のコピーを受け取ることが出来ます。これを実現するには、以下のようなコマンドを実行します。

$REPORT="/tmp/users"

cat $REPORT | mailx ?s "User admin report from server XYZ" Jason_Thomas@kitzune

これにより、$REPORTファイルのコンテンツがEメールであなたに送られます。「-s」はEメールの件名を表しています。これはとても使い勝手のいいスクリプトです。

最後に

Kornシェルスクリプトを作成すれば、多くの無駄な時間が省かれ、あなたの仕事はより簡単になると思います。最初は躊躇するかもしれませんが、簡単なものから始め、一行一行積み重ねていくことです。いつでもこのステップは忘れないで下さい。スクリプトヘッダーを作成し、変数を定義し、作品のエラーチェックを行う。いつか、あなたは自分がやっている全てのことをスクリプトで書こうとしているかもしれません。