またあんたかい...つか潰すけどね,[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

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

MP3 fan
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.

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

細かい話ははしょって*2実際、上の方法ですと HIDKeyboardModifierMappingDstHIDKeyboardModifierMappingSrc のキーの値の型 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'でも “タグ使って書くかどうか” の摘み分けはこういった所にあるんだ、と改めて知った次第です。