2020/11/07

tmux 3.1c の window 分割線を ascii character にする

2020/10/30(Fri) に tmux 3.1c がリリースされました
という事で、恒例の EastAsianAmbiguous を ascii に変更したバージョンを作成します。
過去の作業履歴は 3.1b や 3.0a や 2.9a  に、そもそもの問題についてはこの記事にまとめています。


環境

  • OS: macOS Mojave 10.14.6
  • tmux: 3.1c-border-ascii 7e7a923b7cd2e7cc8d2450e8a8e20838ded13298
  • Homebrew: 2.5.8-118-g2ac5cff
    • Homebrew/homebrew-core (git revision ce1b1; last commit 2020-11-06)
  • Font: Ricty 4.1.1


インストール方法

  • $ brew install --HEAD atton/customs/tmux
でインストールできます。


今回の作業

 3.1b と 3.1c の違いはほぼ無いようなものなので、 cherry-pick で対応できました。

2020/08/16

PS4 の Prime Video の「次に観る」リストから消した作品を再度表示させる

私は Prime Video を観る際、大体 Play Station 4 を使っています。
Prime Video は「次に観る」というリストが視聴履歴から自動的に作成される為、放送中の作品を追うのに便利です。
観終わった作品をリストから削除していると、誤ってまだ観ていない作品を削除してしまいました。
すると、ウォッチリストに追加している作品にも関わらず、リストに表示されなくなりました。それを解決したお話です。


環境

  • Play Station 4 システムソフトウェア: 7.51
  • Prime Video: 3.13


元に戻す方法

作品を「次に観る」リストに再度表示させるには
  • Amazon.co.jp にログイン
  • [マイストア] -> [おすすめ作品を正確にする] -> [興味が無い商品] を表示
  • 再度表示させたい作品の「興味がありません」のチェックを外す
事で解決します。


余談: 「次に観る」に表示されなくなる条件

非表示になる条件は以下の2つがあります。
特に後者の場合、ウォッチリストに追加していても表示されません(前者は未確認)。

PS4 の Prime Video で「リストから削除」を実行すると「興味が無い商品」に登録される、後者の挙動を取ります。
Web の Prime Video では「このシーズンを表示にする」という名前に変わっていますが、こちらも後者の挙動を取ります。
なので「興味が無い商品」の登録から作品を削除すると、リストに再度表示されるようになります。


参考

2020/07/19

GitHub へ push した際に Docker Hub で docker image を自動 build する

過去に「GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した」という記事を書きました。
前回は image の build を GitHub で行なっていましたが、今回は Docker Hub で build するように変更したお話です。


Docker Hub で docker image を build する

GitHub と連携した automated build という機能を利用しました(設定方法はドキュメント参照)。
前回同様、GitHub に push すると自動的に Docker Hub に image が更新されます。


これまた前回同様、以降は作業ログ等です。


何故構成を変更したのか

image を更新する為に Docker Hub を触っていた時、 GitHub 連携の存在に気付いた為です。
ちなみに、更新していた image は latex-make というもので、MacTeX をインストールせずに LaTeX を実行できる image です。
更新内容は TeX Live 2019 から TeX Live 2020 へのアップデートでした。


GitHub Actions 作成時に気にしていた3つの条件のゆくえ

過去の記事では以下の3つの条件を気にしていました。
  • Dockerfile が増えた場合も自動で対応する
  • Dockerfile や関連ファイルに更新が無い Image は Push しない
  • GitHub Actions だけでなく、ローカルの環境でも build できる
第1条件と第2条件は、 Repository を分割して解決としました(latex-make, webpage-title)。
第3条件はビルドスクリプトをローカルマシンに残す事で解決としました。


構成を変更して良かった点

  • 他の image の README を参考にした結果、 README が整備された
    • latex-make には使用例が無かったので追記した
    • shields.io を利用して image のサイズ等のバッジを追加
    • GitHub/Docker Hub の README を(手動で)統一
  • Docker Hub に automated build のログが残るようになった
    • 前回は「push したユーザは atton, push 時刻」程度の情報しか無かった
  • ログイン情報を書くが必要無い
    • 連携時に Docker Hub から GitHub へ権限を要求しているので docker login を実行する必要は無い
    • 具体的に言うと GitHub Actions ではログインパスワードを Secrets に書いていた
      • なので、Docker Hub のログインパスワードを変更後、Secrets を更新しないと docker login に失敗する


構成を変更して良くなかった点

  • 移行作業が手作業だった
    • 対象となる docker image が2つのみだったので、手作業で移行を行なった
    • 仮に docker image が多かった場合、移行スクリプト等を書く必要があったかもしれない
  • 第2条件が若干緩くなった
    • master が更新された際に build が行なわれるので、 README だけの変更 commit でも build が発生する
    • git の tag をトリガーにして build する、等の設定で修正可能
    • しかし現状の image の tag は latest しか無いので放置中

2020/06/09

GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した

私は作成した Dockerfile を GitHub で公開しています(前回の記事の atton/webpage-title も含む)。
Docker Image を手動で管理するのは面倒なので、何らかの形で自動化する事にしました。
最終的に、 Dockerfile が更新された際に build して DockerHub に push する GitHub Actions を作成しました。


GitHub Actions を作成する際に考慮した条件

  • Dockerfile が増えた場合も自動で対応する(現時点では2つ)
  • Dockerfile や関連ファイルに更新が無い Image は Push しない
  • GitHub Actions だけでなく、ローカルの環境でも build できる


具体的な GitHub Actions の内容

作成した .github/workflows/build-and-push.yml とbuild.sh は以下です(commit: 427f143)。

自動化できたので手動 push の必要は無くなりました。べんり。

これ以降は作業ログなどを書いておきますが、かなり長いです。


第一条件: Dockerfile が増えた場合も自動で対応する

この条件については、特定の構成をしているディレクトリを build 対象にする事で対応しました。具体的には
  • ディレクトリ名は任意
    • ls と [ -d ] で確認
  • ディレクトリの直下に Dockerfile が存在する
    • ls と [ -f ] で確認
といったディレクトリです。なお、ディレクトリ名は Docker Image の tag を決める際に使っています。


第二条件: Dockerfile や関連ファイルに更新が無い Image は Push しない

Docker Image を自動 build する際、最初は elgohr/Publish-Docker-Github-Action@master を使っていました

ここで問題が発生。README.md を変更しただけの commit でも Docker Image の更新が行なわれました。
幸い、GitHub Actions の step では if が使えるようなので試してみましたが改善せず。
なので elgohr/Publish-Docker-Github-Action@master は利用しない方針に変更。
使わない事になりましたが、 entrypoint.sh に書かれた(docker login/logout など)内容は参考にできそうです。

さて、次は「Dockerfile や関連ファイルに更新が無い」事を判定をできれば解決しそうです。ググってみると
で確認できるとの事。ではこれを grep して exit code で判定すれば解決、しませんでした。
更新の有無に関わらず、全ての grep の exit code が 1 になっていました。
加えて、ローカル環境では想定通りの exit code が得られるので、どうやら原因は実行環境固有のようです。

「ローカルでは動くが、別環境では動かない」という悲しい事態なので、 printf debug で少しずつ状態を確認していきます。
  • git は存在するか
  • git の version は何か
  • git は実行できるか
  • remote origin は存在するか
  • commit log は辿る事ができるか
  • grep の version は何か
  • ...
結果、「actions/checkout@master を使うと repository の情報が消える(?)」事が判明しました。具体的には
  • git コマンドは実行できる
  • git show を行なうと、全ファイルが新規作成扱いになっている
  • origin を fetch しても commit が取得できない
という謎の状態でした。その為、 actions/checkout@master は利用せずに直接 git clone を実行。
clone した repository では diff-tree が実行可能で、更新の有無が判定可能になりました。


余談: 第二条件の部分を書いている時に思った事

  • elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。
    • Pull Request を作成して提案する手がある
  • 「ローカルでは動くが、別環境では動かない」
    • GitHub で動作 Image を提供している可能性がある
  • 「actions/checkout@master を使うと repository の情報が消える(?)」
    • 今は git clone で対応できるが、 branch の指定といったオプションに対応できない


第三条件: GitHub Actions だけでなく、ローカルの環境でも build できる

この条件は「ローカル環境でも Docker Image を作成可能」にする為につけました。メリットとしては
  • 問題発生時の再現に使用できる
  • commit 前の Dockerfile も試しに build できる
  • 新しい Image 作成時の build が楽
等があります。なお、この条件は build.sh に与える引数の有無で解決しました。


まとめ

結構な文量になりました。debug の説明を含めると長くなりますね。
結果的に「uses を排除して自前の run で記述する」というオレオレ GtiHub Actions で解決。
前回も書いた気がしますが、「個人的には十分満足しているので良しとします。」


参考文献や関連した文献など

2020/06/01

chromium-browser を使って記事のタイトルを取得する

私はブログに記事を引用する際、 URL だけ書く事はあまりしません。
何かの文字列に関連付けたり、記事のタイトルに関連付けます。特に後者は参考文献の場合によく行ないます。
これが結構面倒なので、タイトルを取得する Docker Image を作りました、というログです。


環境

  • OS: macOS Mojave 10.14.6
  • Docker for Mac: version 19.03.8, build afacb8b


実行例

  • $ docker run --rm atton/webpage-title 'https://attonblog.blogspot.com/2020/04/upgrade-awscli-with-linked-python38.html'
  • => atton.blog: Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する
    • '、' は curl で取得すると escape されて 、 になる事についても問題無し。


作成した経緯

最初は curl に grep で title タグを取得する、くらいの shellscript を使っていました。
それが次第にタグの attributes を考慮したり、sed を挟んだり、と色々拡張する事に。
最終的に『header に title は無く、JavaScript で後から設定する』サイトに遭遇。これは curl では厳しい。

この際ブラウザを動した方が色々と問題解決できるのでは、という事で chromium を headless で動かす事にしました。
DockerHub の repository は atton/webpage-title で、Dockerfile は GitHub に置いてあります

記事のタイトルを取得する為だけに大仰なのでは、という感もあります。
ですが、現状タイトルの取得に失敗した事が無いので、個人的には十分満足しています。

2020/05/05

tmux 3.1b の window 分割線を ascii character にする

2020/05/04(Mon) に tmux 3.1b がリリースされました
という事で、いつも通り EastAsianAmbiguous を ascii に変更するバージョンを作成します。
過去の作業履歴は 3.0a や 2.9a や 2.8 に、そもそもの問題についてはこのこのポストにまとめています。


環境

  • OS: macOS Mojave 10.14.6
  • tmux: 3.1b-border-ascii 526f000f29abadeef9f804bb9aea5291b913a312
  • Homebrew:  2.2.15-2-gb06a7af
    • Homebrew/homebrew-core (git revision 0058c; last commit 2020-05-04)
  • Font: Ricty 3.2.2


インストール方法

  • $ brew install --HEAD atton/customs/tmux
でインストールできます。


本家との diff : utf8proc を使わない

しかし、 utf8proc は現時点の最新バージョンである 2.5.0 でも EastAsianAmbiguous 対応はされていません。
前回(2.3, 2.2.0)のように utf8proc を変更する選択肢もありました。
ですが、 tmux のソースを読むと utf8proc が無い場合 wcwidth を使うようなので、変更しない選択肢もありそうです。
試しに utf8proc を抜いてビルドした tmux を軽く触っても、特段違和感は無し。
とりあえず YAGNI の精神で、今回は utf8proc を使わない事にしました。


前回との diff : atton/tmux の default branch を master から border-ascii に変更

これは tmux へパッチを当てる運用方法の変更です。

ローカルで設定している remote repository は以下の2つ。
  • origin: atton/tmux
  • upstream: tmux/tmux
upstream を fetch して origin に反映させつつ、リリースがあれば対応するパッチを当てる、という運用でした。

ここで面倒だったのが、両方の master の使い分け。
例えば upstream/master の変更を origin/master に適用する時は
  • $ git fetch upstream
  • $ git checkout origin/master
  • $ git rebase upstream/master
と、prefix を指定する必要があります。それに加えて、紛らわしいのも改善したい。

そこで、atton/tmux の master は削除して default branch を border-ascii に変更
そしてローカルの tmux は master の remote tracking branch を upstrem/master に指定。具体的には以下のような感じ
  • $ git checkout master
  • $ git branch -u upstream/master
これにより master は tmux/tmux に追従し、他のブランチは atton/tmux に反映される、という状態にできました。


前回との diff : GitHub Actions の追加

GitHub Actions を2ヶ所で利用しています。

1ヶ所目は atton/tmux で、centos 環境で make 可能かチェックしています。
2ヶ所目は atton/homebrew-customs で、macOS 環境で make 可能かチェックしています。

GitHub Actions では mac と docker が使えるので、様々な環境下でテストできる点が良いですね。

2020/04/19

Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する

Homebrew が提供する awscli が 2.0 になる前辺り、必要な python が python@3.8 になりました
awscli を upgrade する際、 python を消して python@3.8 を使うようにしたログです。


環境(ブログ作成時)

  • OS: macOS Mojave 10.14.6
  • Homebrew: 2.2.13-74-gecea0e5
    • homebrew-core (git revision eb6d; last commit 2020-04-19)
    • python: Python3.7.7
    • python@3.8: Python 3.8.2
  • awscli: aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12


keg-only formula と Homebrew の install 事情

Homebrew は元々、 /usr/local/bin へ直接 formula を install しません。
/usr/local/Cellar などの PATH に install して、そこから symlink を貼ります。

その中で key-only formula は「install しても /usr/local/bin に link しない」 formula です。
今回は python@3.8 が keg-only に指定されています。理由として executable の衝突回避が挙げられます。
  • 前提として、現時点で Homebrew が提供している python は 3.7 系列
  • python が存在する環境に python@3.8 も installすると /usr/local/bin/python3 が重複する
  • /usr/local/bin/python3 を 3.7 系列に譲るために、 3.8 は keg-only として link しない
という感じかと思われます。


keg-only formula を link する前の確認

 link の前に、念の為 python が使われていないか、以下のコマンドでチェックします。
  • $ brew uses --installed python
何も出力されない場合は install 済みの formulas 全てにおいて python を使っていません。
出力がある場合、その formula は python を使っています。 3.8 の link は止めた方が良いでしょう。


python@3.8 を /usr/local/bin に link する

上記のチェック時、私の環境では出力が無かった為 python@3.8 を link する事にしました。
なお、 keg-only formula を link する場合は --force が必要です。
  • $ brew upgrade awscli
    • 依存関係で python@3.8 が install される
  • $ brew link --force python@3.8
  • $ which python3 aws
    • /usr/local/bin/python3
    • /usr/local/bin/aws
  • $ python3 -V
    • Python 3.8.2
  • $ aws --version
    • aws-cli/2.0.8 Python/3.8.2 Darwin/18.7.0 botocore/2.0.0dev12
これで python3 と awscli が upgrade できました。良し良し。
ちなみに homebrew-bundle では、 link: true を付けると link してくれます

2020/03/29

pry 0.13.0 で後方互換性を保ちつつ history file の path を設定する

pry が 0.13.0 になった際、実行履歴ファイルの指定方法が変更になった事への対応。加えて後方互換もつけたログ。


pry の警告(ruby 2.7.0 + pry 0.12.2)

ruby 2.7.0 で pry 0.12.2 を起動すると、以下のような警告が出ていました。
私は怠惰なエンジニアなので、問題が発生するまでは様子見をする事にしました。


pry 0.13.0 Released

そして、2020/03/21 に pry の version 0.13.0 がリリースされました。
素晴らしい事に起動時に例の警告が出ません。 pry の開発陣に感謝ですね。
しかし、これでハッピーエンド、という訳にはいきませんでした。


Pry.config の変更

私は pry の history file の path を指定していました。具体的な設定は以下。
0.12.2 はこの設定方法で問題ありませんでした。
しかし、 0.13.0 では設定方法が変わったようで、以下のように NoMethodError が発生します。
という事で設定方法を調べてみます。


設定方法探し

さて、指針も無く彷徨っても仕方が無いので、まずはそれらしい場所にあたりをつけます。
設定時、 Pry.config と書くので、 Config class か module あたりが無いか探します。
  • $ git grep Config
すると lib/pry/config.rb に Config class がありました。
流し読みしつつ、 history で検索します。そうすると history に関連するコードの集まりを見付けました。
さらに言えば history_file なる attribute がありますね。とてもとても怪しい。

Pry.config.history_file の値を pry で確認すると、今書き込まれている history の path でした。
変数が特定できたので、まずは path を代入してみます。 弾かれないか心配でしたが特に問題無し。
pryrc で Pry.config.history_file を設定すると、指定した path に history が書き込まれました。これで解決。

なお、history_file 辺りを blame して commit を確認する
`Pry.config.history.file` becomes `Pry.config.history_file`
とありました。なので調べた結論で正しそうです。


0.13.0 以前の history との互換性

さて、 pry 0.13.0 で history file の path を指定できました。

しかし bundler で gem を管理していると、バージョンが異なる pry が複数、なんてケースもあると思います。
幸い history file の中身は plain text なので、バージョン毎の違いは恐らくありません。
各 pry で同じ history の path を指定する事で、今まで通りバージョンに関わらず共通の history を参照できるはずです。
ということでバージョンが低い pry も考慮に入れた pryrc が以下。

  • respond_to? でバージョン確認
  • path は instance variable で一時的に定義して最後は消す
といった感じにしました。今の所は問題無く動作しています。

2020/02/09

neovim + deoplete で kebab-case の補完をする

kebab-case(単語をハイフンで区切る) は snake_case や camelCase に比べ、比較的使われていないと思います。
ですが、 apt-get や docker-compose を打っていると少し利点を感じました。
  • 「Shift Key を押さなくて良い」
怠惰な私にとって採用理由として十分。なので zsh で使う function は kebab-case で記述しています

さて、ここで小さな問題が発生しました。
neovim で利用している補完プラグインの deoplete が、default の設定では kebab-case を補完してくれない。
と、いうことで kebab-case も補完対象にするように設定したログです。


環境

  • OS: macOS Mojave 10.14.6
  • zsh: 5.7.1 (x86_64-apple-darwin18.2.0)
  • neovim: v0.4.3
  • deoplete: master(記事執筆時 6e01000280)
  • Python: 3.7.6
  • pynvim: 0.4.1


補完の設定

まず、補完の対象を設定する変数などが無いか、:help deoplete で探します。
ありました。keyword_patterns で filetype 別に正規表現を指定すれば良さそうです。
というか ruby の補完サンプルもありますね。末尾の ! や ? に対応している。便利そう。

話が逸れました。まず、kebab-case にマッチしそうな正規表現として
  • 最初の文字は alphabet と '_'
  • それ以降は alpabet と '_' と '-' が0回以上繰り返される
とします。これを具体的な正規表現にすると
  • [a-zA-Z_][a-zA-Z_-]*
で良さそうです。これを filetype zsh の補完に設定します。
何故 sh でなく zsh かと言うと、 sh では kebab-case のfunction が定義できない為です。

設定後、きちんと補完されるようになりました。良し良し。




おまけ(他の定義とか)

これで deoplete の補完対象の設定ができるようになりました。
zsh 以外の普段良く使う filetype の補完設定もしておきます。
  • ruby: 先程発見した ruby の補完設定で、先頭に '@' を加えたもの
  • text: 英数字も含めて補完対象を広めにしたもの
  • _: help にあった定義をそのまま利用。なお、この設定は全 filetype に適用されます
これらを鑑みて設定した、私用の具体的な keyword_patterns の設定はこんな感じ。以下抜粋。

2020/01/30

python2 に依存した Vim plugin が無いか確認と修正対応をしたお話

2020/01/01(Wed) に python2 のサポートが終了しました。が、今の所私の周辺で問題は発生していません。

Neovim で :checkhealth を実行していると、まだ python2 provider が有効な事にふと気付きました。
「いつか python2 provider も消えるのだろうな」と悠長に考えたのが1つ目の感想。
「python2 に依存した plugin があったらマズいのでは」と思って焦ったのが2つ目の感想。
「問題は発生していない」と思っているけれど、本当にそうなのか念のために確認+対応したログです。


環境

  • OS: macOS Mojave 10.14.6
  • Neovim: 0.4.3
  • Python2: 2.7.16 (system builtin)
  • Python3: 3.7.6 (installed by homebrew)


has('python') している plugin が無いか確認

私は Neovim の plugin management に dein を使っています。
そして、plugin の install 先は ~/.config/nvim/dein を指定しているので、その先に cd して grep をかけてみます。
  • $ cd ~/.config/nvim/dein/repos/github.com
  • $ egrep 'has\(.python.\)' -R .
egrep のオプションの -R は、指定したディレクトリを起点に recursive に探索してくれます。
そして、渡しているディレクトリは '.' なので、 カレントディレクトリ以下の全てのファイルを対象にできます。

egrep で指定した正規表現は 'has\(.python.\)' です。これは
  • まず、 vim/neovim で特定の feature が有効か確認する方法として 'has' function があります。
  • そして python2 provider が有効かどうかは has('python') の実行結果で分かります。
  • 加えて考慮する事として、python を括る文字が ' と " のどちらかの問題があります。
    • これは面倒なので . にしました。 ['"] 2つなどでもOKです。
  • 最後に、'()' は egrep パターンマッチに使う記号なので \ でエスケープします。

さて、実行結果は以下のようになりました。
前後のソースを読んではいないので、 現段階では対応が必要かもしれない plugin 一覧とします。


一時的に python2 provider を無効にする

Neovim で :help provider とすると、各 provider の説明が確認できます。
その中には provider を無効化する方法も存在しており、 python2 の場合は
  • let g:loaded_python_provider = 0
と ~/.config/nvim/init.vim に書くと無効化できます。

なお、この状態で :checkhealth を実行すると
  • - INFO: Disabled (g:loaded_python_provider=0).
と表示されます。

さて、これで仮に python2 provider が消えた時状態を再現できました。
先程 egrep で見付けたプラグインの動作確認を行なった結果、
が動作しませんでした。


VimCalc 対応: VimCalc -> VimCalc3

安直に「VimCalc python3」で検索をかけてみます。
そうすると、fedorenchik/VimCalc3 が見付かりました。なお、 fork 元は本家の gregsexton/VimCalc です。
お試しでインストールすると、ほぼ同じ動作。ということで VimCalc3 に乗り換えます。


gundo.vim 対応: let g:gundo_prefer_python3 = 1

さて、二度目も安直に「gundo.vim python3」でググります。
そうすると bitbucket の issue のページがヒットしました。どうやら既に対応済みだったらしく
  • let g:gundo_prefer_python3 = 1
と書くことで python3 を利用するようです。動作確認もできたので、 gundo.vim はそのまま使う事にします。


まとめ

これで Neovim がいつ python2 provider を消しても大丈夫になりました。

蛇足ですが、対応した2つのプラグインは利用頻度が低く、 LazyLoad していました。
なので、仮に Neovim が python2 provider を消したとしても、気付くのに時間がかかった可能性は十分にあります。
それを排除できたので、備えあれば何とやら、ですね。

2019/12/21

tmux 3.0a の window 分割線を ascii character にする

2019/12/01 に tmux  の version 3.0a がリリースされました
いつも通りに分割線を multibyte character から ascii にする作業をします。
過去の作業ログは 2.9a や 2.8 や 2.7 など。そもそもの問題についてはこの記事にあります。


環境



インストール方法

  • $ brew install --HEAD atton/customs/tmux
でインストールできます。


今回の変更

tmux は window や pane を表示するための文字情報を tty-acs.c に持っています。
なので、毎度この定義を修正する事で対応しています。
2.9a の時等は tty-acs.c に変更が無かった為、過去の commit の cherry-pick のみで目的が達成できました。
が、今回は修正が入っているので cherry-pick をすると conflict します。
conflict を解消する形で対応しても良いのですが、今回は新しく修正用の commit を作ることにしました。

過去のパッチ を参考にすると、置換が必要な文字とその対応関係は
  • j,k,l,m,n,t,u,v,w が "+"
  • x が "|"
  • q が "-"
  • ~ が "*"
のようです。これらを元に tty-acs.c を修正。make すると今まで通り動きました。
もちろん後から何か踏む可能性はありますが、今の所問題は発生していません。
ということで tmux のソースコードの更新は以上。
あとは branch 名を homebrew の atton/customs 用に付けてあげればおしまいです。

formula の更新は本家 tmux の --HEAD 版の定義を借りて、branch 名を指定すればOK。

と、いうことで tmux 3.0a-border-ascii の更新ログでした。


おまけ

分割線の定義を間違えると、分割した瞬間に tmux が crash します。こわい。
きちんと定義できれば以下のように割りたい放題しても動きます。


2019/12/15

AquaSKK で Sticky Shift を使う

私は普段、mac で日本語入力をする時は AquaSKK を使っています。
AquaSKK は version 4.7.0 から Stickey Shift が実装されたようなので設定してみました。


環境

  • OS: macOS Mojave 10.14.6
  • Homebrew: 2.1.15-63-g090259b
  • Homebrew/homebrew-cask: (git revision ec6b9; last commit 2019-10-26)
  • AquaSKK: 4.7.0
  • neovim: 0.4.2
  • eskk.vim: 207d05cd


AquaSKK の install

homebrew-cask に formula があるので
  • $ brew cask install aquaskk
で Install できます。


SKK とは

日本語のかな漢字変換プログラムの一つです。
形態素解析を行なわず、漢字に変換、もしくは送り仮名付きの漢字の変換箇所をユーザが指定して入力します。
何を言っているのかさっぱりな感じもあるので、具体的な例を見ていきましょう。


漢字変換

例えば『漢字』と入力したい場合、「ことえり」や「Google 日本語入力」では
  • kanzi<space> または kanji<space>
と入力します。
そして SKK では、変換を開始する入力を大文字のアルファベットで指定します。よって
  • Kanzi<space> または Kanji<space>
と入力します。


送り仮名付き漢字変換

さて、次は『感じ』と入力したい場合を想定します。
「ことえり」や「Google 日本語入力」では変わらずに
  • kanzi<space> または kanji<space>
と入力します。また、その時の変換候補に『漢字』が出ることもあるでしょう。
SKK では送り仮名付きの漢字変換の時の変換箇所も大文字アルファベットで指定します。つまり
  • KanZi<space> または KanJi<space>
と入力します。そうすると、「感じ」「観じ」といった送り仮名付きの変換候補しか出ません。

さらに言えば、先程の『漢字』の入力について
  • Kanzi<space> または Kanji<space>
と入力した場合の変換候補は「漢字」「幹事」「監事」といった、送り仮名無しの候補しか出ません。
これが結構便利で、「送り仮名あり、送り仮名無し」の入力に関しては誤字が少なくなります。


横道: 形態素解析をしない、ということ

例に上げたように、漢字入力の際や送り仮名付きの漢字入力では SKK にはメリットがあります。
しかし、変換のポイントを自分で指定するため
  • これは漢字の入力のテストです
といった入力は一度にはできません。

「ことえり」や「Google 日本語入力」では全てのアルファベットを入力した後、先頭から少しずつ変換することができます。
なので、それぞれ得手不得手がある、と思った方が良いかと思われます。


Sticky Shift とは

さて、ここまで来ると Sticky Shift のお話ができます。
Sticky Shift とは、変換の指定ポイントを大文字のアルファベットでは無く、特定の文字で指定する方法です。

例えば、';' を設定した場合、先程の「漢字と感じ」は
  • ;kanji<space>to;kan;ji
と入力できます。
一見冗長ですが、慣れると便利です。

加えて、大文字入力が必要無いので Shift Key を使わずに入力を完結させることができます。
なお、eskk.vim では default で ';' Key が Sticky Shift 用の文字として実装されています


Sticky Shift の設定

ので設定してみましょう。大元の設定をコピーして追記します。

なお、コピー先の ~/Library/Application\ Support/AquaSKK については、AquaSKK を install した時に作られています。
なので
  • $ cp /Library/Input\ Methods/AquaSKK.app/Contents/Resources/keymap.conf ~/Library/Application\ Support/AquaSKK
を実行してコピー。

そして ~/Library/Application\ Support/AquaSKK/keymap.conf に
  • StickyKey ;

その後、AquaSKK のプロセスを殺すか、reboot 等で AquaSKK が再起動すれば、Sticky Shift が有効になっているはずです。
めでたしめでたし。


参考

2019/11/17

Disable Text Replacement on Safari in Mojave

iOS で文字入力をする際、入力が億劫な定型文とかを登録してみる。
  • General > Keyboard > Text Replacement 
で追加できます。

そこそこ快適になったと思ったら、iCloud 経由で自動的に Mac にも sync される様子。
基本的には無害なのですが、一度 GitHub の sha1 の末尾が置換対象と認識されて誤爆しかけた。ので無効化させる事に。
以下、 iOS では Text Replacement を有効にしつつ、Mac では無効化したログ。意外と大冒険だった。


環境

  • OS: macOS Mojave 10.14.6
  • Saferi: Version 13.0.3 (14608.3.10.10.1)
  • iOS: 12.3.2 and 13.2.2


結論から言うと

以下のコマンドを実行すると Mac の Text Replacement 設定を全て削除できます。
  • $ echo 'delete from ZTEXTREPLACEMENTENTRY;' | sqlite3 ~/Library/KeyboardServices/TextReplacements.db
  • $ defaults delete -g NSUserDictionaryReplacementItems
これで macOS では Text Replacement が発生しなくなります。
あくまで delete なので、iOS 側で設定を追加すると、同期された設定を再度削除する必要があります。


設定が存在しないか探す

iCloud の設定等、怪しい部分を探すも、それらしきものを発見できず。


$ defaults write -g WebAutomaticTextReplacementEnabled -bool false

ググると同じ考えの人はいて、
  • $ defaults write -g WebAutomaticTextReplacementEnabled -bool false
すると良い、とのことで実行。しかし変化無し。

きちんと設定されているか分からないのでまずは設定を表示させる。
man defaults すると read があるので実行してみる。
  • $ defaults read -g WebAutomaticTextReplacementEnabled
    • => 0
0なので一応 false になってる、という事なのだろうか。
delete もあるので実行する。
  • $ defaults delete -g WebAutomaticTextReplacementEnabled
  • $ defaults read -g WebAutomaticTextReplacementEnabled
    • => The domain/default pair of (kCFPreferencesAnyApplication, WebAutomaticTextReplacementEnabled) does not exist
delete した場合は 0 すら返らないので、設定できていたことになる。
しかし効果は表れなかったので、この方法では無理そう。


$ defaults find TextReplacement

defaults には find 機能もあるようだったので、
  • $ defaults find TextReplacement
とすると大量の設定が返ってくる。

defaults は多分 NSUserDefauts を macOS 側からいじる用のコマンドだと思われる。
Application 毎に設定があるし、Application 側で値を変更したら defaults で見られる情報に変化があった。
具体的には 'com.apple.iWork.Keynote' の 'TSWPAutomaticTextReplacement' の値とか。
Keynote で Text Replacement を disable にすると 'TSWPAutomaticTextReplacement' の値が 0 になる。

ちなみに -g は global option らしい。
Safari だけに効くよう、以下のように domain を指定して設定してみる。
  • $ defaults write com.apple.Safari TSWPAutomaticTextReplacement -bool false
しかし無効化できず。うーん。


$ defaults write -g WebAutomaticTextReplacementEnabled -bool true

逆に 0 でなく 1 を設定してみる。そうすると 
  • Menu bar(Safari) > Edit > Substitutions
が select できるようになる。
その中の 'Text Replacement' を disable にすると置換が止まった。
後はこれを defaults のどこに書くのか調べると良さそう。

と、思ったがそうは問屋が卸さなかった。defaults を使っても設定が見付けられない。
その上、 Saferi で 新規 Window を開くと 'Text Replacement' が Enabled な Window が増える。
あと、mac を reboot したら Text Replacement がまた有効になる。
どこかに設定があるからそれに辿りつけば良いんだけれど、対症療法ではどうも分が悪そう。


$ defaults write -g NSUserDictionaryReplacementItems <dictionary>

設定の場所を特定するためにわざと 'hoge' とかを TextReplacement に追加する。
そして
  • $ defaults find hoge
で調べると、NSUserDictionaryReplacementItems という Dictionary に格納されている。

NSUserDictionaryReplacementItems をググると少ないが記事はある
それを辿ると ~/Library/Preferences/.GlobalPreferences.plist というファイルの存在が示唆されている。
  • $ ls ~/Library/Preferences/.GlobalPreferences.plist
すると一応存在している。
  • $ open -a XCode.app ~/Library/Preferences/.GlobalPreferences.plist
内容は defaults read -g と同じっぽい。のでこれをいじっても defaults とやっている事は変わらない筈。

またググって引っかかった記事によれば
  • NSUserReplacementItems は 10.8 より前のバージョンで使われている
  • NSUserDictionaryReplacementItems は 10.9 で使われてる
とのことで。NSUserDictionaryReplacementItems をいじることにする。

元の値を一度取り出して
  • $ defaults read -g NSUserDictionaryReplacementItems 
    • => '( { on = 1; replace = hoge; with = "hogefugapiyo"; } )'
on を 0 にして、書き込む
  • $ defaults write -g NSUserDictionaryReplacementItems '( { on = 0; replace = hoge; with = "hogefugapiyo"; } )'
しかし Text Replacement は発生してしまう。
が、 Safari を起動すると、Text Replacement が発生しなくなった。ということでコレで良さそうだ。
その後、 macOS を再起動しても on flag は 0 のままだった。これで解決かな。


復活する NSUserDictionaryReplacementItems

解決かと思ったがそうでも無かった。しばらくすると on flag が 1 になっていた。
iCloud から sync した時に 1 になるなら理解できるが、特に編集せずとも 1 になる時がある。

ググると DB に格納されている、という記事が。
  • $ ls /Library/Dictionaries/CoreDataUbiquitySupport/atton~*/UserDictionary/local/store/UserDictionary.db
確かにある。sqlite3 で中身を覗いてみるとデータが無い。
というか ls -l したら 0B だった。のでここでは無い。


ちなみに、 on flag が 1 になる再現条件の一つは
  • System Preferences > Keyboard > Text を見る
でした。とりあえず確認に使えるので再現方法が1つ見付かっただけありがたい。


echo 'delete from ZTEXTREPLACEMENTENTRY;' | sqlite3 ~/Library/KeyboardServices/TextReplacements.db

Dictionary の save 先が無いかなー、とかググっていると ~/Library/Spelling に text edit の auto correction の情報がある、という記事にぶつかる。

~/Library をいろいろ見ると
  • $ ls ~/Library/KeyboardServices/TextReplacements.db
という怪しい物体を発見。早速中を見る。
  • $  file KeyboardServices/TextReplacements.db
    • => KeyboardServices/TextReplacements.db: SQLite 3.x database, last written using SQLite version 3016000
  • $ sqlite3 ~/Library/KeyboardServices/TextReplacements.db
    • sqlite> .schema
      • CREATE TABLE ZTEXTREPLACEMENTENTRY
      • CREATE TABLE ZTRCLOUDKITSYNCSTATE 
      • CREATE INDEX ...
      • CREATE TABLE Z_PRIMARYKEY
      • CREATE TABLE Z_METADATA
      • CREATE TABLE Z_MODELCACHE
    • sqlite> select * from ZTEXTREPLACEMENTENTRY limit 1;
      • 4|1|1|0|0|582166527.750349|三度寝|さんどね|C561DE44-D3D9-4F37-95E6-5916FF62C390|bplist00=>X$versionX$objectsY$archiverT$top
システム設定が参照しているかはともかく、コイツが Text Replacement のデータを保存しているのは間違いなさそう。

とりあえずバックアップを取って消してみる。
  • sqlite> delete from ZTEXTREPLACEMENTENTRY;
  • sqlite> select * from ZTEXTREPLACEMENTENTRY;
    • 消えてるので record は無い
System Preferences > Keyboard > Text を開くと見事に消えている。
ので NSUserDictionaryReplacementItems が復活する事も無さそう。
ということで defaults で NSUserDictionaryReplacementItems を消す。
  • $ defaults delete -g NSUserDictionaryReplacementItems
これにて一段落。これらを調べた結果が最初に書いた例の2行です。



余談: WebKit の shallow clone とか

ソース読むかー、ということで WebKit を落とそうとするも時間がかかりすぎる。
  • $ git clone --depth 1 git://git.webkit.org/WebKit.git WebKit
何かないかと git grep -i replacementした結果
  • NSUserDictionaryReplacementItems
  • ContextMenuItemTagTextReplacement
  • WebMenuItemTagTextReplacement
  • kWKContextMenuItemTagTextReplacement
等があって更に混乱した。それと対応してなのか
  • ContextMenuItemTagSmartCopyPaste
  • WebMenuItemTagSmartCopyPaste
  • kWKContextMenuItemTagSmartCopyPaste
等もあり迷宮じみてる感じ。ちなみに depth 1 でも 4.5GB というトンデモサイズです。


参考

2019/11/10

zle を使って特定の条件下のコマンドを実行する際、自動で丸括弧でくくる

前回の記事では peep コマンドを使ってプロセスの終了時に通知を行ないました。
また、peep-mac-tmux というコマンドを作って pid の指定を省略しました。

ですが、 peep-mac-tmux を使う際、上手く動いてくれないパターンがいくつか出てきました。
具体的には以下のようなパターンです。

  • '&&' で繋がれたコマンド
    • peep するのは実行中のコマンドなので、途中のコマンドが終了すると通知してしまう
  • `xargs -L1` のように何度も子プロセスを生成するコマンド
    • 1つの子プロセスが終わった時に通知してしまう

そこで、zsh の機能である zle を使い、これらのパターンの時に括弧で括って実行するようにしました。
丸括弧で括ってあると subshell 内部でコマンドが実行されます。
なので、peep は subshell の pid を peep する事で適切に動作させる狙いです。


環境

  • OS: macOS Mojave 10.14.6
  • Homebrew: 2.1.16-38-ge2c76cc
  • Homebrew/homebrew-core: (git revision 0f36; last commit 2019-11-09)
  • zsh: 5.7.1 (x86_64-apple-darwin18.2.0)


zle とは

zsh command line editor という機能で、man zshzle すると詳細が見られます。

今回の場合、'&&' が含まれる or '|' が含まれる、という時に括弧を追加することにします。
そうして作成したのが以下の call-subshell です。


安直に、egrep で特定の pattern がある時、 BUFFER という vairable を編集する事で追加します。
これで peep-mac-tmux の指定もやりやすくなりました。


無限に増える括弧

さて、peep-mac-tmux しやすくなりました、万歳、とはいかないようです。
この定義ではパターンが含まれるコマンドに、() を追加するので、後のコマンドにもパターンが含まれる。
なので、履歴からコマンドを呼び出すと括弧が増え続けます。これは困る。

そこで括弧が重複しないようにしたのが以下の call-subshell です。


一応、前後に空白があった場合にも対応しています。
これで良し。


まとめ

zle を使うとコマンドを編集できて便利、というお話でした。

ちなみにオチとしては、
  • peep が上手くいくメリット < () がある事で誤爆したりするデメリット
と感じたので、作成して2ヶ月くらいで消してしまいました


参考

2019/11/02

peep を使って、プロセス終了時に Notification Center へ音付きで通知をする

peep というコマンドがあります。pid を指定することで、そのプロセスが終了した際に通知等が行なえます。
この記事は peep コマンドを macOS 上で使ったり、自前 function を作ったりしたログです。


環境

  • OS: macOS Mojave 10.14.6
  • Homebrew: 2.1.15-63-g090259b
  • Homebrew/homebrew-core (git revision 51ba; last commit 2019-10-25)
  • peep: 0.1.2 (rev: f770419/go1.11.4)
  • terminal-notifier: 2.0.0
  • tmux: 2.9a(border-ascii)


peep の install

Homebrew を使ってインストールしてみます。作成者の Songmu さんの記事 の通り
  • $ brew install Songmu/tap/peep
で install できます。


peep-mac: peep + terminal-notifier

peep を install すると peep-notify というコマンドも一緒に install されます。
peep-notify コマンドは Slack に通知したり、macOS の notification center に通知したりできます。

ただ、notification center への通知は音が鳴らずにメッセージだけ表示されます。
軽く読んでみたところ、peep-notify は内部で gosx-notifier を使っていてTitle と Messge のみ設定されています。

peep 自体は pid を監視するコマンドなので、通知に必ずしも peep-notify を使う必要はありません。
そこで、 macOS で音付きで通知できるものは無いかと探す事にしました。
いくつか試したのですが、 terminal-notifier が良さそうです。

terminal-notifier は homebrew に取り込まれているので
  • $ brew install terminal-notifier
で Install できます。

peep + terminal-notifier を使って peep-mac function を作ってみました。 zsh で動きます。
  • $ peep-mac <PID>
とすると、その pid のコマンド名を表示。
その後、プロセス終了時に terminal-notifier で通知が生成されて "Glass" が鳴ります。便利。


peep-mac-tmux: peep + terminal-notifier + tmux

さて、peep-mac を作ったことで、長いプロセスの実行時、音が鳴るまで別の事ができるようになりました。
しかし、 peep-mac を使っていて思ったのです。「pid 調べるのが面倒」と。

そこで作成したのが peep-mac-tmux function です。
tmux 環境下 + 使い方次第では pid の指定をせずに peep-mac が動きます。

具体的には
  • 長いプロセスが実行中の window に pane を追加。
  • 追加した pane 上で peep-mac-tmux を実行。
すると良いです。ここまで来ると完全に自分専用感もありますね。

peep-mac-tmux の実装に関しては
  • pane は 2 つであること
    • 長い process を実行している pane と
    • それをこれから監視しようとする pane
  • active な pane を tmux list-panes から特定する
  • そこで実行されている zsh の pid を取得
  • ps -o <ZSH_PID> で zsh が parent になっている process 一覧を取得
  • pid を sort -r して、一番上のものを peep-mac に投げる
みたいな感じです。大体良い感じに peep してくれます。

ただ、sort -r で監視対象の pid 取得をするので、pidが 一巡してる時には、上手く指定できない事も。
そういう事態はあまり発生しないので、現状はこの実装で運用してます。何か良い解決策無いかな。

と、いうことで、『実行時間長いから終わったら呼んで』みたいな事ができるので便利、みたいなお話でした。


参考

2019/10/20

DefaultKeyBinding.dict を編集して ^; を入力しても beep が鳴らないようにする

私が作業する時は Terminal.app + tmux + neovim の時が多いです。
beep 音はあまり鳴って欲しくないので neovim と Terminal の beep setting は全て off 。
それでも稀に beep 音が鳴ってしまう。しかし、稀すぎて再現できず。
が、最近再現できたので、それに対処したログを残しておきます。


環境

  • OS: macOS Mojave 10.14.6


beep が鳴る原因

『^;(control + ';')』を入力した際に beep が鳴ることを見付けました。
Terminal.app に限らず Safari といった他の Application でも鳴るので、macOS 側の設定のようです。


対応: DefaultKeybinding.dict

OSX 時代から DefaultKeybinding.dict という物があって、それで keymap を設定できるようです。
参考のリンクで一番古いのは2010年とか。そのくらい前から存在しているらしい。
最終的には ~/Library/KeyBindings/DefaultKeyBinding.dict に

だけ記述。
一度 Application を落として ^; を入力しても何も鳴らない。よし。


寄り道

  • 'noop:' を設定してはダメなのか
    • 設定してみたこともあります。が、どうも『noop: だから beep が鳴る』みたいです。
    • DefaultKeyBinding.dict 自体始めて触るので、まず map ができているか怪しかった。
    • 一度「特定の文字を insert する」ように map して、DefaultKeyBinding.dict が有効な事を確認。
    • それから「空の文字列を insert する」ことで beep を抑えている状態です。
  • 他の組み合せでは beep は鳴らないのか
    • 'noop:' の物は基本鳴ります。
    • なので control + 記号 とかは beep 祭りです。
    • 全組み合せを設定しても良いのですが、特に鳴りまくる物を見付けたら設定していこうかと。
    • Keyboard 側の Setting でそもそも beep が鳴らないようにするのがベストな気がします。
      • が、Input Method "ASCII" には 設定項目が存在せず、 AquaSKK にも無い。
    • ので keymap でアドホックに回避してる状態です。
  • macOS 側の KeyBinding と衝突した場合はどうなるのか
    • macOS 側の設定が優先されました。
  • system-wide の key binding とか参考にならなかったのか
    • /System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict ですね。
    • Property List Editor で開けると記述されているが、そんな Application は存在せず。
    • .plist を開ける XCode で開こうと試す。
    • 追加コンポーネントをダウンロードし始めたので、開けるかも、と期待。
    • で、ダウンロードしても開けず。えー。
  • 最終的に私自身の dot_files に入れることにしました。
    • .config/nvim/init.vim といったファイルは symlink で設定を配置しています。
    • が、DefaultKeyBinding.dict は symlink を follow してくれない。
    • ので cp することで対応しています。


参考

2019/10/12

.dockerignore を記述して Docker の image build を高速化する

docker image の build が作業をする毎に重くなる時があります。
今回のケースはカレントディレクトリのサイズが作業ごとに大きくなっていく場合。
その場合は .dockerignore を記述することで解決できます。


環境

  • OS: macOS Mojave 10.14.6
  • Docker: version 19.03.2, build 6a30dfc


具体例

例えば、以下のように image の build を実行したとします。
  • $ docker build -t hoge .
その際、`Sending build context to Docker daemon ...` と長く表示されることがあります。

Docker は image の build 時、指定された directory (今回は ".") のファイルを serialize して daemon に送ります。
このコマンドだと . のサイズが大きいと送信に時間がかかってしまいます。

確かこの時の curerent directory のサイズは2GB程度で、ビルド時間は 100 秒ほどでした。


.dockerignore を記述する

.gitignore のように .dockerignore を directory に配置します。
そして build に関係無いファイルを .dockerignore に記述すると、daemon に送る context から外すことが可能です。
例えば .git など、 docker image に含めることは無さそうなファイルやディレクトリを記述します。
また、git clean などで不要なファイルを消してしまうのも選択肢に入ります。

私の例では.dokerignore を記述した結果 context のサイズが 100MB 以下になり、ビルド時間も20秒以下になりました。
めでたしめでたし。



参考

2019/10/06

q を使って CSV ファイルに SQL を発行する

"q" という、CSV や TSV に SQL をに発行できるコマンドがあります。
便利なのですが、名前がググりづらいことこの上無い感じですね。


環境

  • OS: macOS Mojave 10.14.6
  • Homebrew: 2.1.12-8-gfd9a09e
    • homebrew-core: (git revision 5b99; last commit 2019-10-05)
  • q: 1.7.4


インストール方法

  • $ brew install q
でインストールできます。


実行例

例えば、以下のような "servant.csv" があったとして


以下のように SQL が発行できます。
  • select
    • $ q -d, -H 'select * from servant.csv ;'
      • 1,Altria Pendragon,saver,5
      • 2,Altria Pendragon (alter),saver,4
      • 3,Altria Pendragon,archer,5
      • 4,Altria Pendragon,lancer,5
      • 5,Altria Pendragon (alter),lancer,4
  • count
    • $ q -d, -H 'select count(*) from servant.csv ;'
      • 5
  • limit
    • $ q -d, -H 'select * from servant.csv limit 2;'
      •  1,Altria Pendragon,saver,5
      •  2,Altria Pendragon (alter),saver,4
  • distinct
    • $ q -d, -H 'select distinct(name) from servant.csv ;'
      •  Altria Pendragon
      •  Altria Pendragon (alter)
  • where
    •  $ q -d, -H 'select id,name,class from servant.csv where rarity = 5;'
      •  1,Altria Pendragon,saver
      •  3,Altria Pendragon,archer
      •  4,Altria Pendragon,lancer
  • order 
    • $ q -d, -H 'select * from servant.csv order by rarity;'
      •  2,Altria Pendragon (alter),saver,4
      •  5,Altria Pendragon (alter),lancer,4
      •  1,Altria Pendragon,saver,5
      •  3,Altria Pendragon,archer,5
      •  4,Altria Pendragon,lancer,5
  • distinct + count
    •  $ q -d, -H 'select count(distinct(name)) from servant.csv ;'
      •  2
なお、付けているオプションは
  • -d (--delimiter) 今回は csv なので  ','  が delimiter です。
  • -H (--skip-header) 今回は一行目に header があるので、それは値としてみなしません。
    • と、いうことは header が無い場合も想定していると思われます(やったこと無し)。
です。--help は貴重な情報源。


まとめ

と、いう感じで、"q" を使うと CSV を色々いじったりできて便利です。
ちなみに、 Office で開くと重かったり止まったりするサイズの csv でも捌いてくれます。つよい。


参考

2019/09/21

git clean を使って untracked なファイルを削除する

Mercurial には hg purge というコマンドがあって、 hg で control していないファイルを一括削除できます。
具体的には add してないファイルとか、.c から作った .o とか、間違って作った Rails の migration とか。
それを Git でもできないかなー、と調べたメモ。


環境

  • OS: macOS Mojave 10.14.6
  • Git: 2.23.0


git clean

hg purge のようなコマンドは Git にも default でも存在していて、git clean だそうです。

untracked なファイルを消す際は
  • $ git clean -fd
とかすると add してないファイルが消えます。

あとは、すぐに消すのではなく、消す対象が何かを教えてくれる -n (--dry-run) option が便利です。
  • $ git clean -fdn
で削除対象一覧を出してくれます。ちなみに
  • git clean -f -d -n
と書いても良いみたいです。

他には 
  • -X option: .gitignore で指定されたファイルのみを消す
    • .o とかが消えてくれる。
    • あと untracked なファイルは消えない
    • 新規にファイルを作った上で rebuild したい時に便利だよ、とのこと
  • -x option: .gitignore で指定されたファイルも削除対象 + untracked のファイルも削除対象
    • かなり危険なので事前に dry-run を付けた方が良いです
    • git clean -fdx とかすると clone 直後くらい綺麗な状態になります
とかですかね。
さらに詳細を知りたい場合は man git-clean を読んで頂ければ。


参考

2019/09/16

Terminal.app を使って mac を sleep させる

Terminal から mac を sleep させる方法無いかなー、と思ったのでそのメモ。


経緯

私は普段 MacBookPro + Display + Keyboard で作業をしています。
この状態からそのまま MBP を閉じると clamshell mode になってしまいます。
なので MBP を sleep -> MBP を閉める という流れで全体を sleep させています。
MBP を sleep させるには Shift + Control + 電源ボタン の shortcut を使うことが多いです。

しかし、たまに MBP を sleep させずに閉じてしまう時があります。
外付け keyboard には電源ボタンが無い。ので  sleep させられない。
そのせいで一旦閉じた MBP を再度開いて sleep させて閉じる、とかやっていたのですがちょっと面倒。

ということで、外付け Keyboard だけで clamshell mode の MBP を sleep させる方法た無いかな、と思って調べました。


環境

  • OS: macOS mojave 10.14.6 Version (18G95)


コマンド

  • $ pmset sleepnow
sleep させることができます。思ったより楽だった。