ラベル zsh の投稿を表示しています。 すべての投稿を表示
ラベル zsh の投稿を表示しています。 すべての投稿を表示

2010-12-28

ZSH のパス設定

以前、MacBook と Mac mini Server の間で git clone しようとして失敗したことがあった(→「MacBook にも Git を (あるいはリモートリポジトリの準備)」)。原因は、リモート側のシェルの PATH 設定だった。git でリモートリポジトリから SSH 経由で clone しようとする場合、リモート側で(SSH 経由で) git コマンドが実行される。リモート側のシェルのパスに git コマンドをふくむディレクトリが入っていなければ、git コマンドが見つからずエラーになる。

シェルは起動時に設定ファイルを読み込む(実行する)ことで実行環境を整える。このとき、たいていのシェルでは実行モードによって読み込む設定ファイルが変わる。実行モードというのはログインシェル、対話シェル、そしてスクリプト実行用シェルの 3 つのことで、git clone で起動されるシェルはスクリプト実行用シェルになる。このため、たとえ ssh コマンドでリモートログインした状態で対話的に git コマンドを使えたとしても、git clone しようとすると (git コマンドが見つからず)エラーになることがある。

今日も、MacBook と iMac の間で git clone しようとして同じエラーが出て失敗した。以前解決したはずの問題にまた遭遇したことになる。というのも、あれからしばらくしてシェルを zsh に変えたからだ(→「twitter より (2010-08-03)」)。最初の設定のときに、ssh コマンドでリモートログインしてローカルなシェルの場合と同様に使えることを確認して安心していた。今日まで git clone のようなリモートのコマンドを直接実行することはなかったから、この問題に気付かなかった。

では、zsh を使う場合リモート(のスクリプト実行用)のシェルが参照するパスを設定するにはどうすれば良いのか? より具体的に言えば、git のリモートリポジトリを置いたコンピュータのシェルが zsh のとき、git clone 等が失敗しないようにするにはどうすれば良いのか?

答えは ~/.zshenv

結論を先に書くと、スクリプト用シェルのために PATH を設定するには ~/.zshenv に書けば良い。書式は通常のシェルスクリプトと同じ。つまり、git clone が失敗する問題を解決するためには、リモート側(clone されるリポジトリがある方)に ~/.zshenv を作り、以下のように PATH の設定をしてやれば良い(git コマンドを MacPorts でインストールしている場合)。

export PATH=/opt/local/bin:/opt/local/sbin:$PATH

これまで、zsh のためのパスは ~/.zshrc で設定してきた。この方法どこが悪かったのだろう?

それは実行モードごとの設定ファイルの読み込みが以下のようになっているからだ(→「【コラム】漢のzsh (1) 最強のシェル、それは「zsh」 | マイコミジャーナル」参照)。一言で言えば、~/.zshrc はスクリプト実行用シェルのときは読み込まれない。

zsh の設定ファイル読み込み順序
実行モード 読み込み順
ログインシェル
  1. ~/.zshenv
  2. ~/.zprofile
  3. ~/.zshrc
  4. ~/.zlogin
対話シェル
  1. ~/.zshenv
  2. ~/.zshrc
スクリプト用シェル
  1. ~/.zshevn

これを見れば、スクリプト用シェルが参照する PATH は ~/.zshenv で設定しなければならないことがわかる。

~/.zshenv を読むより前に起きていること

さて、これで MacBook と iMac の間で git clone に失敗する問題は解決できたが、ついでに zsh における PATH の設定について調べてみた。

zsh の man ページによれば、シェルが起動時に最初に読み込むのは /etc/zshenv だとのこと。その後、上述の表のような順序で設定を読み込む。では、/etc/zshenv はどうなっているのか?

Mac OS X 10.6.5 の /etc/zshenv の内容を以下に示す。

# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
 eval `/usr/libexec/path_helper -s`
fi

ここに書いてあるのは /usr/libexec/path_helper があれば、それを実行しろというもの(バッククォート記法なので、正確には path_helper の実行結果をスクリプトとして実行しろ、となる)。

この path_helper というコマンドは PATH を設定するためのシェルスクリプトを生成するためのもので -s オプションで B-shell 用のスクリプトが作られる。man ページには直接実行するものじゃないゾ、と書いてあるが、そこをあえて実行してみた結果を以下に示す。実行の前に PATH と MANPATH の設定を消しているのは、このコマンドが現在の設定に追加するようになっているから。空にしておくことで、zsh が /etc/zshenv でこのコマンドを実行したときの結果がわかる。

[imac] mnbi% PATH=''
[imac] mnbi% MANPATH=''
[imac] mnbi% /usr/libexec/path_helper -s
PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin"; export PATH;
MANPATH="/usr/share/man:/usr/local/share/man:/usr/X11/share/man"; export MANPATH;

では、path_helper は PATH (と MANPATH) に入れるべきディレクトリをどうやって知るのだろう? man ページによれば、それは /etc/paths/etc/manpaths だとのこと。そして、ここに書かれたものに、さらに /etc/paths.d/etc/manpaths.d に置かれたファイルの内容を付け加えて、PATH と MANPATH とする。

以下に、Mac OS X 10.6.5 の /etc/paths の内容を示す。

/usr/bin
/bin
/usr/sbin
/sbin
/usr/local/bin

同じく、Mac OS X 10.6.5 では /etc/paths.d には X11 というファイルがあり、その内容は以下のようになっている。

/usr/X11/bin

以上のことから、~/.zshenv を使ってユーザごとにパスを設定する以外にも、追加したいパスを書いたファイルを /etc/paths.d に置けば、システム全体で(正確には zsh を使っているすべてのユーザで)同様の効果が得られることがわかる。

関連リンク

関連記事

2010-11-11

Snow Leopard アップデート (10.6.4 → 10.6.5)

10.6.4 のアップデートは 2010-06-15 だったようなので、およそ 5 ヶ月を経ての更新になる。ちなみに 10.6.3 は 2010-03-29 、10.6.2 は 2009-11-09 にそれぞれリリースされている。

10.6.2 へのアップデートは記録してあるが(→ 「Snow Leopard アップデート (→ 10.6.2)」)、10.6.4 と 10.6.3、そして 10.6.1 のときは忘れたようだ。10.6 が届いたときのことは記録がある(→ 「Snow Leopard、届いた。」、「Snow Leopard、MacBook にインストールした。」)。

iMac & MacBook

iMac (Mid 2010) は届いた時点で 10.6.4 だったから、これが最初の OS アップデートになる(セキュリティアップデートは除く)。

Snow Leopard 10.6.5 update
iMac (Mid 2010)
680.1MB にはちょっと驚いた。CD-ROM に 1 枚に収まらないかも?
MacBook (Early 2008)
517.3MB。iMac 用よりはかなり小さいが、それでも……。

今回のアップデートはかなり巨大だ。変更点を読んでも、ユーザに取って目立った修正はないようだけど。

右のスクショはアップデート後の iMac の「About Mac」パネルだ。

Mac mini Server

サーバ版のアップデートも巨大だ。10.6.2 のときのアップデートが、同じ mini に対して 524.5MB でその大きさに驚いたが、今回はその 1.5 倍に近い。

Snow Leopard Server 10.6.5 update
Mac mini Server (Late 2009)
741.6MB。こちらは確実に CD-ROM じゃ配布できない。

mini の「About Mac」パネルのスクショも貼っておく。iMac の方と違うのは「Server」の文字の有無だけだ。

カーネルバージョン

10.6.2 のときに記録したので、今回も記録しておく(バックスラッシュで折り返してある)。今回も、サーバとクライアントで全く同一のバージョンになっている。

[mini] mnbi% uname -a
Darwin mini.private 10.5.0 Darwin Kernel Version 10.5.0: \
Fri Nov  5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386
[imac] mnbi% uname -a
Darwin imac.private 10.5.0 Darwin Kernel Version 10.5.0: \
Fri Nov  5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386

Darwin Kernel Version の 2 つ目(10.5.0 の 5 の部分)が Snow Leopard のバージョンの 3 つ目 (10.6.5 の 5 の部分) と一致しているのかも。

ふと、カーネルファイルの情報を見てみたくなって file コマンドで確認してみた。

[imac] mnbi% file /mach_kernel                                            [~]
/mach_kernel: Mach-O universal binary with 3 architectures
/mach_kernel (for architecture x86_64): Mach-O 64-bit executable x86_64
/mach_kernel (for architecture i386): Mach-O executable i386
/mach_kernel (for architecture ppc): Mach-O executable ppc

PPC Mac をサポートしない Snow Leopard のカーネルにどうして ppc 用のバイナリがふくまれているんだろう(・д・)?

他のコマンドも見てみた。まずはシェル。

[imac] mnbi% for shell in /bin/*sh; do; file $shell; done                 [~]
/bin/bash: Mach-O universal binary with 2 architectures
/bin/bash (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/bash (for architecture i386): Mach-O executable i386
/bin/csh: Mach-O universal binary with 2 architectures
/bin/csh (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/csh (for architecture i386): Mach-O executable i386
/bin/ksh: Mach-O universal binary with 2 architectures
/bin/ksh (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/ksh (for architecture i386): Mach-O executable i386
/bin/sh: Mach-O universal binary with 2 architectures
/bin/sh (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/sh (for architecture i386): Mach-O executable i386
/bin/tcsh: Mach-O universal binary with 2 architectures
/bin/tcsh (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/tcsh (for architecture i386): Mach-O executable i386
/bin/zsh: Mach-O universal binary with 3 architectures
/bin/zsh (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/zsh (for architecture i386): Mach-O executable i386
/bin/zsh (for architecture ppc7400): Mach-O executable ppc

なんでウチで使っている zsh だけ...。

/bin/usr/bin を簡単に調べたところ、1/3 ぐらいはまだ ppc 用のバイナリを持っているようだ。

[imac] mnbi% ls -1 /bin /usr/bin | wc -l
    1119
[imac] mnbi% for f in /bin/* /usr/bin/* ; do; file $f; done | fgrep 'Mach-O executable ppc' | wc -l
     396

Snow Leopard って ppc を切り捨てて身軽になったっていうのがウリの 1 つじゃなかったっけ?

サーバ管理ツールもアップデート

OS 自体のアップデートと関係しているのかどうかはわからないが、Snow Leopard サーバに付属のサーバ管理用のツール(クライアントの Mac にインストールして使う)もアップデートされている。左のスクショはその通知。

ウチではこのツールを(Mac mini Server を遠隔管理するために) iMac と MacBook にインストールしているが、OS のアップデートが完了してからこの通知が現れた。OS のアップデート前には「ソフトウェア・アップデート」で検索させても出てこなかった。(ツールの)バージョンも 10.6.5 だし、サーバ OS と連動しているのかもしれない(今回だけ?)。

関連リンク

関連記事

2010-08-08

iMac に Gauche 0.9 をインストール

MacPorts を使ってのインストール。Mac mini にインストールしたときに実行結果を残していたので、今回も残してみる。ただ、前回の記録には依存関係によるビルド&インストールを丸ごと snip してしまったため、実行時間の比較は意味がなさそう。あのときは依存関係分は前もってインストールしておいて Gauche だけをビルドしたのかも。記録はないし、記憶は消えてるしで、判別するすべはない。

使った MacPorts のバージョンは 1.9.1。今回は依存関係により gdbm と slib が自動インストールされた。

[imac] mnbi% time sudo port install gauche                        [~]
Password:
--->  Computing dependencies for gauche
--->  Dependencies to be installed: gdbm slib
[...snip...]
--->  Installing gauche @0.9_0
--->  Activating gauche @0.9_0
--->  Cleaning gauche
sudo port install gauche  102.11s user 25.08s system 142% cpu 1:29.06 total
[imac] mnbi% hash -r                                              [~]
[imac] mnbi% gosh -V                                              [~]
Gauche scheme shell, version 0.9 [utf-8,pthreads], i386-apple-darwin10.4.1

ちなみに、↑で time の出力書式が前回と変わっているのはシェルを tcsh から zsh に変えたから。シェルプロンプトが変わっているのもそのせいだ。

関連リンク

関連記事

2010-08-04

twitter より (2010-08-03)

  • 02:53  予想通り Magic Trackpad はとても気持ち良い。iPhone や iPad ですっかり馴染んだ慣性付きのスクロールもデバイスに関わらず気持ち良いね。もうマウスはいらない。
  • 02:55  Magic Mouse は電池だけ取り出して箱に戻した。
  • 03:33  「 アイディアを思いついた時に、[...snip...]骨組みや足場をえいやっと素早く作ってしまえる能力が、 基礎体力だ。」ああ、まったくその通りだよ。最初に衰えるところでもあるんだよね。 → プログラミングと体力 http://bit.ly/cLCmrj
  • 03:39  プログラマがプログラミングの現場から離れたとき、真っ先にこれが衰える。アーキテクチャだとかアルゴリズムだとか、デザインパターンがどうしたとか、オブジェクト指向はこうあるべき、なんてことは忘れない。でも、いざアイデアを形にしようとしたとき、手が指が動かなくなる。
  • 03:40  そしてため息をつく。「ああ、オレはもうコードが書けなくなってる(´・ω・`)」 じゃあ、そんな基礎体力の衰えたプログラマの再訓練にはどんなことが適しているだろう?
  • 03:47  きっと、本や資料を読むことじゃないんだよね。それだとイライラが募るばかりだ。新しい技術やツールのことを知り、あれもしたいこうも作りたいとアイデアは出るけれど、それを素早く形にすることができない。構想力と実現力の間のギャップが深まるばかり。
  • 03:48  もちろん、たいていのアイデアなんて大したものじゃない。でも、それも形にしてみなけりゃ、動かしてみなけりゃ見えてこないし、ダメだってことに納得できない。
  • 04:58  特に理由はないけれど、せっかくメインマシンが新しくなったことだし、普段使うシェルを変えてみることにした。tcsh -> zsh
Powered by twtr2src.