Job IDを指定してジョブの作業ディレクトリを開くコマンド

torque shellscript

これまたバッチシステムtorqueのニッチなネタ．
一ヶ月以上回り続けているジョブなんかは一体どのディレクトリで作業していたかすら忘れているもんです．
そんなとき，qstatで確認できるJob IDをキーにして，ジョブのある作業ディレクトリ($PBS_O_WORKDIR)に
移動できるといいなぁとおもいました．

書きました．

qdir.sh


実行例

source ./qdir.sh #関数qdirを使えるようにする
qdir 30   #specified Job ID

長いJobnameのジョブを一覧表示するawkスクリプト

torque awk

現在投入されているジョブ一覧を表示してくれるqstatというコマンドがあるが-aオプションを使ってもJobnameを最長15文字しか表示してくれない．15文字を超えるような名を持つ化学構造の計算を，ちょっとずつ条件を変えてジョブに大量投入なんてやった日には，qstatで状況をチェックしようにも区別できなくなって不便．
そんなときのためにqstat -fの出力を使って好きなだけ長い文字数でJobnameを表示するawkスクリプト書いた．

qstatL.awk


実行

qstat -f | awk -f qstatL.awk

出力例

60    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   ufssf   R 1
61    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   ufssf   R 1
62    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   ufssf   R 1
63    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   ufssf   R 1
64    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   ufssf   R 1
65    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   ufssf   R 1
66    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   ufssf   R 1

DB間でテーブルをまるごとコピーする(注意事項あり)

mySQL

DB操作に関わる作業をしているとき、現在運用中のテーブルをそのまま弄るのは色々怖い。
そんな場合は、開発用テストDBを作っておき、そこに本番のテーブルをコピーして弄るのが良いと思う。
以下やりかた。

DB DB名
本番DB production
開発DB dev

productionにあるテーブルtest_tableをdevにコピーしたいとする

CREATE TABLE dev.test_table SELECT * FROM production.test_table;

※注意
AUTO_INCREMENTやDEFAULT CHARSETなどの属性はコピー先へ引き継がれない。別途設定が必要です。
属性が落ちていることに気づかず、DB周りのエラーで数時間ハマった。
例えば、

CREATE TABLE test_table (
    id BIGINT AUTO_INCREMENT,
    user_id BIGINT,
    title VARCHAR(255),
    body LONGTEXT, 
    INDEX user_id_idx (user_id), 
    PRIMARY KEY(id)
    ) 
ENGINE = MyISAM DEFAULT CHARSET = sjis;

なtest_tableをコピーすると、下のようになる。

#コピー元

mysql> show create table dev.test_table
    -> ;
+--------+----------------------------------------------
------------------------------------------------------+
| Table  | Create Table
                                                      |
+--------+----------------------------------------------
------------------------------------------------------+
| test_table | CREATE TABLE `test_table` (
  `id` bigint(20) NOT NULL auto_increment,
  `user_id` bigint(20) default NULL,
  `title` varchar(255) default NULL,
  `body` longtext,
  PRIMARY KEY  (`id`),
  KEY `user_id_idx` (`user_id`)
) ENGINE=MyISAM DEFAULT CHARSET=sjis |
+--------+----------------------------------------------
------------------------------------------------------+

#コピー先

mysql> show create table production.test_table;
+--------+----------------------------------------------
---------------------------------+
| Table  | Create Table
                                 |
+--------+----------------------------------------------
---------------------------------+
| test_table | CREATE TABLE `test_table` (
  `id` bigint(20) NOT NULL default '0',
  `user_id` bigint(20) default NULL,
  `title` varchar(255) character set sjis default NULL,
  `body` longtext character set sjis
) ENGINE=MyISAM DEFAULT CHARSET=utf8 | #色々な属性が落ちてしまっている
+--------+----------------------------------------------
---------------------------------+

うーん。属性を保ったままテーブルをコピーする方法はあるんだろうか。

リポジトリにあげたくないファイルの変更を除外してコミットする

subversion

コードをsubversionで管理しているけれど、httpd.confみたいなサーバに固有の設定ファイルを修正したあとコミットしたくないときがある。
それに相当する機能はtortoisesvnについてるignore-on-commitという機能なんだけど、普通のsubversionでそれを実現する方法がわからないので、svn statusからawkとか使って指定ファイルをコミットから除外する方法を考えた。
以下がそのコマンド

svn ci `svn status |egrep -v 無視したいファイル名| awk '($1~/(M|A)/){print $2}'`

複数無視したいファイルがあるときは、例えば~/sciprt/ignoreに"|"区切りで無視したいファイルのパスを記述して下みたいに
書いてやればよい。

svn ci `svn status |egrep -v $(cat ~/script/ignore) | awk '($1~/(M|A)/){print $2}'`

うーん…
もっと良いやり方あるのかな。

.gitignoreをリロードする

git

.gitignoreに無視ファイルを追加したのに、その指定がうまく反映されないとき…

caching - Ignore files that have already been committed to a Git repository - Stack Overflow

インデックスを一度削除してから再pushする。

git rm -r --cached .
git add .
git commit -m ".gitignore is now working"
git push origin master

注意：git rm -r --cached .するとコミットしていないコードの変更も消え去ります。大事な作業分が消えないよう予め確認してから。

他人のリポジトリにpull requestしてバグフィックスを取り込んでもらった

git github

OmniAuthのmixiストラテジがおかしかったので修正したのです。
http://d.hatena.ne.jp/hosopy/20111014/1318596206
↑の方の修正を勝手ながら取り込ませて頂きました。
事後報告になってしまいすいません！ > id:hosopy


以下バグフィックスをpull requestするまでの流れ。
超めんどいかと思ったけど以外と簡単でした。

fork

開発元のリポジトリから自分のところに持ってきます。
githubでforkボタンを押すだけ。

git clone

git clone git@github.com:ufssf/hogehoge.git

自分のところに持ってきたリポジトリをローカルに持ってきます。

バグ修正用のブランチを切る

git checkout -b bugfix #bugfixブランチを作る

修正、コミット、push

vim hogehoge.hoge #修正
git commit -am "fix for hogehoge"
git push origin bugfix

pull request


github上で自分のリポジトリを開いてpull requestボタンを押します。

どのブランチをマージするのか選択します。
選択後、変更概要の画面が開きます。
requestと同時にissue trackingに投稿されるメッセージに
バグフィックスの概要を書きます。
pull requestを送る前に、念のため差分を確認しておきます。
ローカルで開発している間に本流のリポジトリに更新があった場合、
コンフリクトが起こる可能性があるので。

全裸待機

開発者がmerge pull requestしてくれるのを待ちます。もしかしたら
コードのおかしいところを指摘される可能性があるので、pull request後も
事の進展を注意深く見守るべきです。

参考文献

2011-05-28
今回は1ファイルの修正だけで済み、修正時間も一瞬だったのでコンフリクトはなく、大して気を使う必要が
ありませんでした。修正が多く時間がかかる場合は、上の記事を熟読しておいたほうがよいと思います。