またあんたかい．．．つか潰すけどね，[caps lock]

役立たずの [caps lock] キーを control キーに変更する shellscript のお話．;

keyboard_vid=$(ioreg -n 'Apple Internal Keyboard' -r | grep -E 'idVendor' | awk '{ print $4 }')
keyboard_pid=$(ioreg -n 'Apple Internal Keyboard' -r | grep -E 'idProduct' | awk '{ print $4 }')
keyboardid="${keyboard_vid}-${keyboard_pid}-0"

# CapsLock(30064771129) -> Control(30064771296)

defaults -currentHost write -g com.apple.keyboard.modifiermapping.${keyboardid} -array-add '
<dict>
  <key>HIDKeyboardModifierMappingDst</key>
  <integer>30064771296</integer>
  <key>HIDKeyboardModifierMappingSrc</key>
  <integer>30064771129</integer>
</dict>
'

これで [caps lock] キーは control キーとして振る舞うようになりました．

思うに，設定の反映は killall cfprefsd とかは暖簾に腕押し．再起動必要みたい*1．

しかし同じバージョン内で，こんな部分にまでも手を入れてくるもんなんですね．何だかな．．．

Caps Lock / andrewmalone

あ、あと知ってました？
上にあるように ‘’ 内で改行やインデント入れて記述できるんですね。エスケープ \ とか不要みたい。うん見通し良くて実に気持ちいい。

つか

このネタ、これで何回目だ(笑。そして今回も、またもや os の再クリーンインストール切っ掛けのもの．

macOS の設定についても、いつもの shellscript で勝手に流してもらうようにしているのですが，どうやら [caps lock] 潰して [control] にする設定が効いてなかったよう。
それに気付かず作業したら vim が誤爆した，というのがキッカケ．(舌打

修飾キーのコードが問題でした

今回は keyboard id ではなく，各修飾キーに割り当てられているコードの問題．

これらがヒッソリと変わっていたことにより，設定が反映されなくなったという話らしい．

確かに以前は，caps lock は “0"，control は "2” だった．

今はこんな感じになっている模様．;

key	code
[caps lock]	`30064771129`
[control]	`30064771296`
[option]	`30064771298`
[command]	`30064771299`
[esc]	`30064771113`

書き方を知った．でも．

本当はこんな書き方をしたかった．．．;

defaults -currentHost write -g com.apple.keyboard.modifiermapping.${keyboardid} '(
  {HIDKeyboardModifierMappingDst = 30064771296; HIDKeyboardModifierMappingSrc = 30064771129;})'

via. [plist - How to define an array with a single `defaults` command? - Ask Different][20]

エレガント．

こゆの大好き．

なのですが、これではどうしても上手くいかないようでして、泣く泣く冒頭記載のコードにしました。結構残念。

何となく気になったので軽く探ってみたところ，思うに値の “型” が原因じゃないかな、と踏んでますがいかがなもんでしょ。

man defaults にこんな記載があったりします。;

If no type flag is provided, defaults will assume the value is a string. For best results,
use one of the type flags, listed below.
via. defaults(1) Mac OS X Manual Page

値の型 value type を指定しないと、それは全て “String” 文字列として扱うよ、とのこと。

細かい話ははしょって*2実際、上の方法ですと HIDKeyboardModifierMappingDst、HIDKeyboardModifierMappingSrc のキーの値の型 type は、文字列 String 型になっています。

そして冒頭の方法ですと、それらキーの値は Number 数値型で設定されています。

これが plist の内容を変えても、それが実際に反映される/されないの違いになっているようなのです。

この値の型と言うのは、思いのほか気にすべき要素なのだな、と知らされた次第。

`defaults` でタグで直接書く理由が見えた

そして、defaults でタグで記載することの意味はじめ、その使い分けの判断基準とかと言うものが、実をいうとよく分かっていなくて誤魔化して(笑いたのですが、今回の作業でクリアになりました。

今回のように構造上、より上位(?)の配列や辞書のスタイルだけでなく、内包するキーの値の型も設定しなくてならないような場合、これが出来る方法として、直接タグを記載するこの方法を選択する、と言うことなのでしょう。

うん、これはスッキリした。

そのほか，今回参考にさせていただいたサイト．
» macos - Updating modifier key mappings through defaults command tool - Ask Different
» keyboard/setup.sh · GitHub

ありがとうございました．

はいおしまい．

*1:
これが実にめんどくさいっっ．
何か方法ないもんですかね．

*2:
この書き方、オプションが指定されていないではないですか。普段の感覚ならば ‘-array'が指定されているものだと思っていたのですが、ない。実はこれ気になっていまして．．．
じゃこれは ’-array'が無いから、先の man page にあるよう、String 型でドサッと ‘<’({HIDKeyboardModifierMappingDst = 30064771296; …‘'と設定されてしまうかと言うと、そうでもなく、"配列 Array" と “辞書 Dictionary” の型としてきちんと登録できているので、まんざらでもないのですよ。
要は配列や辞書の中にあるキーの値の型の問題で、そこまで細かい指定ができるようにしなきゃならない、と言うこと。
そして本文にも書きましたが、同じ 'defaults'でも “タグ使って書くかどうか” の摘み分けはこういった所にあるんだ、と改めて知った次第です。

つか

修飾キーのコードが問題でした

書き方を知った．でも．

defaults でタグで直接書く理由が見えた

`defaults` でタグで直接書く理由が見えた