Macでバックスラッシュでハマった話

会社で支給されていたThinkPadが，昨年原因不明の不調で起動しなくなり，代替として使えるPCが手元にMacBook Airしかなかったために，仕方なく業務でMacを使うようになった。最近古いPC入れ替えのお知らせが来て，本来ThinkPadでもMacでも選べるはずなのだが，何故かThinkPadの在庫がないと言われて，MacBook Airが業務に使うには非力だったのも事実なので，背に腹は変えられずM1のMacBook Proに入れ替えた。これでもう当分Windows環境には戻れそうにない。

私物としても古いMacBookを持って入るので，まるきり初心者ではないものの，いろいろMacでやり方がわからないことがあると，追求して調べずにWindowsマシンでやってしまったりしていたために，わからないことはわからないままになってしまっていた。しかし業務に私物のPCを使うわけには行かないので，MacBook Proでやっていく上は，なんでもMacでできないと都合が悪い。というわけで現在も試行錯誤しながらやっている訳である。

まず最初に驚いたのは知らないうちに，MacOSのターミナルのデフォルトのシェルがzshになっていたことである。Linuxでもbashしか馴染みがなかったのでzshは全く知らないが，基本的なところは互換性があるだろうから余り気にしない。ただ流石に新しいだけあっていろいろ便利な機能があるらしい(あまり良く把握していない)が，追加の便利モジュールがあるのでいくつか入れてみた。oh-my-zshが便利だとあちこちに書いてあったので入れてみたが，何がどう変わったのかはよく分かっていない。認識しているのは，デフォルトでaliasが色々設定されていたり，各種コマンドライン補完のためのファイルがパッケージされているらしいこと，gitを使うのに便利なプロンプトになるというところだろうか。ただoh-my-zshと一緒に入れたpecoというツールがとても便利である。pecoは別にzsh専用ではないのだが，zshを活用しようと思わなければ存在に気が付かなかった可能性があるのでzshのお蔭といったところになるだろう。Pecoはフィルタコマンドで，標準入力で文字列のリストを渡してやると，CUIでリストの中からいずれかを選択することを可能にする。例えば，カレント・ディレクトリのファイルのリストを渡すとpecoがファイルを一覧表示してくれてカーソルキーを使って目当てのファイルを選択してリターンキーを押すと，選ばれたファイル名がpecoの出力として得られるのである。長いファイル名をすべてキー入力するのに比べると圧倒的に楽になる。私の場合は右手しか使えない状態なので尚更便利である。フィルター機能が秀逸なのだが，その辺，気になった人は色々紹介しているサイトがあるのでググってみていただきたい。

.zshrcでpecoを起動するキーを設定しておくと，コマンドで入力中にファイル名が必要なところでpecoにファイル名のリストを食わせて起動することで操作を楽にすることができる。しかしこれを使って気づいたのだが，lsコマンドやfdコマンドなどでファイルリストを作ってpecoに食わせた場合コマンドラインに戻ってくるのはファイル名に含まれる空白や特殊文字もそのままになってしまうということである。いちばん簡単な解決法はファイル名をそれぞれダブルクォートで囲んでしまうということ。そこで.zshrcを編集して，ダブルクォートを追加するようにしてみた。ここで注意が必要なのは，ダブルクォートがシェルスクリプト中では特別扱いが必要な文字ということである。そのため普通の文字として扱うためにはバックスラッシュでエスケープする必要がある。そんなことはプログラマとしては至極当たり前のことなのでやっているのだが，実際実行してみるとなんかおかしい。ダブルクォートが表示されるべきところに円記号が表示されており，ダブルクォートそのものは表示されていない。なぜだろう。ここでひとしきり悩むわけである。これはしかし後から考えると永年Windowsの世界で生きてきた人間には気づかなくても仕方ないことだったと言えるだろう。私は暫くウンウン唸っていてふと閃いたわけである。それは，MacOSでは「バックスラッシュ」と「円記号」が別物なのではないかということ。

「バックスラッシュ」という記号はそもそもASCIIのエンコーディングでは，0x5cというコードポイントに割り当てられている。一方日本で使われる「円記号」はASCIIでは定義されていない。そりゃそうだ。で，日本のJIS(X201)では1バイトの文字エンコーディングが規定されているのだが，ここではコードポイント0x5cに「円記号」が割り当てられている。そして逆に「バックスラッシュ」は定義されていない。つまりASCIIとJISとでは「バックスラッシュ」と「円記号」が完全に交換されている事になっているのである。その結果として一般的なコンピュータの世界では，コードポイント0x5cの文字は，環境にインストールされているフォントによって「バックスラッシュ」と表示されたり「円記号」と表示されたりするが，文字データとしては同一のものとして扱われてきたのである。ところがいつのMacOSからそうなのかは知らないが，MacOSでは「バックスラッシュ」と「円記号」が同時に存在しうる状況なのである。それこそMacOSらしいと言えるのかもしれないが目に見えているものがまさにそのものなのである。確かに今やUnicodeがOSの標準のエンコーディングとして採用される時代にあって，過去の遺物のようなASCIIコードの事情を引きずり続ける必要はないのかもしれない。しかしプログラミング言語としては，Unicode(UTF-8)のソース・コードをサポートする処理系が一般的になっているとはいえいまだにASCIIエンコーディングのソース・コードも有効な場合がほとんどである。(普通の文字だけを使っていればUTF-8エンコーディングで書かれたファイルはASCIIエンコーディングとしても読めるという事情はあるが)

話を戻すと，Windowsの世界で生きてきたプログラマにとっては「バックスラッシュ」=「円記号」であり，脳内で自動的に相互変換されてしまうのである。ところが今のMacOSではそれが通用しない。エディタに「円記号」が表示されていればそれは純然たる円記号であって，決してバックスラッシュではないのである。それで私が編集した.zshrcでは，私が円記号を入力したので円記号が表示されているだけで，結果としてエスケープされなかったダブルクォートは文字列リテラルを囲む特殊記号として機能していたので表示されなかったというわけである。MacOSでバックスラッシュを入力する方法は[option]+「円記号」だそうだ。プログラミングのときにこれではあまりに面倒だろうから，「円記号」単独でバックスラッシュを入力する設定も可能だそうだ。いずれにしても何か特殊な設定をしていない限り，バックスラッシュが必要なところには目で見て正しくバックスラッシュが表示されていなければならない，ということである。