ソースからのソフトウェアのインストールを支援する installer.sh
普通 linux とかで ソフトをインストールするときは、パッケージマネージャを使えばいいです。
ただ、何かの事情で使えないことがあったりします。そもそも管理されてなかったり、あっても欲しいバージョンでなかったり、管理者権限を持ってなかったり。そのような場合、多くはソースからインストールをすることになると思います。
ソフトをソースからインストールする場合、その手順はほとんどいつも同じなはずです。つまり、例えば tarball をダウンロードして展開して ./configure && make && make install
をする、といった具合です。一回ならまだいいですけど、何回も繰り返すようになるとだるいです。何回も繰り返すことがたまにあったので、あんまり労力をかけずに自動化できるようにしてみました。
Feature
- いくつかの変数と一つの関数を定義するだけでインストールを自動化できる
- 実行時には特有な外部プログラムを必要としない。普通にシェルスクリプトが実行できる環境であればスクリプト一つでインストールが完了する
- ArchLinux の PKGBUILD に強い影響を受けている
Usage
installer_sh から installer.sh
をコピーして、いくつかの変数を書き換えます。例えば、 python3.3 のインストーラ は、冒頭が以下のようになります。
pkgname=python3
pkgver=3.3.0
_pkgname=Python
pkgdesc="Programming language"
url="http://www.python.org"
source="$url/ftp/python/$pkgver/$_pkgname-$pkgver.tar.bz2"
_prefix=$HOME/.local
main(){
cd $srcdir/$_pkgname-$pkgver && \
./configure --prefix=$_prefix && \
make && \
make install
}
冒頭をこんな感じに記述した installer.sh
を保存します。 $ ./installer.sh install
と実行することで、 $source
のファイルをダウンロード、展開し、 main()
を実行するまでを自動でしてくれます。
remember-major-modes-mode.el
emacs がファイルから major-mode を判別しようとするとき、 auto-mode-alist
と interpreter-mode-alist
が使われる。
ヘンなファイル名だったりして、こういう自動判別が上手く働かないことがたまにある。ファイル名にいくらか決まりのあるようなものなら auto-mode-alist
に追加すればいいけれど、それがそのファイル特有のものだったりすると、ひとつのファイルのためだけにわざわざ init.el
を書き換えるような事になったりして面倒だった。
なので、ある特定のファイルについて major-mode を記録できるようなものとして remember-major-modes-mode.el
を作った。
Usage
ライブラリをパスの通った場所において、 init.el
とかに
(when (require 'remember-major-modes-mode nil t)
(remember-major-modes-mode 1))
を加える。
M-x remember-major-modes-remember
することで今のバッファの major-mode を記憶する。次にそのファイルを開いた時に、 remember-major-modes-mode
が有効であれば記憶した major-mode が自動的に有効になる。
現在の git レポジトリから新しい作業ディレクトリを作る dit-dup 作った
git new-workdir
git のレポジトリで作業しててふと他のことがしたくなった場合、 stash とかを使ったりするけど、先日
git-new-workdir
を知った(参考:git-new-workdir が便利 - #生存戦略 、それは - subtech)。
簡単にいえば、あるレポジトリについて .git/ 以下のほとんどを symlink で共有した新しい作業ディレクトリを作ってくれる。 そのため、片方の作業ディレクトリで commit したりすると他の方でもその commit が見える。 その上 HEAD は共有されないため、例えば一つのレポジトリについてそれぞれの作業ディレクトリで別の branch を checkout して commit するみたいなことができる。
で、 git-new-workdir はこんなふうに使うのだけど、
git-new-workdir <repository> <new_workdir> [<branch>]
これがわりとめんどくさいと思った。
- 複製元は今いるレポジトリでいい
- 新しいディレクトリも今いるところに良い感じにつくればいい
- ついでにブランチが無ければ新しく作って欲しい
そこで、これの上にかぶせる git-dup.sh を作った。
Install
git-dup.sh
を git-dup
として PATH の通ったところに保存する。
git-new-workdir
も /usr/local/share/git-core/contrib/workdir/git-new-workdir
みたいなところから探してきて
PATH の通ったところに simlink 貼るなりする。
Usage
$ git dup [<branch>]
How It Works
- 指定されたブランチが無ければ作成する
- ブランチ名を省略した場合、現在いるブランチを使う
- 今いるのが detached-HEAD だった場合、 master ブランチを使おうとする
- そのとき master ブランチがなかったらエラーで死ぬ
- 新しいディレクトリを
_<repname>_<branch>
として作成する。 repname は今いるディレクトリの名前が使われる。 既にあったら死ぬ git new-workdir
を使って現在のレポジトリの作業ディレクトリをそのディレクトリ内に作成しブランチを checkout する
git のレポジトリ内で日記を書く
git-diary を作りました。 レポジトリ内に diary という名前で orphan な branch を作り、文章を空コミットのログとして記録します。
インストール
git-diary.sh を git-diary に rename して PATH の通ったところに置きます。
使い方
日記を書く
$ git diary add [text ...]
add を引数ありで実行した場合、それを日記として記録します。 引数がない場合、エディタを起動します。
$ git diary add My first diary.
Add new diary:
My first diary.
$ git diary add
# launch editor
Add new diary:
My diary 2.
日記を見る
基本的には diary ブランチを見るだけです。
$ git log diary
また、 diary list という専用コマンドもあり、これは alias.diary-list をブランチ名付きで実行します。
$ git config alias.diary-list "log --oneline --reverse"
$ git diary list
# >> git log --oneline --reverse diary
$ git diary list --grep=todo
# >> git log --oneline --reverse diary --grep=todo
設定
diary.branch
日記に用いるブランチ名。
diary.editor
日記を書くのに使うエディタ。これが設定されていない場合、普通コミットメッセージを書くのに使うエディタが起動します。
alias.diary-list
前述のとおり。設定されていない場合、 "log"
が自動的に設定されます。
エントリ1
h1 見出し
本文 強調 強調2
h2 見出し
- 記号リスト1
- 記号リスト2
- リスト1
リスト2
- nested list
- nested list