最近、zsh + Vim + tmux でコマンドラインライフを過ごしている方も多くなってきたように思う。その豊かな CLI ライフを支えているのは数多くの優れたプラグインであることには間違いない（もちろんプラグインを使わない派閥も一定数いるでしょう）。 今回はとりわけ zsh に絞って有用であるプラグインを紹介していく。 zsh のプラグイン プラグインマネージャ まずは管理の要となるプラグインマネージャだろう。 今イチオシなのは zplug（neobundle + vim-plug の zsh 版）なのだが定番である Antigen も一応挙げておく。 zplug - A next-generation plugin manager for zsh Antigen - A plugin manager for zsh, inspired by oh-my-zsh and vundle.

Vim プラグインの歴史 GitHub 以前 (〜2008年) 昔の話です。Vim script で拡張の機能を書いたらそのスクリプトを vim.org にアップして開発者同士で共有したり、ユーザがダウンロードして使っていたようです。いわゆる「プラグイン管理」の始まりなのですが、このときはまだ手動で行われていたようです。 例えば、こんな機能も Vim script で書いた拡張です (autogroup などは考慮してません)。 Vim 7 から Vimball という機能が Vim 本体に同梱されて、それからはこれを利用するユーザもいたようです。vim.org からアーカイブされたスクリプトを持ってきて、:so % したり、気に入ったら runtimepath 以下に置いて自動読み込みしたり。その頃の plugins ディレクトリは混沌としていたようです。ペライチのスクリプトが無造作に転

（続編; --expect オプションの酷使について）私の fzf 活用事例 peco 便利ですよね。正直、使い始めてしまうと使わない日はありません。最近の CLI 界隈では選択的インターフェイスやインタラクティブフィルタなどと呼ばれるツールが盛んに開発されています。特に peco は ghq との連携で一躍人気が出た気がします。 ghqを使ったローカルリポジトリの統一的・効率的な管理について こんなやつですね。以下は ghq のリポジトリへのアクセスを簡単にするためにスクリプトです。 # Require Bash 4.0+ peco-src() { local selected selected="$(ghq list --full-path | peco --query="$READLINE_LINE")" if [ -n "$selected" ]; then READLINE_LI

昔に書いたものなので余り参考になさらずに 僕はターミナルに引きこもっています。たまに外出しても最寄りのブラウザ程度です。そんな僕は Mac を使っています。綺麗な UNIX だからです。ターミナルアプリとしてターミナル.app を使っています。iTerm2 含めいろいろ試しましたがコレがさいつよでした。そして、僕は 2 年半かけてさいつよ環境を築き上げました。 tl;dr 最強のターミナル開発環境の構築する 最強の開発環境を目指して タイトルで豪語しすぎた感はありますが、本気で構築中です。僕がターミナル環境の整備に目覚めたのは学生の時でした。特に何かのプロジェクトに携わるといったこともなく、たまに講義の課題を解いたり趣味のアプリを作成したりといった程度での開発だったので、環境構築や整備に割く時間がありました。 まずは現状 普段のターミナル環境は次のとおりです。 ターミナル.app（全画面）

#!/bin/bash # Check arguments if [[ -z $1 ]]; then echo "too few argument" 1>&2 exit 1 elif [[ ! $1 =~ ^(((https?|git)://)?github.com/)?[A-Za-z0-9_-]+/[A-Za-z0-9_-]+(\.git)?$ ]]; then echo "$1: invalid github.com URL" 1>&2 exit 1 fi # Format username/reponame uri="$(echo "$1" | perl -pe "s/^((https?|git):\/\/)?(github\.com\/)?//;s/\.git$//")" username="${uri%/*}" reponame="${uri#*/}" # Destination

tl;dr よく使われるコマンドの一つに cd コマンドがあります。ターミナル生活の 80% 近くは cd と ls である、という英文記事を何処かで見かけました。それを効率化しようという Tips です。 目的 cd はよく使われるのに使い勝手が悪いコマンドである気がしてなりません。cd コマンドは有効なパス（相対パス、絶対パスは問わず）しか解釈してくれないからです。つまり、存在していて尚且つパスが解決できるものに限るのです。例えば、ホームディレクトリにいるときに、/home/lisa/work/dir に行こうとして cd dir とだけタイプしても no such file or directory （そんなディレクトリは見当たらないよ！）と言われてしまいます。きちんとした経路でなければならないのです。いちいちパスを覚えていない場合や、部分的にしか思い出せない場合には結構面倒ですよね

【2015/07/16 追記】優れた dotfiles を設計する - TELLME.TOKYO この記事では書かなかった全体のロジックについて書きました Dotfiles Driven Development dotfiles とは Unix 系 OS で俗に言う設定ファイルのことです。.vimrc や .zshrc など、設定ファイルの多くは隠しファイルとしてファイル名の頭にドットがつくことからそう呼ばれています。 ほとんどのエンジニアは CLI 環境での開発は避けては通れないものに思います。CLI 環境は「黒い画面」として敬遠されがちで、CLI になると格段に作業効率がダウンする人も少なく無いです。その作業を効率化するキーとなるのは、設定ファイルの習熟度にあると思います。GUI 開発環境と比べてこちらはテキストベースでカスタマイズできるため、究極まで自分好みに合わせることが可能です。

Help us understand the problem. What are the problem?

最新の類似投稿としてシェルスクリプトのコーディングルール2014も併せてどうぞ。 2014/10/09追記 ぼくがシェルスクリプトを書くときに気にしていること、過去の失敗で書き留めたことを忘れないために。 1. グローバル変数は大文字 PATH や HOME など、環境変数が大文字なので、エクスポートする変数を大文字で書くという習慣は一般的であるような気がしますが、エクスポートする変数を抱えるシェルスクリプトを作成する機会が稀なので。 グローバル変数は大文字 ローカル変数は小文字 エクスポートする変数も大文字 関数内からグローバル変数にアクセスする場合がありますが、やはり区別していると、可読性が増すような気がするのでお勧めです。 2. awk を知る Unix 上にて文書処理をするときに、数多くのフィルタコマンド（grep、cut、tr、head、sort、uniq、sed、awk、wc、