% rbenv install -l

...

2.3.0

2.3.1

2.3.2

2.3.3

2.3.4

2.4.0-dev

2.4.0-preview1

2.4.0-preview2

2.4.0-preview3

2.4.0-rc1

2.4.0

2.4.1

2.5.0-dev

...

この中からインストールするバージョンを選ぶ

(当時は 2.3.3 を選択)

選んだバージョンを指定して rbenv で Ruby をインストール

% rbenv install 2.3.3

インストールされている Ruby のバージョンは次のように確認できる

% rbenv versions

* system (set by /Users/username/.rbenv/version)

2.3.3

「*」がついているものが現在有効になっているバージョン

特定のディレクトリにのみ Ruby のバージョン変更を適用する

ワーキングディレクトリ(今回は ~/working)に移動して Ruby のバージョンを確認

% cd ~/working

% ruby -v

ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin16]

% rbenv version

system (set by /Users/username/.rbenv/version)

% rbenv which ruby

/usr/bin/ruby

Ruby のバージョンを変更する

% rbenv local 2.3.3

% ruby -v

ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin16]

% rbenv version

2.3.3 (set by /Users/username/working/.ruby-version)

% rbenv which ruby

/Users/username/.rbenv/versions/2.3.3/bin/ruby

% ls -a

. .. .ruby-version

ruby コマンドが切り替わっているのがわる

rbenv local で Ruby バージョンを切り替えた場合、そのディレクトリ配下では指定したバージョンが有効になる

(おまけ) そのとき gem は？

上の手順で ruby は変更されているが gem はどうなっているのか？

まずはホームディレクトリで gem を調べてみる

% gem -v

2.0.14.1

% rbenv which gem

/usr/bin/gem

% gem environment

RubyGems Environment:

- RUBYGEMS VERSION: 2.0.14.1

- RUBY VERSION: 2.0.0 (2015-12-16 patchlevel 648) [universal.x86_64-darwin16]

- INSTALLATION DIRECTORY: /Library/Ruby/Gems/2.0.0

- RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby

- EXECUTABLE DIRECTORY: /usr/local/bin

- RUBYGEMS PLATFORMS:

- ruby

- universal-darwin-16

- GEM PATHS:

   - /Library/Ruby/Gems/2.0.0

   - /Users/username/.gem/ruby/2.0.0

   - /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/gems/2.0.0

- GEM CONFIGURATION:

   - :update_sources => true

   - :verbose => true

   - :backtrace => false

   - :bulk_threshold => 1000

- REMOTE SOURCES:

   - https://rubygems.org/

次に Ruby 2.3.3 を適用したワーキングディレクトリで

% gem -v

2.5.2

% rbenv which gem

/Users/username/.rbenv/versions/2.3.3/bin/gem

% gem environment

RubyGems Environment:

- RUBYGEMS VERSION: 2.5.2

- RUBY VERSION: 2.3.3 (2016-11-21 patchlevel 222) [x86_64-darwin16]

- INSTALLATION DIRECTORY: /Users/username/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0

- USER INSTALLATION DIRECTORY: /Users/username/.gem/ruby/2.3.0

- RUBY EXECUTABLE: /Users/username/.rbenv/versions/2.3.3/bin/ruby

- EXECUTABLE DIRECTORY: /Users/username/.rbenv/versions/2.3.3/bin

- SPEC CACHE DIRECTORY: /Users/username/.gem/specs

- SYSTEM CONFIGURATION DIRECTORY: /Users/username/.rbenv/versions/2.3.3/etc

- RUBYGEMS PLATFORMS:

- ruby

- x86_64-darwin-16

- GEM PATHS:

   - /Users/username/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0

   - /Users/username/.gem/ruby/2.3.0

- GEM CONFIGURATION:

   - :update_sources => true

   - :verbose => true

   - :backtrace => false

   - :bulk_threshold => 1000

- REMOTE SOURCES:

   - https://rubygems.org/

- SHELL PATH:

   - /Users/username/.rbenv/versions/2.3.3/bin

   - /usr/local/Cellar/rbenv/1.1.0/libexec

   - /Users/username/.rbenv/shims

   - /usr/local/bin

   - /usr/bin

   - /bin

   - /usr/sbin

   - /sbin

   - /Users/username/bin

gem もちゃんと切り替わっているのがわかる

gem パッケージのインストール先も ~/.rbenv/versions/... になっている

いろいろ調べてみると、rbenv を利用している際の gem インストールは rbenv exec gem install を、bundler は rbenv exec bundle を使用するのがよさそう

上の調査結果を見る限り gem install は rbenv exec を使用していなくてもよさそうだが、システムに同名のコマンドが混在しているとどっちが適用されるか不安があるから rbenv exec を利用するのが安全か？

2018-09-05

Homebrew のインストール

オフィシャルサイトhttps://brew.sh/index_ja のトップに記載されてるコマンドをたたくだけ

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

インストール後のチェック

brew doctor

Homebrew とパッケージリストの更新

brew update

2018-08-30

Git 用語まとめ

Git

なんとなくわかったこと。(勘違いや間違いを含む可能性アリ)

図も描いてみたかったけど時間かかるしやめた。

repository

リポジトリ。履歴情報。コミットオブジェクト、ブランチやタグの情報など。または、ワーキングツリーを含む Git 管理下のディレクトリを指す。

bare repository

ベアリポジトリ。ワーキングツリーをもたない。git init で指定されたディレクトリ直下に履歴情報が配置される。bare は「裸の」という意味。

non-bare repository

ワーキングツリーをもつリポジトリ。git init で指定されたディレクトリがワーキングツリーとなる。同時に .git ディレクトリが作成され、履歴情報、インデックスなどの Git 管理ファイルが配置される。

working tree

ワーキングツリー。ワーキングディレクトリ。ユーザーの作業領域。

index

インデックス。ステージングエリアとも呼ばれる。コミット対象のファイルを管理する。

staging

ステージング。コミット対象のファイルをインデックスに登録すること。Git コマンドは "add"。

commit

コミット。インデックスに登録された情報をもとにワーキングツリーのスナップショットを作成し、リポジトリに登録する。

commit object

コミットオブジェクト。コミット時点でのワーキングツリーのスナップショットの先頭データ。曖昧だがスナップショット全体を示すこともある。

スナップショットのデータ構造は commit -> tree (ディレクトリ構造) -> tree or blob (ファイルデータ) となっている。コミットオブジェクトは、ツリーオブジェクト、親コミットオブジェクト、作者、作成日時、コミッター、コミット日時、コミットコメントの情報をもつ。

author

最初にコミットした人。通常はファイルを修正した人。通常の commit --amend や rebase では変わらない。

committer

最後にコミットした人。commit --amend や rebase をしたら変わる。

branch

ブランチ。直訳すると「枝」。履歴ツリーの枝をイメージした言葉だと思うが、実態は履歴上にある最新のコミットを示すタグのようなものだと考えるとしっくりくる。履歴が枝分かれする(複数のコミットオブジェクトが同じ親を示す)と複数のブランチが存在することになる。

remote-tracking branch

リモート追跡ブランチ。リモートブランチの追跡ブランチ。ローカルに存在するリモートブランチのコピー。fetch するとリモートブランチの最新情報を取得し、リモート追跡ブランチが更新される。

remote repository

リモートリポジトリ。push & fetch の対象となる別のリポジトリ。だいたいは共有リポジトリ。git remote -v で確認できる。通常は origin に clone もとのリポジトリが設定される。

local repository

ローカルリポジトリ。現在、作業しているリポジトリ。

merge

マージ。現在のブランチに、別のブランチとの差分を取り込む。

fast-forward ではない場合、または --no-ff オプションが指定された場合は、別のブランチとの差分を取り込みマージコミットを作成する。

fast-forward merge

ファストフォワードマージ。現在のブランチが指定されたブランチの履歴の途中にあり、まだ枝分かれしていない場合、現在のブランチを指定されたブランチと同じコミットに移動させる。マージコミットは作成されない。

rebase

リベース。親(枝分かれするコミットオブジェクト)の付け替え。指定されたブランチの最新情報を取り込み、カレントブランチの履歴上にある、(枝分かれしてから最新のものまで)すべてのコミットを作り直す。

2018-08-26

Git 共有リポジトリを作成する

command-line Git

usage

git init --bare --shared [direcotry]

--bare

bare リポジトリを作成する。履歴情報のみ。ワーキングツリーを持たない。

--shared

ディレクトリのアクセス権限を指定する。デフォルトは group(true) で "g+sx" になるっぽい。１つのアカウントで利用する分には不要だと思う。

direcory

ディレクトリを指定する。デフォルトはカレントディレクトリ。ディレクトリが存在しなければ新規作成する。

2018-08-26

ターミナルの記録をとる

macOS command-line

ターミナルで実行したコマンドラインとその標準出力をファイルに書き出す

script [file]

exit でファイル出力を終了する

出力されたファイルには制御文字が含まれてるのでそのままだと読みづらい

なにかしらの置換処理で除去するか、less -r で表示するとよさそう

2018-08-26

first upload test

title1 タイトル１

title2 タイトル２

title3 タイトル３

body 本文

foobaa ほげほげ