投稿日:
私は30年ほどWindowsをメインで使っていて、LinuxではXfceを使っており、モバイルはAndroidを利用しているが、急遽仕事でmacを使わざるを得ない事態になり、非常に不便だったので、その不便さと、多少でも緩和できる方法を書いていく。
使用したマシンはM4 Macbook Proで、OSはSequoia 15.2で、比較対象はWindows 11だ。
- macを使っていて不便に感じたこと
- ウィンドウの切り替えが困難
- マルチディスプレイ環境でウィンドウをモニタの境界線上に亘って表示できない
- ウィンドウの整列ができない
- タスクバーがない
- アプリケーションメニューがウィンドウ上に存在しない
- 時計が画面右上にある
- キーボードの互換性がない
- ログイン時にキーボードレイアウトがランダムに変わる
- ログイン時に本体と外部のキーボードの配列が恐らく異なる
- ログイン画面のパスワードマスクが外せない
- ログイン画面でキーボードレイアウトの変更メニューが通知バナーに隠される
- ログイン時にゆっくりキーを打たないとパスワード入力ができないことがある
- 通知バナーが邪魔
- スクリーンショットを自動でクリップボードに飛ばしてくれない
- スタートメニューがない
- IMEの挙動が難しい
- キャレットの移動が遅い
- 8000x8000くらいのJPEGをSlack上で拡大してドラッグするとすごいガタつく
- ウィンドウの最小化、拡大縮小、閉じるボタンが非常に小さく、Windowsの逆にある
- 都度都度、管理者権限を要求される
- Finderで隠しファイルを見るのが手間
- フォルダを開いた時のアイコンの並びがぐちゃぐちゃ
- OSを落とすのがめんどくさい
- Homebrewはmacの標準パッケージマネージャではない
- きっちりしてそうな様相に反して、アプリケーションが全く入っていない
- ACアダプタの整流器とコンセントプラグが合体している
- macの操作感を少しでもWindowsに寄せるTips
- あとがき
macを使っていて不便に感じたこと
ウィンドウの切り替えが困難
Windowsであれば、Alt+TabやWin+Tab、タスクバーからマウスで切り替えなど、ウィンドウの切り替えは造作もないが、macではこれが非常に大変だった。
まずAlt+TabやWin+Tabに相当する機能はOS標準では存在せず、AltTabといったサードパーティソフトが必要だ。
タスクバーからマウスで切り替える操作についてはDockから似たような操作ができるが、同じアプリケーションのウィンドウが二つある場合、右クリックしてメニューを出し、選択する必要がある上、サムネイルが出ないため、どれが何なのかが解りづらい。
またDockが画面の縦幅を占有するので邪魔なので隠してしまうと、Dockを再表示させるのも時間がかかり、この操作には非常に実用性がない。
macを使っている人にどうしているか聞いてみたところ、ウィンドウの数だけ仮想デスクトップを作って、Magic Trackpadでスワイプして切り替えているとのことだった。それって仮想デスクトップ20個くらいあったらしんどくない…?
要するに複数のウィンドウを切り替えて並行で操作しながら作業するという運用には向いていないようだった。
余談だがWindows 11のAlt+Tab操作はウィンドウが切り替えられないことがしばしばあり、私はマウスで切り替えることが多いのだが、macの隠れるDockを使ったウィンドウ切り替えはあまりにも非効率的で、到底承服できなかった。きっと4Kモニタのように画面に余裕のある状態での利用が想定されているのだろう。
マルチディスプレイ環境でウィンドウをモニタの境界線上に亘って表示できない
Windowsであれば画像のように画面の境界を越えてウィンドウを表示することは標準で可能だが、macで同じことをするとどちらか片方にしか表示されず、もう片方のモニタからはウィンドウが消えてしまう。
恐らくmacではモニタの境界を越えた状態でウィンドウを表示することを想定していないか、そこで切るのが正しいという考えがあるのだろう。
なお、Xfceでもモニタの境界に亘って表示させることは標準で可能だ。
私は作業を一時中断して退避させるなどの目的でモニタの境界上にウィンドウを配置することがしばしばあり、この特性には不便を感じている。
ウィンドウの整列ができない
Windowsであれば画面端にウィンドウを持っていくと左右二分割や、画面四分割などウィンドウを整列し、ウィンドウの境界をドラッグするとリサイズもきれいにできるが、macにその機能はなさそうだった。
ウィンドウの切り替えが困難なのと相成って、基本的に1つの画面上に複数のウィンドウを並べるという運用は想定されていない気がした。
タスクバーがない
macにはタスクバーがなく、Dockのみがある。Windowsのタスクバーとの違いは、起動していないアプリケーションも並んでいることだ。
Windowsのタスクバーはピン止めをすべて外すことで、起動しているアプリケーションだけにできるため、作業に集中できるがmacのDockは余計なアイコンが多くあり目が余計に滑って不便に感じた。別にmacのDockも余計なものは消せるのだが、スタートメニューが存在しないし、そもそもDockはタスクバーではないし、Finderやドロワー、ごみ箱をここから消すのは、アクセス手段が失われる懸念もあり、やれていなかった。
アプリケーションメニューがウィンドウ上に存在しない
macではアプリケーションのメニューは画面最上部のバーに固定で出ている。この関係でマウスでメニューを操作しようとするとウィンドウの位置やサイズによってはカーソルの移動距離が長く手間であるし、直感的でないと感じた。
また一つのモニタ上にウィンドウを複数出している場合に、別のウィンドウのアプリケーションメニューを操作する場合、一度そのウィンドウをアクティブにしてから画面最上部のバーにアクセスしないといけないのもWindowsと比べた時に1ステップ多く手間がかかり、面倒だ。
私はこれを作業効率の観点から好ましく思っておらず、Linuxのデスクトップ環境でもGNOMEを避けている。
恐らくmacでは一画面に一ウィンドウを最大化状態で保持して操作するのが前提の哲学としてあるのかもしれない。過去にmacは1画面1ウインドウで時代遅れだとか、そういった意見をネットで見ることが過去にあったので、そう感じた。
時計が画面右上にある
首が疲れるので右下にあってほしい。macユーザーは首を持ち上げるのが、苦ではないのかもしれない。
キーボードの互換性がない
CtrlやAltがmacに存在しないことは知っていたが、他にも違いがあった。
例えばHomeやEndについてはアプリケーションによって振る舞いが異なっていた。Windowsであれば標準ではスクロールバーを一番上や下に持っていったりCtrlキーとのコンビネーションでファイルの先頭や一番下に移動させることが一般的だが、macでは恐らくアプリケーションごとに異なる振る舞いを示し、統一した振る舞いはなさそうだ。
何より先頭や末尾に移動する機能がないのは面倒だった。
これはKarabiner-Elementsを導入することで多少はマシになるが、多少マシになる程度だ。何故ならKarabiner-Elementsはアプリケーション単位にキーバインドを設定しないとまともに機能しないからだ。利用するすべてのアプリケーションのキーバインドを設定するというのは気の遠くなるような作業で、事実上役に立たないといっても過言ではないだろう。
他にもVSCodeのターミナルでCtrl+CやCtrl+Zが効かないなど、枚挙に暇がなく、遭遇するたびに一々調べるのも大変なので、今のところはターミナルを殺すことで対処している。
ログイン時にキーボードレイアウトがランダムに変わる
スリープから復帰したときにキーボードレイアウトがUSになっていたりABCになっていたりQWERTZになっていたりした。
なぜ不規則に変わるのかは一切把握できていないが、このせいでログイン時にパスワードの入力を誤ることが多く、非常にストレスになっている。
ログイン時に本体と外部のキーボードの配列が恐らく異なる
ログイン時にどちらか片方のキーボードでしかパスワードが正しく入力できないことがあるため、恐らく個別にキーレイアウトが設定されている。
前項のランダム変化と合わさり、一体何の意図があってこうしているのかさっぱり理解できない。ユーザーが自分の意思で個別に変更しているのならわかるが、一般的に複数のキーボードを繋ぎ、すべてのレイアウトをバラバラにしたいケースは、そう多くないと思う。
ログイン画面のパスワードマスクが外せない
前の項に付随する内容だが、パスワードマスクが外せないので変なレイアウトになっていた時にキーボードと入力内容を対比して、それに応じて打鍵するキーを修正するといった操作ができない。
ログイン画面でキーボードレイアウトの変更メニューが通知バナーに隠される
ログイン画面の右上にキーボードレイアウトの変更メニューがあるが、通知がたまっているとこれが隠れて見えなくなる。こうなると半分エスパーで操作する必要があり、かなり辛い。このUI設計した人の思想を私には理解できそうにない。
ログイン時にゆっくりキーを打たないとパスワード入力ができないことがある
ログイン時にパスワードを入力する画面で、キーボードを早く打ちすぎると入力されないことがある。体感で500ms以上開けて入力すると安定したが、何故かは不明。
参考までにスローキーや固定キーの設定が影響している可能性があるという情報を得て確認してみたものの、これらの設定は無効だった。
再現条件も不明で、起きる時と起きない時があるため、面倒な事象だ。
通知バナーが邪魔
macでは画面上に無限に通知バナーが溜まり、これを削除するには一つ一つ丁寧に小さなバツボタンを押していくしかない。Slackの通知などで画面からはみ出てバナーがあると、ひたすら押し続ける必要がある。まるで何かの修行をしている気分だ。
Windowsの場合は画面を一列丸ごと通知バナーが埋めることはないし、タスクバーの時計をクリックしたらバナーはすべて消え、通知一覧に移動する。そして通知一覧から読み直すこともできる。
またmacでは通知は標準で消えないようにみえるが、Windowsでは通知は時間経過で消えるのが一般的で、常に画面を占有することはない。
私は仕事をしている中でmacを使っている人が通知を見逃すことが多いのをしばしば聞くのだが、邪魔くさくて消してたら見過ごしたとか、そういうことが多いのではないかと考えている。
Windowsを使っていて通知を見逃すというのは個人的に通知バナーをミスクリックして消したくらいしか経験がないが、macを使っていると通知バナーが画面の外に流れて消えたり、画面を占有するのもあり、見逃すことが増えたと感じる。
参考までにClaude Opus 4.6に聞いて見たところ、macOSの通知には「バナー」スタイルと「アラート」スタイルがあり、バナーに設定すれば数秒で自動的に消えること、また通知センターではグループ単位での一括削除も可能であることだったが、そこを気にしないといけない時点で個人的にはどうかと思った。少なくともWindowsでは気にする必要のない部分だ。
スクリーンショットを自動でクリップボードに飛ばしてくれない
macではスクリーンショットを撮っても自動でクリップボードに飛ばしてくれない。
スクリーンショットを撮ると毎回画面右下に小さなサムネイル画像が出るので、これをクリックして出てくるメニューでクリップボードに飛ばすか、ファイルに落とすかを選択しないといけない。すごく面倒くさい。
また数秒すると消えてしまうため、何か突発的な用事が発生するなどで、クリックするのが遅れると撮り直しになるのも面倒だ。
UbuntuであればGNOMEでもクリップボードに飛ばされたと思うし、Xfceでも標準ではクリックボードに行くので、macの挙動はどうしても不便に感じてしまう。
スタートメニューがない
macにはスタートメニューがなく、GNOMEやAndroidなどにもあるアプリドロワーがあるのみである。全画面占有する割に巨大なアイコンが並び、情報量が少なく、アプリケーションを探すのが極めて面倒くさい。
またピン止めも恐らくできないので、使い勝手が悪い。
IMEの挙動が難しい
標準のIMEが非常に使えないのでGoogle IMEを入れて、標準を殺してみるものの、時折標準のIMEに復帰している気配がしており、難しさを感じることがある。
あとIMEの切り替えをKarabiner-Elementsを使って全角半角キーで実現しているのだが、この動作にも違和感があり、困難を覚えがちだ。
キャレットの移動が遅い
エディタやブラウザのURLバー、Slackの入力欄など、どこであってもキャレットの移動速度が驚くほど遅い。非常にガタガタしながらキャレットが移動するのを眺めていると何とも言えない気持ちになる。
かつてメモリがしょぼいWindows XPで重いワードを開いた時はこんな感じだったかもしれないが、今となってはなかなかない光景だ。ましてや使っているのがM4 Mac Proであるから、余計にそう思う。
8000x8000くらいのJPEGをSlack上で拡大してドラッグするとすごいガタつく
M4 Mac ProはApple M4 Proを搭載しており、非常にスペックが高いはずである。しかし、高々8000x8000くらいのJPEGをSlack上で拡大してドラッグするだけで非常にガタガタとカクついた。
参考までにDell Latitude 5430でCPUがIntel Core i7-1255U、メモリが32GBのWindows 11環境では、これは起きなかった。
先ほどのキャレットの件といい、macはグラフィック処理が苦手なのかもしれない。
ウィンドウの最小化、拡大縮小、閉じるボタンが非常に小さく、Windowsの逆にある
押させる気がないんじゃないかと思うほど小さく、大変使いづらかった。またWindowsと比べた時、左右逆にあるのも不便に感じた。
記憶があやふやだが、GNOMEではWindowsと同じく右側にあり、サイズも押しやすかった気はする。
都度都度、管理者権限を要求される
例えばAltTabなどのアップデートがあった時、毎回管理者権限を要求されるのがうっとおしいし、Rancher Desktopも毎回管理者権限を要求してくるのでうっとおしい。
ウィンドウの管理がしづらいのと相成って、これらの権限要求ダイアログが、アプリケーションウィンドウとセットでOS起動時に重なって出てくると、とても面倒くさいと感じる。
Finderで隠しファイルを見るのが手間
Command+Shift+.の同時押しで隠しファイルが出せるが、手間である。
以下のコマンドを流せば恒久的に表示できるが、GUIで設定できないのは不親切に思う。
defaults write com.apple.finder AppleShowAllFiles -bool true
killall Finder
フォルダを開いた時のアイコンの並びがぐちゃぐちゃ
Finderでフォルダにファイルなどをドラッグしたときに、ドラッグした位置に保存されるため、非常にぐちゃぐちゃになる。
常に均等整列することも可能らしいが、少なくとも標準ではそうなっていない。
OSを落とすのがめんどくさい
OSを落とそうとしたときにアプリケーションが生きていると、一々都度都度落とすように言われるのが非常に面倒くさい。
Windowsなら強制終了ボタン的なのを一度押せば全スルー出来るし、そもそも基本出ない印象だが、macではアプリケーション毎にこれが出てきて、ボタンを押し落とし、また出てきて落としとか、面倒なので終了メニューを何度も出して連打して落としたりしている。面倒くさい。
Homebrewはmacの標準パッケージマネージャではない
mac関連の記事でアプリケーションの導入に出てくるHomebrew(brew)だが、なんと標準ではなく、サードパーティである。
これまでAltTabやKarabiner-Elementsといったサードパーティが出てきたが、またサードパーティだ。Microsoftがサードパーティーソフトウェアにあった便利機能をOSに取り入れているのと比べるとAppleの動きはまるで対照的だと感じた。
きっちりしてそうな様相に反して、アプリケーションが全く入っていない
macは標準でzshをシェルとしており、ターミナルもついていて、お金を払って買うものだし、きっと充実した環境があるだろうと思えば、全くなかった。
びっくりするほど何も入っていないので、入れてやる必要があった。
確か一番最初にこんな感じで入れたと思うが、他にもPerlとか色々入れたほうがより便利になるだろう。
brew install coreutils
brew install diffutils
brew install ed
brew install findutils
brew install gawk
brew install gnu-sed
brew install gnu-tar
brew install grep
brew install gzip
ACアダプタの整流器とコンセントプラグが合体している
これはOSとしてのmacとは関係ないことだが、macはハードウェアとソフトウェアが不可分であるところもあるので書く。
M4 Mac Proでは写真のようにコンセントプラグに大きな整流器が合体していた。
これは他のコンセントに干渉する上、自重で脱落しやすく、個人的には好ましく思っていない。写真では干渉を避けるためにコーナータップを生やして回避している。
macの操作感を少しでもWindowsに寄せるTips
Alt+Tabの実現
AltTabを入れる。
矩形スクショをWindowsのように撮れるようにする
Command+Shift+4で任意の場所に矩形を作り、スクリーンショットを撮れる。
クリップボードに送るには、スクリーンショットを撮影すると右下にサムネイルが出るので、そこをクリックして操作するのでひと手間かかる。
Win+Shift+Sで起動させるにはKarabiner-ElementsのComplex Modificationsに以下の設定を書けば実現できる。
{
"description": "Right Command + Shift + S to Command + Shift + 4 (Screenshot Tool)",
"manipulators": [
{
"from": {
"key_code": "s",
"modifiers": { "mandatory": ["left_command", "shift"] }
},
"to": [
{
"key_code": "4",
"modifiers": ["left_command", "left_shift"]
}
],
"type": "basic"
}
]
},
JISキーボードの全角/半角キーをIMEのON/OFF切り替えキーに変換
Win+Shift+Sで起動させるにはKarabiner-ElementsのComplex Modificationsに以下の設定を書く。
{
"description": "JISキーボードの全角/半角キーをIMEのON/OFF切り替えキーに変換",
"manipulators": [
{
"conditions": [
{
"input_sources": [{ "language": "en" }],
"type": "input_source_if"
}
],
"from": { "key_code": "grave_accent_and_tilde" },
"to": [{ "key_code": "japanese_kana" }],
"type": "basic"
},
{
"conditions": [
{
"input_sources": [{ "language": "ja" }],
"type": "input_source_if"
}
],
"from": { "key_code": "grave_accent_and_tilde" },
"to": [{ "key_code": "japanese_eisuu" }],
"type": "basic"
}
]
},
VSCodeでCtrl+@を押したときにターミナルが出るようにする
Karabiner-ElementsのComplex Modificationsに以下の設定を書く。
{
"description": "VS Codeが前面にあるとき、左Control+@をターミナルトグルとして機能させる",
"manipulators": [
{
"conditions": [
{
"bundle_identifiers": [
"^com\\.microsoft\\.VSCode$"
],
"type": "frontmost_application_if"
}
],
"from": {
"key_code": "open_bracket",
"modifiers": { "mandatory": ["left_command"] }
},
"to": [
{
"key_code": "j",
"modifiers": ["left_command"]
}
],
"type": "basic"
}
]
},
OCR機能
スクショ撮影→右下のサムネイルクリック→拡大画像ウィンドウを表示で、画像中の文字列をドラッグすると文字を取れるようになっている。
そこまで多用したわけではないが、精度は実用上問題なさそうに感じた。
Windowsのように画面を拡張したマルチモニタにする
システム設定→ディスプレイ
メインディスプレイを切り替え、内蔵ディスプレイはそれのミラーリングにする(OFF にはできない)
またこの時に「ディスプレイのミラーリング中または共有中に通知を許可」をONにしておくと、外部モニタで通知が見れるようになる。OFFの場合、本体モニタ側に通知が出る。
Dockを隠す
システム設定→デスクトップとDockを開き、適当に縮小して自動的に非表示になるように設定。アニメーション系の邪魔なものもOFFにしておく。
ユーザーディレクトリを開く
Finderでデスクトップを表示し、アドレスバー的な部分を右クリックすると出てくる。
面倒なのでサイドバーにD&Dしてピン留めしておくと良い。
英字の先頭を大文字にしない
システム設定→キーボードを開きテキスト入力セクションにある「入力ソース」の「編集」を開き、すべての入力ソースで「文頭を自動的に大文字にする」をOFFにする。
IMEをWindows風にする
システム設定→キーボードを開きテキスト入力セクションにある「入力ソース」の「編集」を開き、各入力ソースでWindows風のキー操作にチェックを入れる。
UIの隙間を狭める
UIにマージンがやたら多いので埋める。
システム設定→ディスプレイ→スペースを拡大をいい感じにいじる。
あとがき
同僚にも幾らか聞いたのだが、なんかみんな力業でやっているようで、あまり参考にならなかった。ひょっとするとmacにはWindowsの様な定型的なお作法がないのかもしれない。わからない。
他にもいくつかの会社でmacの操作方法について聞ける機会を得たものの、Windows利用経験がない人だと「その操作をする発想がなかった」レベルの話をされて、割と戸惑うので、恐らくmacではWindowsと思想そのものが根底から違うのだと思う。
少なくとも私はmacの思想に相容れられないほどにWindowsを使い込みすぎており、30年来の利用によりWindows操作に特化しすぎているため、macに習熟するのは無理があるなと思った。
LinuxやAndroidは違和感なく使えるが、iOS(iPhone)やmacは操作に難儀し、文字入力さえ満足にできない次元なので、恐らくAppleの哲学に対して、私の相性が根本的に良くないのだと思う。
投稿日:
私は2020年の末あたりからLet's EncryptのDNS-01 challengeをValue-Domainで達成するためのスクリプトであるvalue-domain-dns-cert-register (vddcr)の開発を行ってきていたのだが、メンテが辛くなってきたので、今回Shellscript(Bash)Perlでvalue-domain-dns-utilとして作り直した。その経緯と、開発中の学び、そして最後にどうやって作っていったかについて書いていく。
背景
一年半ほど前からTypeScriptに限界を感じてきたことや、当時の誤った単体テストへの偏執により、vddcrはメンテしたくない状態になってしまっていた。
そこで昨夏、つまり2025年の8月に式年遷宮、つまり全体的な書き直しを行ったのだが、個々の処理をする部品を作ったまではいいものの、それらを繋ぎ合わせるところで飽きてしまい、放置していた。vddcrはこの時点で事実上の放棄状態だった。
しかし、自宅サーバーの運用をしていく中で別の目的でValue-DomainのDNS APIと関わらなければならない必要が出てきたため、今回、vddcrの置き換えも兼ねて新しく作り直すことにしたのだ。
具体的には複数ドメインに対するDDNSをバルクでやりたい要求が生まれたが、Value-DomainにあるDDNS APIは一度に1ドメインしか処理できない上にレートリミットが60秒に1回と極めてキツく、複数ドメインに対して行うには余りにも遅延が大きかった。
例えば10ドメイン更新しようとすると10分もかかるわけで、これでは使い物にならないというので、DNS APIを直に叩いて一気に書き換える必要性が出てきたのだ。どうせ作るならvddcrが担っていたDNS challengeの機能も包含できる形にしたかったので、Value-DomainのDNS APIを便利に叩くためのツールキットとしてvalue-domain-dns-utilを作ることにした。
つまりvddcrの純粋な後継ツールというよりは、vddcrの役目もこなせるツールキットを開発し、vddcrと同等の機能を有するツールを実装サンプルとして同梱したわけだ。
Shellscriptにした理由
ものの数時間でPerlに直したので過去の話となった。移植性の関係でbashはイマイチだった。
ぶっちゃけそんなに大した理由はなくて、単に目の前にターミナルとテキストエディタがあってパッと組めたからという部分が大きい。実際ベースはパッと作れた。まぁ作って半年も放置していたのが…。ただまぁPerlの方が保守性は高いだろうし、移植性もあるだろうとは思うから、気が向いたら書き直すかもしれない。
ちなみに別言語に移植することの検討はvddcrでも行っていたが、最終的には候補になかったShellscript(Bash)での実装に落ち着いた。そもそもこの課題の存在を忘れていたので、検討すらしていなかったのである。
value-domain-dns-utilについて
今回作ったvalue-domain-dns-utilは、vddcrの単純な代替ではなく、Value-DomainのDNS APIを叩くのに便利なShellscriptの関数群だ。DNS challenge以外にも用が生まれたので、このような汎用的な形になっている。
DNS APIから現在のレコードを取得する関数や、取得したレコードから先頭一致のパターンマッチでレコードを取得する関数、レコードリストへの追加や置換をする関数、そして編集したレコードをDNS APIに送り戻す関数を備えており、DNSに関する一連の編集処理ができるように便利に作っている。
結果として、Value-DomainのDNS APIを叩く汎用機能があれば、それを流用してLet's EncryptのDNS-01 challengeもできるし、当然複数ドメインに対するDDNSをバルクでやることも可能になる。
学び
開発中に発見も多くあったので記していく。なんかこういうのまとめた記事かページ作りたいね。
echoでドルマーク始まりのシングルクォート文字列を作ると、その中の改行コードが展開される
例えば以下のようになる。これは一行で改行展開を書けて変数に入れられるので、インデントされているコードなどで物理的にへし折りたくないときなどに有用だし、文字列としてのコードが見えるのでわかりやすい部分もあると思う。
入力
#!/bin/bash
# ドルマーク始まりのシングルクォート文字列は改行が展開される
echo $'1:aaa\nbbb'
# つまりこれと同じ
echo "2:ccc
ddd"
# ダブルクォートの中の\nは展開されない
echo "3:eee\nfff"
# ドルマーク始まりのダブルクォートも展開されない
echo $"4:ggg\nhhh"
# 一行で改行展開を書けて変数に入れられるので便利
hoge=$(echo $'5:iii\njjj')
echo "$hoge"
出力
1:aaa
bbb
2:ccc
ddd
3:eee\nfff
4:ggg\nhhh
5:iii
jjj
変数の最後の一文字を削る
これは後方一致除去(${parameter%word})と呼ばれるものらしく、詳しくは調べていないが"hoge"に対してfugaを繋げ、"hogefuga"としたい場合に便利だ。
例えば以下のように書ける。
入力
#!/bin/bash
hoge='"hoge"'
fuga='fuga'
result="${hoge%?}$fuga"'"'
echo $result
出力
"hogefuga"
sedで改行を改行コードに置換(\n→\\n)
これは見つけた当時sedの記事にも書いているが、以下のようになる。
入力
cat <<'EOF' | sed ':a;N;$!ba;s/\n/\\n/g'
aaa
bbb
ccc
ddd
EOF
出力
aaa\nbbb\nccc\nddd
[]ではGlob展開できないが、[[]]では出来る
今のところこういった形式でGlobを書くことはないのだが、Sonnet 4.6にテストコードを書かせている中で発見したので書き留めておく。
入力
#!/bin/bash
hoge='aaabbbccc'
[ $hoge = *"bbb"* ]
result1=$?
[[ $hoge = *"bbb"* ]]
result2=$?
echo $result1
echo $result2
出力
1
0
あとがき
LLMとの作業分担
今回の開発でもLLMを活用したのでその辺り。
今回の開発では、8ada152~93d58ccのコミットを行った。最も古いコミットである8ada152ではテストコードを除き、私がフルスクラッチで書き、テストコードはClaude Code(Sonnet 4.6)に書かせた。
次の029a951では、私が書いたコードをClaude Code(Sonnet 4.6)に全体的に直してもらって私がレビュー・微修正するという開発形態をとった。それ以降のコミットはコメントなどの微修正なので、再び私が手動で書いている。
こうした分担により、設計の根底にある信条のようなものには私の色が濃く出ているが、実装上の問題点はClaude Codeによって大きく改善されている。特に029a951では、typoや単純な実装ミスの修正に加えて、bashの文字列処理に不慣れなことで生まれたエスケープシーケンスの山が整理された。jqの-rオプションの有無がまちまちだった部分も統一され、可読性がだいぶ向上したと思う。
とはいえ、Claude Codeの言うことを鵜呑みにはしていない。こちらから明示的に指示して直させた箇所もある。例えばテストコードのappend_recordやreplace_recordのアサートは元々Globで書かれていたのだが、より厳密にするために全文マッチに直させた。別にレコードの順序がどうなっていようとValue-Domain APIは気にしないどころか勝手にソートされるので実用上の意味はないのだが、こういうのは人としての拘りである。
昨今は過去の記事でもちょいちょい言及している通り、LLMを使った開発をそこそこしていて徐々に馴染めてきているので、その点も含めてよい経験になった。
抽象化した今回の設計と、過去の歪な設計を振り返って
抽象化して再利用性を高めた今回のツールキット方式と、単体テスト大正義とばかりに変な作りになってしまった前回の方式の振り返り。
過去のvddcrでは単体テストへの誤った偏執によりモジュールが具象的な単位で分割され、非常にメンテナンス性が悪く、再利用性もないものになっていたが、今回はちゃんと抽象化して、責務ごとに機能が切れたと思っている。このことによって再利用性が高く、使いやすいものが作れたと考えている。大した規模ではないとはいえ、部品を組み合わせて処理を組むには程よくいい感じだろう。
先ほどのことや、単純に機能を削ったこと、TypeScriptの複雑すぎる型管理や非同期処理から解放されたこともあり、コードもだいぶ見通しがすっきりした。ツールではなく、ツールキットという形で作ったことも奏功し、Value-DomainのDNS API周りのスクリプトは大分作りやすくなったと思う。将来的にバルクのDDNSスクリプトを書くのも楽になるはずだし、重い腰を上げて作れてよかった。
式年遷宮で起きる変遷について
式年遷宮をする以上、元の状態には戻れないという話があり、それが何故起きるのかみたいなところが分ったような、分からないような、そんな話。
しかし世の中には式年遷宮で全く違う姿になるものがある。今回作ったのはまさにそんな感じで、なんというか作者の気持ちがわかった気がする。
分かりづらい例えだが、FF14の外部ツールであるConcept Matrix(CMTool)がAnamnesisに変わったときは、全く別物になった気さえしたし、こういった式年遷宮によって元あったことは一応できるにはできるけど、複雑になったり、なんかかゆいところに手が届かなくなったり…みたいなのは他でもちょいちょいあると思っていて、今回vddcrをvalue-domain-dns-utilにしたのもまさにそうだと思う。
という背景があるのもあり、完全互換を目指したvd-dcr.shを同梱することで、この不便さを少しはなくそうとした。いやまぁ自分のためにやってるので、自分のためのことではあるのだが…。とはいえ、以前のと比べるとプラットフォーム別の互換性は落ちていると思うので、現時点だと動かない環境は増えている気がする。
あとがき2:結局Perlに変えた
動かそうとしてた環境の一つのシェルがashで、bashが使えないことに気が付いたのでSonnet 4.6に頼んでサッとPerlに変えてもらった。
関連記事
なんか気が付いたら動かなくなってた気がするので作業ログとして残しておく。
確認環境
| Env | Ver |
|---|---|
| Windows 11 Pro | 25H2 OS build 26200.8740 |
| MSYS2 | msys2-x86_64-20251213 |
| zsh | 5.8 (x86_64-pc-msys) |
| nvm-windows | 1.2.2 |
MSYS2 msys2-x86_64-20210725でも動作を確認しているため、MSYS2のバージョンはほぼ関係ないと思われる。
前提条件
- MSYS2とzshは既にあるものとする。
- Node.jsは入っていないものとする。
やり方
- nvm-windowsからインストーラーを落としてインストール
- 任意のシェルで
nvm onを実行 nvm install ltsなり適当なインストールコマンドを叩くnode -v && npm -vで両方のバージョンが出ればOK
トラブルシューティング
nodeやnpmのコマンドが見つからない
nvm onを実行していないと上手くパスが通らないのでこれを実行する必要がある。
あとがき
nvm onなんてしなくても動いていた気がしたが、久々にWindowsでnodeを叩こうとしたら動かなかったので、ついでに全部の環境を刷新するついでに書いた。
投稿日:
Windows 11の新しいメモ帳は、CVE[1]が出たり、Markdownをコピペしたら勝手にエスケープされたり、毎回新機能の設定をOFFさせられたりと、新しいメモ帳に愛想が付いてきたので古いメモ帳に戻すことにしたのでそのログ。
新しいメモ帳にはお亡くなり頂き、古いメモ帳だけにした。
やったこと
トラブルシュート
テキストファイルの新規作成ができなくなった
以下のレジストリを登録することで出すことができるようになる。
[HKEY_CLASSES_ROOT\.txt\ShellNew]
"NullFile"=""
[HKEY_CLASSES_ROOT\txtfilelegacy]
"FriendlyTypeName"="テキストファイル"
新しいメモ帳を復活させたい
Microsoft StoreにあるWindows Notepadというやつが恐らく同じものだと思われるので、これを入れるといい。
実際にこれをインストールすると「メモ帳」が復活した。
あとがき
メモ帳なんかプレーンテキストが書ければそれ以上は要らないので昔のメモ帳に戻ってこれてよかった。
UIも無駄に場所を取っていたのがすっきりした。
- CVE-2026-20841でWindows Notepad アプリのリモートでコードが実行される脆弱性 ↩








