Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gintenlabo/5749ae1dc73d2f20e4f990f21d82a54c to your computer and use it in GitHub Desktop.
Save gintenlabo/5749ae1dc73d2f20e4f990f21d82a54c to your computer and use it in GitHub Desktop.
WSL Ubuntu に Oh my zsh と asdf をインストールしつつ、 .zshrc とかを git で管理するようにする

WSL Ubuntu に Oh my zsh と asdf をインストールしつつ、 .zshrc とかを git で管理するようにする

新PC移行でWSL環境をセットアップしたので、備忘録的に書いておきます。

zsh のインストール

zsh をインストールしてない場合はまずインストールします。

# WSLを導入したての場合はまずパッケージを更新する
sudo apt update
sudo apt upgrade

# zsh をインストールし、ログインシェルとして指定
sudo apt install zsh
chsh -s $(which zsh)

Oh my zsh のインストール

Ubuntu を再起動すると何かずらーっと表示されますが( ~/.zshrc がないため)、 Oh my zsh をインストールする過程で ~/.zshrc は作られるので q を押すので大丈夫です(他の選択肢でも大丈夫)。

以下のコマンドで Oh my zsh をインストールします(すでに zsh を使っていて自分の ~/.zshrc がある場合、インストールスクリプトでもバックアップはされるはずですが、念のため自分でもバックアップしておくこと。 また、実行されるスクリプトの内容は念のため確認しておきましょう。 自分が見たときは特に問題はなかったですが、いつ悪意ある変更が加わるか分からないためです)。

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

~/.oh-my-zsh ディレクトリと ~/.zshrc ファイルが作成されるはずです。

dotfiles を git で管理する

~/.zshrc などの設定ファイル(dotfile)は git で管理すると色々と捗ると思いますので git で管理しましょう。

まずホームディレクトリ直下に dotfiles というディレクトリを作って移動します。

mkdir ~/dotfiles
cd ~/dotfiles

git を初期化します。 もし元から zsh を使っていて既存の ~/.zshrc があったなら先にコミットしておくのもいいでしょう。 今回は現行の ~/.zshrc を最初のコミットとして使います。

git init
cp ~/.zshrc zshrc
git add zshrc
git commit -m "initial commit"

管理するファイル名ですが、僕は ls で常に見えるように . を外すのが好みです。

~/.zshrc~/dotfiles/zshrc へのリンクへと変更します。

# ~/dotfiles 内にいる想定
ln -srvbT zshrc ~/.zshrc

ln コマンドのオプションについては各自で調べてください。

ホームディレクトリを ls -al で表示して、 ~/.zshrc が正しく ~/dotfiles/zshrc を指しているか確認します。

ls -al ~

.zshrc の部分が .zshrc -> dotfiles/zshrc となっていれば問題ないです。

また、元々あった ~/.zshrc~/.zshrc~ というファイルとしてバックアップされているはずです。

バックアップファイルを消す前に、 ~/.zshrc が正しくリンクできているかを念のため更に確認したいので、 ~/dotfiles/zshrc をいじってシェルを再起動します(テーマを変えるとかが分かりやすいでしょう)。

変更が反映されていれば問題なくインストールできています。 ~/.zshrc~ は消してしまって大丈夫です。

問題があるようなら、 ~/.zshrc を消した上で ~/.zshrc~~/.zshrc にリネームすれば元に戻せます。 何が問題なのかを確かめた上で、再度リンクを作りましょう。

ここでは成功したものとして次に進みます。

Oh my zsh を git submodule で管理する

ホームディレクトリにある .oh-my-zsh も git で管理してると色々と面倒がなさそうです。 git submodule で管理しましょう。

# ~/dotfiles 内にいる想定
git submodule add https://github.com/ohmyzsh/ohmyzsh.git oh-my-zsh

ln コマンドでリンクします。

ln -srvbT oh-my-zsh ~/.oh-my-zsh

こちらも ちゃんとリンクできているかどうか、ホームディレクトリを ls -al で確認しましょう。

ls -al ~

~/.zshrc のときと同様に、 .oh-my-zsh の部分が .oh-my-zsh -> dotfiles/oh-my-zsh となっていれば問題ないです。 念のためシェルを再起動して、正しく動くかを確認しましょう。

問題ないようならバックアップの .oh-my-zsh~ を消し、 git commit します。

git commit -m "Add oh-my-zsh submodule"

asdf のインストール

asdf は NodeJS 等のバージョンを管理できるツールです。 便利なので使いましょう。 Oh my zsh を使っているなら専用のプラグインがあるのでインストールは簡単です。

まず asdf を git submodule~/dotfiles 内にクローンします。

# ~/dotfiles 内にいる想定
git submodule add https://github.com/asdf-vm/asdf.git asdf

安定バージョンをチェックアウトします。

cd asdf
# 2023/12/14 現在では v0.13.1 が stable
# ここは公式を確認して最新の安定バージョンにすること
git checkout v0.13.1 # v0.13.1 は tag らしいので switch ではなく checkout を使う。 git switch --detach でもいい
cd ..
git add asdf # バージョン変化を stage しておく

ホームディレクトリに asdf へのリンクを張ります。

ln -srvbT asdf ~/.asdf

zshrc を編集して plugins に asdf を追加します。

# ...

# Which plugins would you like to load?
# Standard plugins can be found in $ZSH/plugins/
# Custom plugins may be added to $ZSH_CUSTOM/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
# Add wisely, as too many plugins slow down shell startup.
plugins=(git asdf)

# ...

これで asdf が有効になったはずです。 シェルを再起動するか source ~/.zshrc を実行して、 asdf が使えるか試してみましょう。

asdf --version

v0.13.1 (もしくは自分の指定したバージョン)が表示されれば問題ないです。

asdf の具体的な使い方は自分で調べてください。

変更を commit します。

git add zshrc
git commit -m "Use asdf"

GitHub とかでホスティングする

マシン移行時にスムーズに環境構築できるよう、 GitHub とかでホスティングしておくことをお勧めします。

public リポジトリを個人的にはお勧めしていますが、自信がなければ private でもいいです。

なお、ホスティングする際は、たとえ private であっても設定ファイル内に機密情報とかが入ってないことを確認してください。

具体的なホスティングのやり方は、ここでは省略します。

インストールスクリプトっぽいものを作る

環境構築自体は一先ずこれで終わりですが、環境移行したときにスムーズに環境構築できるよう、インストールスクリプトっぽいものを作っておくと便利です。

やり方は個人の好みによりますが、筆者の使っている方法を紹介します。

まず dotfiles で管理しているファイル名のリストをファイルに保存します。 筆者は dotfiles という名前で管理していますが、名前はなんでもいいです。

zshrc
oh-my-zsh
asdf

実際にはもっと多くのファイルを管理することになると思います。 管理されるファイルが増えたら、その都度追加します。

然る後、 README.md にインストール用のシェルスクリプトサンプルを書きます。

## how to install

```bash
cd path/to/your/repository

# サブモジュールの初期化
git submodule update --init

# リンクの作成
# 本当は while read などを使うべきなのだろうが、
# スペースの混じったファイル名は dotfiles には まあ ないだろうということで for を使う
# FIXME: 複雑なファイル名に対応できるようにする
for file in `cat dotfiles`; do
  ln -srvbT ${file} ~/.${file}
done
```

あとは dotfilesREADME.mdgit commit すれば おっけーです。

作業用 dotfiles ディレクトリを作る

dotfiles リポジトリの内容を編集したい、でも現在の設定はそのままにしておきたい、という需要がたまに出ます。

そういう時のために作業用 dotfiles ディレクトリを作っておくと便利です。

ここでは ~/work/dotfiles に作ることにします。

cd ~/work
git clone ~/dotfiles/.git dotfiles # もしくは GitHub 等でホスティングしているリポジトリから clone する
cd dotfiles

こうやって作った作業用ディレクトリ内で作業する分には、何をやっても環境は壊れませんので、安心して作業できます。

作業用ディレクトリの内容を実際の環境に反映させたい場合のために、 ~/dotfiles ディレクトリ内から ~/work/dotfilesgit remote で参照できるようにさせておくと便利です。

cd ~/dotfiles
git remote add local-workspace ~/work/dotfiles/.git
git fetch local-workspace

作業ディレクトリの作業内容を反映させたい場合は、作業ディレクトリ内で git commit した上で、 ~/dotfiles ディレクトリ内で git pull を使います。

cd ~/dotfiles
git pull --ff --ff-only local-workspace master #またはmain、もしくは作業ブランチ名

これで ~/work/dotfiles 内の master ブランチの内容が反映されるはずです。

おわりに

  • dotfiles で管理できるファイルは他にも .vimrc.gitconfig 等、たくさんあります。 どんどん管理するようにしましょう。 その際は dotfiles ファイルへの追加をお忘れなく。
  • Oh my zsh のカスタムテーマを使いたいときは、リポジトリに(例えば) oh-my-zsh-custom ディレクトリを追加し、 ~/.oh-my-zsh-custom へとリンクした後に、 zshrcZSH_CUSTOM の部分の設定を ZSH_CUSTOM="$HOME/.oh-my-zsh-custom" とすることで作れます( dotfiles への追加も忘れずに)。 カスタムテーマは oh-my-zsh-custom/themes ディレクトリ下に置きましょう。 筆者は oh-my-zsh-custom/themes/dst-improved.zsh-theme というテーマを作って使っています。 使う場合は zshrcZSH_THEME の部分を(例えば) ZSH_THEME="dst-improved" とすれば使えます。
  • git submodule は貴方が思ってる以上に便利です。 例えば Vim の Vundle を使うのに git submodule を使えます。 Vundle の具体的な使い方は筆者に問い合わせれば(気が向いたときに)答えます。
  • 機密情報の流出はマジで警戒しましょう。 通常は機密情報は一般の dotfile から分離できるように設計されてる筈なので、ちゃんと調べれば問題ないはずです。 万が一 流出したら、その時点でその情報は全世界に知れ渡っていると判断するべきです。 速やかに変更しましょう。
  • 今回は簡単のため mastermain かも)ブランチで作業しましたが、筆者の好みは「共通化出来そうな設定のみ master/main で管理し、個々の環境は個別にブランチを切って(例えば wsl-ubuntu 等)作業する」です。 その場合は各ブランチに常に master/main がマージされているようにしましょう。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment