f

2016-08-25

How to check root user in POSIX Shell script

シェルスクリプトなどで現在のユーザーがルートユーザー(root権限,管理者権限,スーパーユーザー,super user)であるかを判別する方法を記す。

例えば,システムやデバイスの操作を行いたい時には,sudosuコマンドによりルート権限を取得してからコマンドを実行する。これをシェルスクリプトで実装するには,スクリプト内で現在のユーザーがルートユーザーかどうかを判定して,ルートユーザーでなければ処理を中断させるのが一つの方法だ。そこで,現在のユーザーがルートユーザーであるかを判別する方法が必要となる。

結論を書くと,以下のPOSIX準拠の構文により実現できる。

if [ $(id -u) = 0 ]; then
echo "I am root user: $(id -nu)."
fi

root権限ではuser ID(UID)が0であることがPOSIXで保証されていることを利用している。このことは,WikipediaのUser identifierのページで言及されている。引用元のPOSIXのgetpwuidコマンドのページを確認すると,以下のとおりに確かにroot権限ではUIDは0となると明記されている。

The following example gets the user database entry for the user with user ID 0 (root).
getpwuid

UIDの取得にはPOSIX準拠コマンドであるid -uにより取得できる。ユーザー名の取得は-n(name)オプションを一緒につければ取得できる。

ネットの情報だと,他にもUID変数やEUID変数,whoamiコマンドを使ったり,ルートユーザー名がrootであることを利用した判別を行っている。

参考:

しかし,これらの変数,コマンド,名前はPOSIXで未定義なので,他の環境での動作が保証できない。そのため,特に他の理由がなければ,[ $(id -u) = 0 ]により判別すべきだろう。

2016-08-20

Python "if __main__" in Node.js and WSH JScript

Pythonでは現在のプログラムが実行されていることを判別する構文がある。

if __main __ == "__main__":
print("module is runninng")
else:
print("module is included")

__main__という特殊変数に,そのファイルが実行されていれば,"__main__"という文字列が格納されていることを利用している。

これにより,ライブラリとして読み込んだ時と実行時とで処理を分けることができる。この構文により,例えば実行したらテストを動したり,サンプルの処理を行うことができ,そのファイル(ライブラリ)自体の動作の説明を行うことができる。ライブラリとして使うことを想定するプログラムでは便利だ。

この構文をJavaScript(Node.jsとJScript)で実現する。

if __main__ in Node.js

Node.jsでは以下のどちらかの構文により実現できるようだ。

if(require.main === module) {
  cocnsole.log('main module');
}
if(!module.parent) {
  console.log('main module');
}

参考:node.js equivalent of python's if __name__ == '__main__' - Stack Overflow

if __main__ in JScript

JScriptであれば,WScirpt.ScriptNameプロパティに現在実行中のプログラムのファイル名が入っているので,これを利用する。例えば,以下のように記述する。

// \file hi.js

if (WScript.ScriptName === "hi.js"){
WScript.Echo("Hello");
}

Node.jsでの例と違い,自分自身のファイル名をハードコード(直接入力)しなければならず,少しいまいちなやり方となってしまう。しかし,こうしなければならない。つまり,以下のようにNode.jsでの例と同じように変数名の有無で判定すると,親から読み込んだ場合でも実行されてしまう。

if (WScript.ScriptName){
WScript.Echo("Hello");
}

なぜなら,親から実行した場合には,WScript.ScriptNameには親のファイル名が入っているからだ。

これを確かめるには,以下のサンプルファイルを実行すればわかる。

/// \file is_sample_main.js

if (WScript.ScriptName){
  WScript.Echo('Failure');
}

if (WScript.ScriptName === "is_sample_main.js"){
  WScript.Echo("Not shown");
}
<?xml version="1.0" encoding="UTF-8"?>
<!-- \file is_sample_main.wsf -->
<package>
  <job>
    <script language="JScript" src="is_sample_main.js"></script>
 </job>
</package>

上記2ファイルを作成して,is_sample_main.wsfをダブルクリックか以下のコマンドでコマンドプロンプトから実行する。

cscript.exe -nologo is_sample_main.wsf
Failure

is_sample_main.wsfでは,is_sample_main.jsを読み込んで実行しているので,is_sample_main.wsfは親ファイルとなる。そのため,WScript.ScriptNameで条件分岐させた処理は実行してほしくない。しかし,WScript.ScriptNameだけの条件分岐に入り,実行されてしまっていることがわかる。

参考:javascript - JScript - How to know if the script was activated using WSH or internally by another script? - Stack Overfl

Create Library

ここまでで,Node.jsとWSH JscriptでPythonのif __main__ == "__main__"を実現する方法を示してきた。ただ,毎回手作業で書くには少々長い。そこで,これを実現する関数を作ってライブラリ化してみる。

/****************************************************************************
 \file      is_main.js
 \author    SENOO, Ken
 \copyright CC0
*****************************************************************************/

function is_main(this_file_name){
    return (typeof(module ) !== "undefined" && !module.parent    ) ||
      (typeof(WScript) !== "undefined" && WScript.ScriptName === this_file_name)
}

if (typeof(print) === "undefined"){  // for SpiderMonkey
  function print(text){
    if      (typeof(console) !== "undefined") console.log(text );
    else if (typeof(WScript) !== "undefined") WScript.Echo(text);
  }
}

if (is_main("is_main.js")){
  print("Hello");
}

上記のis_main.jsでは,is_main関数を定義している。引数に自分自身のファイル名を渡せば,Node.jsとWSH Jscriptの両方のif __main__ "== __main__"を評価してその結果を返してくれる。汎用化させるために,条件式の最初にNode.jsやWScirptが使えるかどうかを判定している。

また,後半では以前以下の記事で作成したprint関数を再掲している。これにより,コード末尾の自分自身が実行されている時だけメッセージを表示させることを,Node.jsでもWSH Jscriptでも動作するようにしている。

参考:My Future Sight for Past: JScriptのWScript.Echo()とJavaScriptのconsole.log()の共通化

Conclusion

JavaScriptであるNode.jsとWSH JScriptで,ライブラリ自体が実行されているかを判別するPythonのif __main__ == "__main__"を実現する方法を紹介した。今後これらの言語でライブラリを作成するときは活用してみたいと思う。今回紹介したコードはgistでも公開しているので必要に応じてダウンロードしてほしい。

GitHub GIst: Python "if __main__" in Node.js and WSH JScript

2016-08-16

KaoriYa版Vimの独自設定を無効化する方法

WindowsにおけるVimとしては,KaoriYaで配布されているVim(KaoriYa版Vim)が日本では有名だ。

KaoriYa版では使いやすいように公式とは異なるKaoriYa独自の追加設定がなされている。通常であれば,使いやすくなるので問題ないが,一部自分の設定に影響を及ぼしてしまう。このKaoriYa独自設定を無効化したくなったのでその方法を調べた。

2016-08-17T22:00追記:確認にはVim 7.4.1944 +kaoriya (2016-06-20)を使った。

端的に結論を書くと,以下のコマンドをコマンドプロンプトから実行して,KaoriYa版Vimと同じ場所に無効化のための設定ファイルを作ればいい。

REM VIM変数にKaoriYa版Vimの配置場所を指定。例:C:\Users\senooken\local\opt\vim74-kaoriya-win64
set VIM=%USERPROFILE%\local\opt\vim74-kaoriya-win64

echo let g:vimrc_local_finish = 1 > %VIM%\gvimrc_local.vim
echo let g:gvimrc_local_finish = 1 > %VIM%\vimrc_local.vim

KaoriYa版Vimを普段使わない理由と使う理由

個人としては,2年ほど前まではKaoriYa版Vim(GVim)を使っていた。しかし,途中からChocolateyでインストールできることに気づいたので,公式で配布されているVimに切り替えた。公式のVimに切り替えた理由は以下2点だ。

  1. 公式のインストーラーを使えば,右クリックにメニューが追加され便利。
  2. 派生版よりも公式を使ったほうが安心。

第1の理由だが,公式版のVimをインストールすれば,ファイルを右クリックしたときに,[Edit with Vim]というメニューが表示され,これを選ぶことで素早くどんなファイルでもGVimで開くことができる。KaoriYa版GVimでは右クリックのメニューには登録してくれないので,右クリックメニューで使えるようにするには以下のどちらかの方法で自分で設定することになる。

  • 自分でレジストリーをいじって登録
  • 右クリック→[送る]の候補に登録

後者の[送る]メニューへ登録するには,%AppData%\Microsoft\Windows\SendToディレクトリ(エクスプローラーのアドレスにshell:sendtoでもアクセス可能)にgvim.exeのショートカットを配置すればいい。この方法なら管理者権限も不要で簡単だ。しかし,[送る]メニューは右リックメニューの真ん中から下の方に表示されるので,アクセスしにくい。

2016-08-16T23:30追記:なお,右クリックメニューにこだわらなければタスクバーに登録したアイコンからGVimを起動して,ファイルをGVImにドラッグドロップすることでも,素早くアクセスできる。しかし,GVimの起動のためにマウスカーソルをタスクバーに移動させると気が散るのであまりよくない。

右クリックからGVimを使うときのメニュー

第2の理由としては,KaoriYa版独自の設定は使わないほうがいいと思ったからだ。例えば,KaoriYa版のVimではfileencodingjapanという値を使える

2016-08-16T23:30追記:コメントでの指摘のとおり,encodingの値としてjapanはVimの公式設定として利用可能な値だ(:help encoding-values)。ここは,KaoriYa版ではfileencodingsの値に,guessが使えるという記憶違いだった。KaoriYa版の独自設定は,当てているパッチをみれば原理的にはわかるらしいが,Vimのソースに関する知識がいるので理解するのは簡単ではない。公開日が2009年と少し古いが,以下の記事でKaoriYa独自機能について解説されているのでわかりやすい。

KaoriYa 版で追加される機能まとめ - 永遠に未完成

この記事で紹介されている通り,KaoriYa版どうかはif has('kaoriya') ... endifで判別できるので,KaoriYa版独自機能を使うならば,このように条件判定を行ってから使い,公式版のVimでも動作するようにしよう。

しかし,当然ながらこの設定はVimのヘルプには掲載されていない。そのため,例えば,外人やVimをよく知らない人がこの設定をみたら意味を理解するのが極めて難しくなる。だから,このような公式で提供されていない非標準設定の利用は控えるべきだろう。

上記2点の理由から普段はKaoriYa版Vimは使っていない。ただし,KaoriYa版Vimでなければならない場面が1箇所ある。それは,管理者権限が使えない場面だ。管理者権限が使えない状況というのは,例えば会社や共有のパソコンなどでの利用が想定される。管理者権限が使えなければ,公式で配布されているイン ストーラーでインストールすることができない。実際は,公式ではこのことを考えて解凍するだけで使えるバイナリ版も配布している。しかし,これは使わないほうがいい。なぜか?それは,公式の単独パッケージでは以下2点の問題があり極めて使いにくいからだ。

  • バージョンが古い。
  • syntaxやplugin,diff.exeなど通常であれば付属する標準設定・プラグインや標準コマンドが付属しない。

このことから,管理者権限が使えない場面や,レジストリーを汚したくない,携帯性を高めたいという場面においてはKaoriYa版Vimを使うしかない。そのため,会社ではKaoriYa版GVimを使っている。

2016-08-16T23:30追記:コメントでの指摘で初めて知ったが,現在の最新の公式のWindows版VimのNightly BuildがGitHubで配布されているようだ。ここからであれば,必要な付属品が全て同梱されたバイナリーが入手できることを実際にダウンロードして確認できた。指摘をくれたkaoriyaさんにツイートで教えてもらったが,VimのWebページではアナウンスしておらず,メーリングリストでお知らせがあったようだ。

Releasesのページを確認したところ,2016-01-27のv7.4.1185からバイナリー版の配布を始めたようだ。約半年前の今年に入ってからなので比較的最近配布されるようになったようだ。

KaoriYa版Vimの問題点

しかし,KaoriYa版Vimでは前述の通り独自設定がなされており,場合によっては自分の設定と競合することもあるだろう。実際に僕には問題となった。具体的には,gvimrcで設定されているcolorscheme morningの設定だ。

普段は~/.vimrcに以下の設定を記述することで,VimとGVimの両方でカーソル行を薄水色でハイライトするようにしている。

set cursorline  " hightlight cursor line
highlight CursorLine cterm=NONE ctermbg=LightCyan guibg=LightCyan

公式のVimとGVimを使う限り,この設定で何も問題はない。しかし,KaoriYa版GVimでだけ,カーソル行のハイライトがmorningのカラースキームで上書きされてしまう。

回避策としては,~/.gvimrcにも上記のハイライト設定を記述することで,KaoriYa版GVimで設定されたハイライト設定をさらに上書きする方法がある。しかし,公式版のVimでは正常に動作しているのに,日本独自のKaoriYa版Vimのためだけにこのような設定をするのは好ましくない。それに,今まで~/.vimrcの一箇所の設定だけで済んでいたのに,同じ内容を~/.gvimrcにも記述する必要があり,保守性が悪くなってしまう。

2016-08-16T23:30追記:コメントでの指摘のとおり本来であれば,GVim固有の設定は~/.gvimrcに記述すべきであり,このことは以下のとおり公式でも推奨されている。

The gvimrc file is where GUI-specific startup commands should be placed.

:h gvimrc

しかし,:highlightのハイライト設定に限れば,VimとGVimとで同時に設定でき,例えばcolorschemeの設定などで分けて書くのはあまり現実的ではない。だから,~/.vimrcの設定をそのまま使いたい。

KaoriYa版Vimの独自設定の無効化方法

幸いなことに,KaoriYa版の設定を無効化する方法があるので,この方法で対応する。

無効化の方法は,KaoriYa版に付属するvimrcgvimrcの冒頭に記載されている。内容をまとめると以下の表のとおりとなる。

Kaoriya版Vimの独自設定の無効化条件

vimgvim
グローバル設定
  • g:vimrc_local_finishの値が非0
  • $VIM/vimrc_local.vimが存在
  • g:gvimrc_local_finishの値が非0
  • $VIM/gvimrc_local.vimが存在

ユーザー設定
  • g:vimrc_first_finishの値が非0
  • $HOME/.vimrc_first.vimが存在
  • g:gvimrc_first_finishの値が非0
  • $HOME/.gvimrc_first.vimが存在

変数$VIMはKaoriYa版のvim.exeやgvim.exeの配置場所を表す。上記設定を簡単に実現するならば,例えばvimrc_local.vim内にlet g:vimrc_local_finish = 1と記述すればよい。ユーザー設定ファイル.vimrc_first.vimも一応使えるが,ホームディレクトリをあまり汚したくないのでグローバル設定で対処した。

同様の設定をgvimrcに対しても設定すればいい。手作業でやってもいいが,面倒なのでコマンドプロンプトで以下のコマンドを実行してvimrc_local.vimを作成してやればKaoriYa版Vimの独自設定の無効化は完了だ。

REM VIM変数にKaoriYa版Vimの配置場所を指定。例:C:\Users\senooken\local\opt\vim74-kaoriya-win64
set VIM=%USERPROFILE%\local\opt\vim74-kaoriya-win64

echo let g:vimrc_local_finish = 1 > %VIM%\gvimrc_local.vim
echo let g:gvimrc_local_finish = 1 > %VIM%\vimrc_local.vim

自分にはKaoriYa版のgvimrcの設定だけが問題だったので,gvimrcだけ無効化した。

グローバル変数の設定だけで済むのならば,自分の~/.vimrcに以下を追記してやるだけで済む。

let g:vimrc_local_finish  = 1
let g:gvimrc_local_finish = 1

この程度であれば,自分の設定で保持してもいいのだが,無効化にはファイルの存在までチェックしているので,面倒だがファイルを作るしかない。そのため,vimrc_local.vimg:vimrc_local_finishの設定も押し込めた。おそらく,このグローバル変数が他でも使われていることを心配して念の為二重にしているのだろう。

まとめ

KaoriYa版Vimの独自設定を無効化する方法をまとめた。こういったローカル設定に関する情報はあまりないと思うので,誰かの参考になるのではないかと思って記事にまとめた。

KaoriYa版Vimは1999年から配布が行われており,約20年の歴史がある。日本でのVimの普及に大きな役割を担っていると思う。今後もVimを使っていくつもりなので,KaoriYa版Vimの動向もときどきチェックしていこうと思う。上記のKaoriya版独自設定の無効化にでは,グローバル変数だけでいいのではないかという意見も気が向いたらissueで質問してみようかしら…(遠い目)。

2016-08-07

Doxygen vs. Sphinx+Breathe

ソースコードに埋め込まれたコメントから文書を生成するツールとして,DoxygenとSphinx+Breatheについて検討し,Doxygen単独での利用が妥当と結論づけた。そのことについてメモしておく。

一連の考察は以下でまとめたツイートがベースとなっている。

Doxygen vs. Sphinx+Breathe - Togetterまとめ

Introduction

ソフトウェアを開発していると,そのソフトのクラスの構成や使い方,概念などが複雑になってくることがある。また,会社など複数人で開発を行っていると,新しく参加する人のためであったり,数年後に忘れた時のために,APIの説明文書(API文書)があるととても役に立つ。

しかし,こうしたAPI文書を作成する労力は無視できない。また以下の点も文書整備の妨げとなるだろう。

  • ソフトウェアの更新。
  • 文書整備の優先度の低さ。

こうした問題があるため,文書の整備にかける労力はできる限り小さくしたい。これを実現する手段として,文書化ツールの利用がある。API文書の記述方法には,大きく2パターンが存在し,それに合わせて文書化ツールも分類される。

  • ソースコード中に記述(例:Doxygen)
  • ソースコードとは別に記述(例:Sphinx)

この件については,以下のブログでも詳しい説明がある。

リファレンスマニュアルの記述方法 - ククログ(2011-05-05)

ソースコード中に記述する代表例はDoxygenであり,ソースコードと分離して記述する代表例はSphinxだと思う。

基本的にはソースコード中に記述する方法のほうが,書き漏らしがなく,ソースコードのすぐ近くで説明をかけるので,労力が少ないだろう。つまり,DoxygenのほうがAPI文書の作成には有利だ。しかし,文書の作成能力としては,Sphinxのほうが柔軟性が高いように思っている。Sphinxは世界中のOSSプロジェクトで採用されており,実績がある。また,Linux Kernelの文書でも採用されており,その利便性が気になっていた。

SphinxでどうにかDoxygen(やソースコードに埋め込まれたDoxygen用のコメント)をうまく使えたらいいなと思っていた。DoxygenのマニュアルのUsing the XML outputでSphinxの拡張機能であるBreatheを使うことで,Doxygenの出力XMLをSphinxで使うことができると知った。そこで,API文書の作成にDoxygen単体とSphinx+Breathe (+Doxygen)のどちらがいいか検討してみた。

Comparison

DoxygenもSphinx+Breatheもあまり使ったことがないので,実際にサンプルを自分で作るのは難しい。そこで,Doxygen単体とSphinx+Breatheが実際に使われた事例をみることにした。具体的には以下のプロジェクトを参照した。

Doxygen単体の事例
Eigenソース
Sphinx+Breatheの事例
ITKExamplesソース

例えば,以下のサイトで上記プロジェクトについて言及されていた。

上記ページで,この他にも,Doxygen単体の事例として,OpenCVも上げられていた。

比較には,最終成果物であるWebページ(HTML)と元ソースを使った。Webページがいくらきれいでも,元ソースに記載された記法が複雑であれば使用するのは難しいからだ。

Result

検討の結果,Doxygenのほうがよいと判断した。理由は大きく以下2点だ。

  • Doxygen単体で書かれたEigenの文書の品質が高く,Doxygen単体でも十分。
  • Sphinx+Breatheの実績が少なく,メリットに比べ導入の手間が大きい。

Eigenでは,ソースコードとは別にdocディレクトリに説明文書だけを書いた.doxファイルが大量に配置されている。これらの.doxファイルで主に使い方な ど,APIとの関わりの少ないを見出しをつけて書いている。図表やサンプルコードがふんだんに盛り込まれており,非常に品質の高い文書で感動した。ただし,Doxygenコマンドもふんだんに使われており,Doxygenコマンドには存在しない表などはHTMLコードを書いているので,Doxygenに対する習熟が必要となる。

この一方,Sphinx+Breatheの利点は以下2点だろう。

  • Doxygenで抽出したライブラリAPIの柔軟な配置
  • Sphinxによる柔軟な文書作成

しかし,Eigenのマニュアルをみて,Doxygenで作られたAPI文書の品質についてはあまり問題にならなくなってしまった。また,Doxygenで抽出したAPIの柔軟な配置をうまく活用した文書の作成はノウハウがないので難しい。実際ITKexamplesでのSphinxの利用はいまいちだった。具体的にはソースコードごとに専用の.rstファイルを作り,そこで単にSphinxの指令を入力してAPIを表示させているだけだった。もう少し込み入った使い方ができないならば,Doxygenで表示させるのと同じで,手間だけが余分にかかっている。

そのため,Sphinx導入に際して発生する以下の2点のデメリット以上のメリットが見当たらなくなってしまった。

  • reST記法の習熟
  • Sphinxの環境構築

また,Breatheには以下で指摘されている通り問題がいくつかあるようだ。

python - Has anyone used Sphinx to document a C++ project? - Stack Overflow

Doxygenを採用すれば,記法や環境構築はDoxygenだけで済む。Sphinx+Breatheを使う場合でも結局Doxygenコメントを使うので,二度手間となってしまう。やはり,Doxygenだけにしたほうがいいだろう。

余談だが,OpenCVも2系までSphinxを使っていた(Breathe拡張はなし)。しかし,3系からDoxygenに移行している。

やはりメンテナンス性を考えるなら,Doxygenを使ったほうがいいのだろう。

2016-08-03

Install Subversion 1.9.4 from source on Ubuntu 16.04

バージョン管理ソフトであるSubversionをソースからインストールする。

会社で採用されているVCS(Version Control System)がSubversionだった。普段はWindows PCからTortoiseSVNというGUIから操作しているが,コマンドラインからも操作できたほうがいいと思ったので,ソースからインストールしてみた。

インストール手順は,ダウンロードページの一番下の[Building and Installing Subversion]示されているインストール手順のページで書かれている通り,Subversionのソースに含まれるINSTALLファイルを参照する。

Subversionで最低限必要な依存関係は以下のとおりとなっている。

  • autoconf 2.59+
  • libtool 1.4+
  • C compiler (gcc)
  • libapr, libapr-util
  • SQLite
  • libz

上記の内の大部分はOSに標準でインストールされている。例えば,locateコマンドでインストールされているかどうかがわかる。locateコマンドでライブラリを指定して何も表示されなければインストールされていない。

locate libapr

今回は,不足していたlibapr,libapr-util,SQLite,libzをソースからインストールした。

インストールはUbuntu 16.04とFedora 19で確認した。

libz

libzは圧縮のためのライブラリである。

Source: zlib Home Site

LOCAL=~/.local
PKG=zlib
VER=1.2.8

cd $LOCAL/src
wget -nc http://zlib.net/$PKG-$VER.tar.xz
tar xf $PKG-$VER.tar.xz
cd $PKG-$VER
./configure --prefix=$LOCAL/stow/$PKG-$VER
make && make install
cd $LOCAL/stow; stow $PKG-$VER

libapr, libapr-util

libaprとlibapr-utilをインストールする。これらはApacheで開発されているソフトで共通で使われるライブラリらしい。

libapr-utilにはlibaprが必要なので,先にlibaprをインストールする。

Source: Download - The Apache Portable Runtime Project

LOCAL=~/.local

PKG=apr
VER=1.5.2
cd $LOCAL/src
wget -nc http://www-eu.apache.org/dist//apr/$PKG-$VER.tar.bz2
tar xf $PKG-$VER.tar.bz2
cd $PKG-$VER
./configure --prefix=$LOCAL/stow/$PKG-$VER
make && make install
cd $LOCAL/stow; stow $PKG-$VER
PKG=apr-util
VER=1.5.4
cd $LOCAL/src wget -nc http://www-eu.apache.org/dist//apr/$PKG-$VER.tar.bz2 tar xf $PKG-$VER.tar.bz2 cd $PKG-$VER ./configure --prefix=$LOCAL/stow/$PKG-$VER --with-apr=$LOCAL make && make install cd $LOCAL/stow; stow $PKG-$VER

SQLite

最後の依存関係として,DBソフトであるSQLiteをインストールする。SQLiteのソースをSubversionのディレクトリに配置すれば,Subversionのインストール時に,一緒に組み込んでくれる(INSTALLファイルの12. SQLite参照)。しかし,独立性やパッケージ管理のしやすさを考えて,SQLiteも単独でインストールする。

Source: SQLite Download Page

LOCAL=~/.local
cd $LOCAL
wget -nc https://www.sqlite.org/2016/sqlite-autoconf-3130000.tar.gz
tar xf sqlite-autoconf-3130000.tar.gz
cd sqlite-autoconf-3130000
./configure --prefix=$LOCAL/stow/sqlite-3.13.0
make && make install
cd $LOCAL/stow; stow sqlite-3.13.0

Subversion

Subversionに必要な依存関係をインストールし終わったので,最後にSubversionをインストールする。

Source:Download Apache Subversion Sources

LOCAL=~/.local

PKG=subversion
VER=1.9.4
cd $LOCAL/src
wget -nc http://www-us.apache.org/dist/subversion/$PKG-$VER.tar.bz2
tar xf $PKG-$VER.tar.bz2
cd $PKG-$VER

# 以下のとおりにsqliteのソース部分だけDLして配置すればSVNのビルド中に自動に組み込める
# wget -nc https://www.sqlite.org/2016/sqlite-amalgamation-3130000.zip # unzip sqlite-amalgamation-3130000.zip
# mv sqlite-amalgamation{-3130000,}

./configure --prefix=$LOCAL/stow/$PKG-$VER LDFLAGS=-L$LOCAL/lib
make && make install
cd $LOCAL/stow; stow $PKG-$VER

最後に以下のコマンドでSVNのバージョンを確認できたら完了となる。

svn --version

これでSubversionがコマンドラインから使えるようになった。