Backend 開発環境としての Windows 注意点 2022

Dec 13, 2022 · 2 min read · Windows WSL Git Docker ·

開発環境としての Windows に興味が尽きないホシイです。

WSL が使いやすくなり、Linux を target とした server application の開発環境としての Windows 活用も、すこし様子が変わってきているように感じます。
ゲーム開発などでの Windows 活用の有用性は言うまでも無いですが、かたや、特に我々のように本番環境の target を Linux としている backend engineer 向けには、Windows を使うこと自体が足かせとなることもままあることには注意が必要でしょう。
(もちろん、Windows Server を使用している場合はまったくその限りではありません。)

2022 と題したわりには古い話ばかりだったりしますが、年の瀬ということで、今回はそれらについてまとめてみたいと思います。

Windows 問題の例

CRLF 問題

Windows では標準の改行コードが CRLF (\r\n)、Linux では LF (\n) であり、そのまま使用すると一部の状況で問題となることがあります。

たとえば、shell script の shebang です。

#!/bin/sh(CRLF)

このように、一行目に書いておくことで interpreter を指定するものですが、上記のように CRLF で終わっていると shell が /bin/sh(CR) を探してしまい、そんなものはありませんよ、となってしまいます。

❯ ./test.sh 
zsh: ./test.sh: bad interpreter: /bin/sh^M: no such file or directory

これを解決するには、以下のようにします。
※ 実行形式 binary file などにも適用してしまうとこわれてしまうので対象に注意しましょう

❯ sed -i 's/\r$//' test.sh

参考 : https://www.cyberciti.biz/faq/how-to-remove-carriage-return-in-linux-or-unix/

filename 大文字小文字問題

Windows では、filename で大文字小文字の区別が (一見) されません。ただし、実際は大文字小文字の別がちゃんと記録されているため、他のシステムから見ると奇妙に見えてしまうことがあるようです。
git commit などするときには気をつけましょう。

よさそうな説明 : https://stackoverflow.com/questions/47831629/git-on-windows-capitalized-file-names-on-origin-lower-case-locally

git add したときの表記で add されるため、正確に実際の filename の大文字小文字に沿うように、とのことです。
(逆に言うと、大文字小文字が合っていなくても add されてしまうということです)

file permission 問題

これもよく問題になります。Windows の file system では Linux とは違う permission が用いられているので、cygwin や git bash、なんなら WSL 上の bash であっても Windows の file system 上の file を扱っている以上は Linux から認識されるようになりません。これが、つけたと思った permission が git commit した結果には反映されない原因になります。

これを解決するには、以下のようにします。

❯ git update-index --chmod=+x test.sh

これで file permission も git に変更として記録されます。(commit 可能になります)

参考 : https://stackoverflow.com/questions/6476513/git-file-permissions-on-windows

※ 逆に言うと、Linux や macOS で作業している場合はふつうに chmod +x などしたものを commit するだけで git に反映されます。ふだん Windows だけで作業しているかたにはこちらのほうが不思議に映るかもしれません。

文字 encoding (Shift_JIS) 問題

さすがに EUC はもう見かけることも無くなってきましたが、古くから Windows 環境でメンテしている file や、古い Excel に頼っているような業務では Shift_JIS (より正確には MS932) を扱うことがありそうです。

これは該当データを入力として扱う application 側の対応も必要なので対応がかんたんではありませんが、文字コード変換だけであれば iconv などを使うと良いでしょう。

❯ iconv -f Shift_JIS -t UTF-8 test.txt

ただし、一部の文字では 1:1 の相互変換がされないことに注意が必要です。変換後が完全におなじになっているか、往復変換をかけた file を元のものと diff するなどして確認しておくとよいでしょう。

さらに、Windows に標準で入っている「メモ帳」は、UTF-8 で保存するときの選択肢によっては BOM をつけてしまうことがあるようで、これも要注意です。特別な用途以外でほぼ使わないものですので、つけないようにしておきましょう。
BOM がついてしまっている file の検出はこちらが参考になりそうです。

file system に絡む問題への解決策

ここまで個別によくある問題についてあげてみましたが、実は文字 encoding 以外の問題は、普段から ext4 など Linux 用の file system 上で作業することで解決します。

かたや、WSL では標準で Windows の drive が mount されており、双方から同一の file が扱えて非常に便利ですが、これは Windows の file system を用いているため、上記したような問題に軒並みぶつかります。

解決策のひとつとして、VS Code Dev Container や Docker などで container を使い、(Windows volume の bind mount するのではなく) container volume を ext4 などで利用するという方法があります。

また、わたしはあまり手元で試したことはないのですが、余裕があればこちらで紹介されているような方法を用いて別の作業領域を確保しておくと、長期的にいろいろと捗るかもしれません。

いっそ VM をつくって作業環境にしてしまうというのもアリです。ただし、その場合も便利だからといって Windows の drive を mount してそのまま使うと意味が無くなってしまうので注意してください。作業領域は VM 内のネイティブの volume を確保して使うようにしましょう。

いっそのことで言うとさらに、最近選択肢がぐっと増えてきた GitHub Codespaces などのようなクラウド開発環境を使用してしまうのもよさそうです。セキュリティなどの問題も難しくなってきている昨今、いろんな周辺の問題も一気に解決が目指せるかもしれません。

蛇足

勤怠管理や経費精算などの社内システムも今やほとんどが web で済むようになり、Office 製品群 (及び同等機能をもつ製品群) も web で利用できるものが多くなりました。こうなると、(少なくとも我々の) 業務に Windows はもう不要なのでは…? とも思われてきますが、業務での選択肢になりそうな Linux 搭載の PC 製品というのはまだまだ少ないようです。
選択肢が多くなるといいですね…