for文とかで使うセミコロンの位置

最近は、スクリプトが熱いですね。LLの基本はshにあると実感する今日この頃。そんな中、同僚がseqというコマンドを教えてくれた。

$ seq 10
1
2
3
4
5
6
7
8
9
10

数字を出力するだけのコマンド。最初なんのために使うんだと思ったけどもすぐにfor文で使うんだなと予測できた。

こんな感じ？

for i in `seq 10`
do
echo $i
done

別の書き方。doの位置が行末にあるバージョン。

for i in `seq 10`; do
echo $i
done

個人的にはこっちの方がすっきり見えて好きなんだけど、セミコロンの位置がわかりづらい。こんなのすぐ忘れるよって思った。

for i in `seq 10` do
echo $i
done

これじゃダメなの？って思うよね。でも、今回for文の構文を見直してみたら、3つの文から構成されているとことに気づいて合点がいった。

1行目:for $var in $wordlist
2行目:do $command
3行目:done

3つの文（命令？）から構成されているから、続けて書く場合にはそれぞれにセミコロンが必要になる。

だから一行で書くと次のようになる。

$ for i in `seq 10`; do echo $i; done

このようにfor文は三つ文（コマンド？）で成り立っているのである。これでセミコロンの位置について記憶が曖昧になることはないだろう＾＾。

応用してwhile文を一行で書くとこうなる。

$ while :; do echo hoge;done

:はなにもしない命令。

ちなみに俺はdoは行末にあるのが好き。doを改行するスタイルは冗長に見えてしまう。

for i in `seq 10`
do
echo $i
done

for (int i = 0; i < 9; i++)
{
System.out.println(i);
}

この書き方はjavaやc言語で書いてるぶんにはすっきりして良いのだが、シェルスクリプトで再現すると、中括弧を無理やりdoとdoneで置き換えた感じで嫌。

やっぱりjavaでいく行末カッコの以下の書き方の方が好きだな。

for (int i = 0; i < 9; i++) {
System.out.println(i);
}

for i in `seq 10`; do
echo $i
done

ということでif文も次のようなスタイルです。

if [ -f hoge.txt ]; then
echo 'exist!'
fi

antプロジェクトmaven化してみた。

仕事で使ってる社内のjavaライブラリがあるんだけどこれが昔ながらのantのみのモジュールでつくられていた。まぁわざわざmaven化するほど困ってるわけではないんだけども、このライブラリはいくつかのプロジェクトで利用されていて、バージョン管理とかをきちんとしたいのとmavenの練習になるかなってことでこのプロジェクトをmaven化してみた。

依存ライブラリの解決

まずは依存*1しているライブラリの洗い出し。

最初、eclipseのmavenプラグインを使ってEclipseから検索してpom.xmlを書き換えてたんだけど、途中でなぜかバグって依存ライブラリの記述が全部消えたorz。なんというかEclipseのプラグインって完成度がまちまちだからこういうことがよくあるんだよな。これでますますEclipseを離れたくなった。Eclipseも嫌いじゃないけど、やっぱ俺はemacsラブ。marabal-mode最高...と言いたい。

ということで素直に下記サイトで地味に検索して依存関係を潰していった。

http://mvnrepository.com/

このサイトの検索ボックスにライブラリの一部の文字列を入力すると検索結果がでるのでそこからめぼしのものを選んでdetailリンクをクリックすると、pom.xml用のタグが表示される。mavenのリポジトリは他のツールでも利用してるらしくmaven用ツールのほか、いろいろな依存関係の記述例が表示されるのが気になった。

これら依存関係のタグをpom.xmlにコピペしてその都度

$ mvn compile

していきながらコンパイルが成功するまで地味な作業の繰り返していった。

java-mail

その途中でjava-mailの依存関係を解決できなかった。このjarはmvnrepository.comの検索では見つかるものの、いざコンパイルをかけるとダウンロードでこけてしまう。ここをみるとライセンス的に怪しいという。

http://d.hatena.ne.jp/shinsuke_sugaya/20060503/1146608133

もともとmvnrepository.comにあったものが、移動したのだろうか？

その後、ググッて見つけた以下を参考にして新しくリポジトリを追加することで解決した。

http://d.hatena.ne.jp/Aileron/20091207/1260175613

<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4.2</version>
</dependency>

<repositories>
<repository>
<id>maven-repository.dev.java.net</id>
<name>Java.net Maven Repository</name>
<url>http://download.java.net/maven/2/</url>
</repository>
</repositories>

joglのリポジトリ

ところでこのリポジトリのURLはjava.netである。たしかjoglがjava.netで開発されてたので気になって検索してみたらあった。

http://download.java.net/maven/2/net/java/jogl/jogl/

joglもjava.netのリポジトリには登録されてるのね。rcというのが気になるけどこれを気にjoglのmavenを使ったビルド環境をもう一度見直してみよう。

社内リポジトリ

とまぁそんな地味な作業を重ね、ビルドが成功するようになった。完成したjarを社内リポジトリにインストールしたい。

## jarを生成
$ mvn package

まず、mavenの社内リポジトリをおく場所。これはsvnリポジトリをおいてる場所と同じにした。このsvnにはssh経由でアクセスしてunixユーザの権限で管理しているのでmvnリポジトリも同様にしたい。

リポジトリID	hoge.com
リポジトリURL	ssh 192.168.1.1:/usr/local/maven2repo

そこでまずリポジトリ用のディレクトリを作成した。

$ ssh -A 192.168.1.1
$ cd /usr/local/
$ sudo mkdir maven2repo
$ sudo chown -R root:dev maven2repo
$ sudo chmod -R 774 maven2repo
$ sudo chmod g+s maven2repo

devグループに属す人なら誰でもアクセスできるようにしたつもり。

で、今回maven化したプロジェクトのpom.xmlに以下のように登録先の情報を記述する。

<distributionManagement>
<repository>
<id>hoge</id>
<name>Hoge Repository</name>
<url>scpexe://192.168.1.1/usr/local/maven2repo</url>
</repository>
</distributionManagement>

ビルド作業しているホストの以下のディレクトリにsettings.xmlを準備する。

• ~/.m2/settings.xml

<?xml version="1.0" encoding="UTF-8"?>
<settings>
<servers>
<server>
<id>hoge.com</id>
<username>${username}</username>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
<configuration>
<sshExecutable>ssh</sshExecutable>
<scpExecutable>scp</scpExecutable>
</configuration>
</server>
</servers>
</settings>

デプロイコマンドは以下

$ cd ~/dev/goocore
$ mvn deply

以上でデプロイ完了

今回ハマったのは、ssh -A のようにエージェントフォワードしてる環境でのscpによるデプロイ方法。ググッてすぐに出てくるのはみな、usernameとprivatekeyのパスを設定する例ばかりで、今回のように鍵はエージェントフォワードしてる場合の設定例がなかなか見つからない。そんななか下記の参考を発見できたおかげで無事解決できた。感謝です！てかマニュアルちゃんと読めって話だよね。

http://yasushi.stbbs.net/c/articles/2006/03/23/%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%AE%E4%BD%9C%E3%82%8A%E6%96%B9

所感

今回の作業のなかでivyというビルドツールの存在を知ったのだが、これがなかなか良さげ。このツールはantのタスクで、mavenのリポジトリを流用してjarの依存関係を解決してくれる。対するmavenは確かに便利なんだけども、依存関係の解決以外にたくさんの機能が備わっててものすごく大袈裟に見える。そもそもこれらの機能はほとんどど使わないし、中身はブラックボックスだからビルド方法を変えようと思っても気軽に拡張できない。その点ivyはantのいちタスクであるため、見通しもいいし簡単にビルドルーチンを改造できる。仕事で使ってるプロジェクトはどれも小規模なものばかりなので、mavenではオーバースペックかもしれない。そう考えると、ほんとに大規模なプロジェクト以外はどれもantですまして、必要に応じてivyを使ったりするのがべストかもしれない。mavenには豊富なプラグインが用意されていてリリースツールや継続的インテグレーションツールなどとの連携が充実してるように見える。しかし、これについてはantにもいえそうなことで、大抵antタスクがあるような気がする。逆にmavenからの利用だと導入コストが高そう。軽量そうなivyと重厚なmaven。どちらかというとivyのほうが魅力的に思える。とはいってもmalabar-mode使うにはpom.xmlが必要だから結局mavenを使いそうだけども。

ivyとかビルドのことについて、以下のサイトとその先の紹介サイトが大変参考になりました。

http://d.hatena.ne.jp/wyukawa/20101122/1290440174

*1：どうでもいいけど「依存」って「いそん」て読むんだよね。「既存」も「きそん」。アナウンサーとかの発音きくとわかるよ。この業界「既存」を使うことが非常に多いんだけど、いまだかつて「きそん」と発音する人を見たことががない。ただし「保存」は「ほそん」ではなくて「ほぞん」だよ。