R/O

CLI で GitHub のようにファイルを一覧表示する

2022-07-31T08:39:38Z

CLI でも GitHub 等のようにファイルごとの最終更新を一覧表示したくなることがあるので、簡単なスクリプトを書いた。 git-ls としてパスの通った場所に置いて git ls で使えるようにしている。

#!/bin/sh

ls_file() {
    file_path="${1%%/}"
    file_basename=$(basename "${file_path}")
    ls_tree_opt=
    if [ -d "${file_path}" ]; then
        file_basename="${file_basename}/"
        ls_tree_opt='-d'
    fi
    file_mode=$(git ls-tree ${ls_tree_opt} HEAD -- "${file_path}" | cut -d ' ' -f 1)
    if [ -n "${file_mode}" ]; then
        git log -1 --pretty=format:"${file_mode} ${file_basename} %x09 %h %s %x09 %cr%n" HEAD -- "${file_path}"
    else
        printf '%s %s \t %s \t uncommitted\n' '------' "${file_basename}" '-------'
    fi
}

path="${1:-.}"
if [ -f "${path}" ]; then
    pattern="${path}"
elif [ -d "${path}" ]; then
    pattern="${path}/.* ${path}/*"
else
    echo "no such file or directory: ${path}"
    exit 1
fi

for file in ${pattern}; do
    case "${file}" in
    "${path}"/.|"${path}"/..)
        continue
        ;;
    "${path}"/.git)
        continue
        ;;
    "${path}/.*"|"${file}/*")
        continue
        ;;
    esac
    ls_file "${file##./}"
done | column -t -s '	'

Gist にも置いてある: https://gist.github.com/ryot4/245a4b2c28b064c68c1d957b8d580d18

サンプルとして https://github.com/githubtraining/hellogitworld で使ってみると以下のような表示になる。

hellogitworld $ git ls
100644 .gitattributes    bf7a9a5 .gitattributes to make this play nicely onWindows          10 years ago
100644 .gitignore        d2280d0 Adding maven build script                                  10 years ago
100644 .travis.yml       9805760 Fix YAML name-value pair missing space                     8 years ago
100644 README.txt        a13dba1 Even I can change the readme file                          9 years ago
100644 build.gradle      c594793 Added gradle build file                                    10 years ago
100644 fix.txt           78f4771 Fixes #1                                                   10 years ago
100644 pom.xml           ef7bebf Fix groupId after package refactor                         8 years ago
040000 resources/        755fd57 Addition of the README and basic Groovy source samples.    11 years ago
100755 runme.sh          f5ed019 Added shell script to drive the execution of the app       11 years ago
040000 src/              ebbbf77 Update package name, directory                             8 years ago

ファイルの数だけ git log を叩く実装なのでリポジトリによっては結構重い点は要注意。

pushd と popd が少しだけ楽になるかもしれない Bash function

2021-03-25T16:27:38Z

bashrc で引数を与えるとそこに pushd し、与えないと popd するだけの関数を定義して使っている。

pd()
{
    if [[ -n ${1} ]]; then
        pushd "${1}"
    else
        popd
    fi
}

これだけ。push と pop を同じコマンドで行えるところが慣れると便利で割と気に入っている。

go:embed で CLI ツールのシェル補完スクリプトをバイナリに埋め込む

2021-02-28T16:48:56Z

Go 1.16 で入った go:embed を使って、自作の CLI ツール sidenote¹ のシェル補完用スクリプトをバイナリに埋め込んでみた。

Embed shell completion script in the binary · ryot4/sidenote@c2ddebe

テキストファイルの内容を文字列として埋め込むだけなら非常に簡単で、以下のようにするだけ。

embed パッケージを import する
```
import _ "embed"
```
string 変数の宣言の前に //go:embed <ファイル> で埋め込みたいファイルを指定する
```
//go:embed path/to/file.txt
var embeddedFileContent string
```

sidenote では埋め込んだスクリプトを出力するだけの completion サブコマンドを追加²して、Bash であれば ~/.bashrc に

source <(sidenote completion bash)

と書いておけばシェル補完を有効化できるようにした。

Go で CLI ツールを作る利点の一つにツールがシングルバイナリで動作することがあるが、シェル補完用スクリプトのようにツール本体とは別の付属物がある場合、バイナリに埋め込んでしまうことでユーザに別途インストールしてもらう手間を省くことができる。³ 特に (アーカイブ形式での配布ではなく) go install でインストールすることを想定しているようなものの場合はうれしいと思う。

バイナリにファイルを埋め込むためのパッケージは以前から色々と存在していたものの、sidenote はなるべく依存関係を小さく保っておきたい意図で Go の標準ライブラリ以外は使わないようにしていて、自前でファイル埋め込みを実現するのも大変そうなので対応していなかった。そういう意味で標準のツールチェインでサポートされるようになったことはありがたい。

sidenote については以前の記事を参照 ↩
サブコマンド名は kubectl にならった ↩
これは付属物だけをアップデートしたい場合でもバイナリ全体を更新する必要がある、ということでもあるので、何でもかんでも埋め込めば良いということではない ↩

CLI での作業メモをディレクトリ単位で管理する

2021-01-16T14:41:12Z

作業メモの管理どうする問題

コンピュータ上で何かしら作業をしながらメモを取る場合、人によって色々な流儀があると思う。私はターミナル上でテキストエディタ (Vim) を起動してプレーンテキストで書くことが多い。

そうしているとテキストファイルの管理に困りがちで、

何も考えずに作業ディレクトリに転がしておく → ディレクトリが散らかる。特にバージョン管理されているディレクトリでは、個人的なメモを誤ってリポジトリに入れないように気を付けるのが面倒
メモ置き場を一つ決めてそこに全部放り込む → 作業とメモが紐づかない。しばらく作業から離れるとメモを探すのに手間取ったり、メモの存在自体を忘れたりする

というようなことがあり、折衷案として作業ディレクトリごとにメモ置き場を用意する方法を考えた。案というほど大したものではなくて、単に専用のディレクトリ (.notes) を作って全部そこに入れるだけ。

$ mkdir .notes
$ vim .notes/TODO

こうしておくと作業ディレクトリの直下がメモで散らかることはないし、バージョン管理システムに無視させる場合もディレクトリ一つの方が扱いやすい。Git の場合は ~/.config/git/ignore にグローバルな ignore 設定を書ける¹ ので、そこに .notes を追加するだけで済む。

作業ディレクトリからたどって参照したいけれど、ファイルの実体は作業ディレクトリの外に置いておきたい、という場合もある。例えば定期的にメモのバックアップを取ることを考えると、作業ディレクトリごとに散らばっているよりは一か所にまとまっているほうが扱いやすい。これはシンボリックリンクを使えば簡単に実現できる。

$ mkdir -p ~/notes/some-project
$ ln -s ~/notes/some-project/ .notes
$ vim .notes/TODO

これですべて解決……とはならなくて、

毎回 vim .notes/TODO のようにパスを指定するのは面倒
サブディレクトリからメモを開こうとすると vim ../../.notes/TODO みたいなのが発生しがちで、やはり面倒

という問題がある。このあたりの手間を減らすものがあるとうれしい……ということで、sidenote という小さい CLI ツールを作って使っている。

sidenote のかんたんな紹介

インストール方法は README を参照。シングルバイナリで動くコマンドで、Bash 用のコマンドライン補完もある。

機能はサブコマンドに分かれていて、v0.1.6 時点では以下の通り。

$ sidenote -h
Usage: sidenote [-d path] [-version] <command> [command-arguments]

options:
  -d string
        Specify the directory for notes (env: SIDENOTE_DIR)
  -version
        Print the version and exit

commands:
  cat       Print contents of notes
  edit      Open notes with the editor ($VISUAL or $EDITOR)
  import    Import a note from the existing file or the standard input
  init      Initialize the directory for notes
  ls        List notes
  path      Print the path of notes
  rm        Remove notes
  serve     Serve notes over HTTP
  show      Open notes with $PAGER

Run sidenote <command> -h for usage of each command.

何かを書きたくなったら、まず init コマンドでカレントディレクトリ直下にディレクトリ (デフォルトでは .notes、名前は変更可能) を作る。

$ sidenote init
initialized .notes
$ ls -dl .notes
drwxr-xr-x 2 ryot4 ryot4 4096 Feb  9 19:03 .notes

カレントディレクトリの外にファイルを置きたい場合は init -l にパスを与えてその場所へのシンボリックリンクを作る。指定したパスにディレクトリが存在しない場合は自動的に作成される。

$ sidenote init -l ~/Documents/notes
initialized .notes (-> /home/ryot4/Documents/notes)
$ ls -l .notes
lrwxrwxrwx 1 ryot4 ryot4 31 Feb  9 19:03 .notes -> /home/ryot4/Documents/notes

準備は以上で、メモの作成・編集は edit コマンドで行う。例えば、

$ sidenote edit TODO

とすると .notes/TODO をデフォルトのエディタ ($VISUAL または $EDITOR に設定されているもの) で開く。 .notes/ の部分は裏側で自動的に補われるので手で指定する必要はない。

カレントディレクトリに .notes が存在しない場合、sidenote はディレクトリ階層を上にたどって探す。² 例えば

$ tree -aF project
project/
├── .notes/
│   └── TODO
└── src/
    └── module/

    3 directories, 1 file

のようなディレクトリ構造がある場合、module ディレクトリの中で sidenote edit TODO を実行すると

module の直下には .notes が無いので一階層上の src を見る
src の直下にも .notes が無いので一階層上の project を見る
project の直下に .notes があるので、その中の TODO をエディタで開く

という動きになる。この挙動によってサブディレクトリの中でも相対パスを意識せずにファイルを扱える。

基本はこれだけで、他にファイルの一覧 (ls) や内容の表示 (cat / show)、削除 (rm) などを行うコマンドがある (より詳しい使い方は README を参照)。

既存のコマンドを使って楽をする

sidenote コマンドはなるべく単純なものにしたいと思っていて、例えば検索を行うサブコマンドは存在しない。代わりに .notes ディレクトリの場所を出力する path コマンドがあって、これと既存の検索コマンドの組み合わせで検索を行えるようになっている。

path コマンドは今いるディレクトリに対応する .notes ディレクトリのパスを出力するもので、上の module ディレクトリの例だと以下のようになる。

module$ sidenote path
../../.notes

これを使うと、例えば全てのメモの中から XXX という文字列を grep したい場合は以下のようにできる。

$ grep -R XXX "$(sidenote path)"

例えば sidenote grep XXX のような組み込みの検索コマンドを用意する方が直感的でコマンド入力も楽になるけれど、path と外部コマンドを組み合わせる方法は検索に grep 以外のものを使いたくなった場合でも対応できるし、検索に限らず「ファイルパスを受け取って何かする」類の処理全般に応用できるので柔軟性がある。何より、実装量を減らせるので楽で良い。

同様に、cd "$(sidenote path)" でメモの在りかに移動すれば通常のファイル操作を行えるので、cp や mv のような複雑なファイル操作 ³ もサブコマンドとしては用意していない。

実装

sidenote は Go で書いた。この手のツールは簡単に使い始められることが重要だと思うので、シングルバイナリで動作する点は大きい。また、依存関係のメンテナンスを考えずに済むように Go の標準ライブラリだけを使用して書いている。大したことはしていないので実際のところシェルスクリプトで書いても良かったかもしれないけれど、それはそれで実装が辛いことになっていたかもしれない。

あと、Bash のコマンドライン補完をまともに実装したのはこれが初めてだった。通常と異なるファイルパスの解釈をするツールなのでファイルパスの補完を行う _filedir がそのまま使えなかったりしてやや苦労したものの、やはり補完の有り無しでコマンドの使い勝手に天と地の差があるので用意してよかったと思う。

正確には $XDG_CONFIG_HOME/git/ignore ↩
これは git コマンドが .git を探す際の挙動とだいたい同じ ↩
単純そうに見えるが、ちゃんと実装しようとすると考えるべきことが多くて大変 ↩

ターミナルのカラースキームを自作した

2020-06-26T14:12:38Z

長時間ターミナルを眺めて作業していると目の疲れを感じることが増えてきたので、目に優しい配色を目指してターミナルのカラースキームを自作してみた¹。

以下で公開している。(2021-04-11 追記: 名前を変えて GitHub に移した)

ryot4/Hikage

全体的に彩度を抑えているのが特徴。数日間使ってみて目が痛くなったりはしていないので、それなりに目論見通りにはできた気がする。(使いながら何度か調整はした)

使ったもの

これからカラースキームを作りたい人の参考になるかもしれないので紹介。

terminal.sexy: Web ブラウザ上でターミナルのカラースキームを作成できるツール²。iTerm2 や Xresources などの設定をインポートして別のフォーマットでエクスポートできるので、自分ではカラースキームを作らない場合にも役立つかもしれない。
Contrast Checker: 2つの色 (前景色と背景色) のコントラスト比を確認できるツール。色の組み合わせが WCAG 2.0 に適合しているかどうか教えてくれるので、見やすさに問題がないか客観的に確認できる。
Windows Terminal: 設定がテキストファイルで、保存すると即座に画面に反映される点は試行錯誤するのに便利だった。

見栄えの確認は実際に色付きの出力をするコマンド (ls とか vim とか tmux とか) で試すほかに、簡単なスクリプトで色の組み合わせを一覧表示³して眺めたりもした。

#!/bin/sh

echo
for bg in '' $(seq 40 47); do
    for bold in '' 1; do
        for fg in '' $(seq 30 37); do
            code="${bold}${fg:+;$fg}${bg:+;$bg}"
            code="${code#;}"
            printf '\033[%sm%7sm \033[0m' "${code}" "${code}"
        done
        echo
    done
done
echo

出力はこんな感じになる。

ここ数年は Tango Desktop Project のカラーパレット (を少しいじったもの) を使っていた。最近だと Windows Terminal のデフォルト設定にも Tango のカラースキームが付属している。 ↩
他に Web 上でターミナルのカラースキームを作成できるツールとしては 4bit Terminal Color Scheme Designer がある。こちらは個々の色を細かくいじることはできないが、その分手軽で統一感のあるカラースキームを作りやすい。 ↩
ターミナル上での色付き出力は ANSI エスケープコードを使って行う。この手のスクリプトは Web 上で探すといろいろ見つかるが、Bash Prompt HOWTO 6.1. Colours の最後に載っているものがカラースキームの紹介ではよく使われている (と思う)。 ↩