Latest topics 近況報告

Windows 10で「デスクトップの解像度」と「アクティブな信号解像度」が一致しない現象が発生したときの解決方法 - Feb 01, 2021

先日導入したLGの35型液晶をLet's noteの外部ディスプレイとして接続して、「複数のディスプレイ」→「表示画面を拡張する」を選択したときに、表示が期待通りにならない現象が発生した。

このディスプレイの最大解像度は3440×1440なのだけれど、Windowsのディスプレイ設定で解像度を誤って4K（3840×2160）に一度設定した後、3440×1440に戻したのに、ディスプレイ側に「推奨解像度を超える解像度の信号が入力されている」旨の表示が出てしまう。

どうも、「3840×2160の解像度で信号が出ているけれど、その真ん中あたりの3440×1440にだけデスクトップが表示されている」という訳の分からない状態になっているらしい。そのせいで、ディスプレイ側で3840×2160を3440×1440に収めるように縮小表示されてしまって実効表示領域が狭くなるし、デスクトップ部分を全体に表示しようとしたら、そこからさらにもう1回拡大することになるので、全体がボケボケになる、という具合だった。

この状態、Windowsの「設定」→「ディスプレイ」では確かに解像度として3440×1440が選択されているのだけれど……

「ディスプレイの詳細設定」を見ると、「デスクトップの解像度」が3440×1440なのに、「アクティブな信号解像度」は3840×2160と、それぞれ異なる数字が表示されていた。

この状態を解消する方法はないものかと検索していたら、別の製品のAmazonのカスタマーレビューにヒントがあった。曰く、Windowsの設定画面ではなく、ディスプレイアダプターのプロパティで「モードの一覧」を開くとすべての解像度・色深度のリストが表示され、そこから適切な解像度を選択し直すといいらしい。

試しに見てみると、このリストでは「3440×1440 True Color（32bit） 59ヘルツ」が選択された状態になっていた。そのすぐ下にあった「60ヘルツ」の項目を選択して「OK」でダイアログを閉じ、戻った際のディスプレイアダプターのプロパティで「適用」ボタンを押すと、無事に「デスクトップの解像度」と「アクティブな信号解像度」の両方が3440×1440に揃った状態になった。ディスプレイ側で等倍表示されるようになり、文字も絵もクッキリ見える状態になった。これでようやくまともに使える。

他に同じ現象で困った人がこの情報に辿り着けるように、記録を残しておく。

自宅のPCが急死したので買い換えた（死んだWindows 10 PCから新しいWindows 10 PCへの移行） - Jan 31, 2021

次の号に掲載される予定のシス管系女子の原稿を制作中に、突然画面がグリッチしたかと思ったら無反応になり、電源長押しで再起動を試みても画面は真っ暗のまま、UEFIの画面すら出てこなくなってしまった。追加で挿してたグラボを抜いても状況変わらずだったので、マザーボードとかオンボードグラフィックスとかその辺がお亡くなりになったのだと思われる。前回調達して移行したのは2017年5月だったので、享年約3年9ヵ月だった。

作業中の原稿は、そのPCの起動ドライブだったSSD（M.2 NVMe）の中に閉じ込められてしまってたんだけど、AOTECHというブランドから出てるUSB接続の外付けHDDとして使えるようにするケース（当初、「M.2」という点だけに気を取られて「M.2 SATA」のみ対応のケースを買いそうになってしまったけど、Twitter上で「安い物はM.2 SATAのみ対応でM.2 NVMeと互換性が無いよ」と指摘を頂いて、ギリギリで回避できた。危なかった）を使って取り出して、別のPCでとりあえず完成まで仕上げて提出した。この間1週間もかかってない。

それと並行して進めなくてはならなかった新PCの調達だけど、そういう切羽詰まった状況で吟味してられなかったので、前回と同じくパソコン工房のBTOのクリエイター向け構成にした。4年の延長保証を付けずに購入したPCが3年9ヵ月で死んでしまったので、今回は4年保証も付けた。

移行は概ね、過去にやった以下のそれぞれの作業の合わせ技で行った。

• 自宅PCでの、Windows 7からWindows 10への移行
• 業務PCでの、リアルUbuntuからWSL1上のUbuntuへの移行

最新の情報へのアップデートも兼ねて、改めて書き起こしておく。

続きを表示する ...

WSLでフォルダーを作るとWindowsでNTFSなパーティションでも大文字小文字が区別される落とし穴がある - Dec 23, 2020

業務でWindowsネイティブのアプリケーションに関わることになって、Visual Studio用のプロジェクトになってるリポジトリをcloneしてきてビルドしようとしたら、fatal error C1083: コンパイラの中間生成物 ファイルを開けません。（ファイルパス）:No such file or directory とエラーが出てビルドできなくて、ドハマリしてた。Windowsのエクスプローラで見ても確かにその位置にファイルはあるのに。何故？

他の人を巻き込んで調査に協力してもらって最終的に分かったことは、ファイルシステムがNTFSのパーティションでもパスの大文字小文字が区別される状態になっていることがあり、エラーメッセージに現れていたパス（すべて小文字）では実際のファイル（大文字小文字混在）にアクセスできなかったのが原因だということだった。パスの大文字小文字を区別しない状態に設定を修正したら、問題は解決した。

何故そんな状態が発生していたかというと、今使っている作業環境（Windows 10）に引っ越すにあたり、旧環境から必要なファイルをまとめて持ってくるために、WSL1上のrsyncを使ったのが原因だったようだ。Per-directory case sensitivity and WSL | Windows Command Lineという記事によると、This option controls which directories are treated as case sensitive, and whether new directories created with WSL will have the flag set.（（DevFsのcaseオプションは）ディレクトリー名の大文字小文字の区別を制御し、WSLで新たに作られたディレクトリーは大文字小文字を区別するフラグがセットされた状態となる）とあった。PowerShellで当該フォルダに cd して fsutil.exe file queryCaseSensitiveInfo . と実行してみると、確かに問題のcloneされたリポジトリのディレクトリーはパスの大文字小文字が区別される状態になっていた。

この状態は fsutil.exe というコマンドを使って、fsutil.exe file setcasesensitiveinfo . disable とすれば解除できるそうなのだけれど、残念ながらこの fsutil.exe は再帰的な実行に対応していないため、問題を解決しようと思うと、cloneしたリポジトリ配下のファイルやディレクトリーすべてにこのコマンド列を実行しなくてはならない。それはあまりにかったるいしヒューマンエラーも起こりそうだったので、既存の質問に寄せられていた回答に倣って、PowerShellで以下のようなコマンド列を実行して再帰的にディレクトリーの設定を修正することにした。

(Get-ChildItem -Recurse -Directory).FullName | ForEach-Object {fsutil.exe file setCaseSensitiveInfo $_ disable}

普段はファイル名に大文字小文字を混在させないようになるべく意識しているせいで、この状態が発生している事に気付いてなかった。メモ帳や秀丸エディタなどのWindowsアプリケーションでエラーメッセージに現れていたパスのファイルを開こうとして、確かにファイルはあるのにファイルが見つからないと言われる、という現象が調査の過程で発生して、それでやっと気が付いたんだった。自分で知らないうちに掘っていた落とし穴に、掘ったことにも気付かず自分でハマってしまった。

という学びを得た話をWSLアドベントカレンダー2020に書けばよかったんだけど、もうすべて埋まってたので、記録のためにここに放流しておく。

WindowsのストアアプリがWindowsの更新後に「指定されたユーザーには有効なプロファイルがありません」で起動できなくなる問題の回避方法 - Nov 09, 2020

結論：Windowsをもう1回再起動してください。

Windows 10 1909からWindows 10 20H2に更新した後でWindows Terminalを起動しようとしたら、「指定されたユーザーには有効なプロファイルがありません」と言われて起動できなくなってしまった。Preview版の頃に入れてそのまま使っていたのがまずかったのか？と思って1回消してストアから入れ直してみたけど、症状は変わらなかった。

エラーメッセージで検索すると、どうもこれはストアアプリで共通して起こる問題らしく、他にはiTunesやSkypeやWordやExcelでも発生した事例があるようだった。ただ、検索上位に出てくる情報は役に立たない情報ばかり（何々というアプリが原因かもという的外れなリプライしか付いてなかったり、Wordのバージョンを書いて下さいというリプライに質問者が無反応で放置してたり）だった。

そんな中に1つ、Stack Overflowとかの情報を機械翻訳してる系のスパムサイトか？と思える文面のページがあって、そこには「更新後にもう一度再起動するで問題を解決できます」と書かれていた。更新の後に再起動かかった直後なのに、そんなので本当に効くのか？　と、機械翻訳くささに半信半疑になりつつも実際試してみたら、これが当たりだった。本当に2回目の再起動で状況が改善して、Windows Terminalが起動できる状態に戻った。1回アンインストールしたので、設定が吹っ飛んでしまったけど……

（教えてもらって気が付きましたが、ページ内に小さくリンクがありました。元記事はHow to fix broken Windows user profile after latest Win10 pro upgrade? - Super Userだそうです。）

次にググる人が少しでも優位な情報に辿り着きやすいように、ここに記録を残しておく事にする。

Windows 10の環境構築 - Apr 05, 2019

会社で新しくWindows 10 PCをメイン環境として使い始めようとしていて、セットアップするのになんやかや詰まったので記録を残しておきます。

任意のホームディレクトリ名でアカウントを作る

何も考えずにMicrosoftアカウントで使い始めると、例えば shimoda.hiroshiみたいなMicrosoftアカウントだったら C:\Users\shimo みたいな適当にぶった切られた名前でホームディレクトリができてしまう。C:\Users\piro みたいに任意の名前のホームディレクトリにするためには、以下の手順を踏まないといけない。

1. 使いたいホームディレクトリの名前でローカルアカウントを作成する。
2. そのローカルアカウントを管理者にする。
3. そのローカルアカウントでログオンする。
4. そのローカルアカウントからMicrosoftアカウントに切り替える。
5. 再起動後、古いホームディレクトリ（C:\Users\shimo とか）を管理者権限で削除する。

コンピューター名を変える

コンピューター名はWindowsの通常使用だと意識する事はあまりなくて、LAN内で参照する時に使う程度だけど、WSLでホスト名として常時目にする事になる。これがランダムっぽい名前だと結構いらつくので、最初に変えておく。（以後はWSLでも勝手にこの情報を参照してくれる）

WSLの初期設定

WSLを有効化してストアからUbuntuをインストールした後にやること。

1. 起動時の初期ディレクトリをWindowsのホームではなくWSL上のhomeにする。 Windows Terminalを使う場合、Windows Terminalの設定（settings.json）のWSL用の項目の "source": "Windows.Terminal.Wsl" をコメントアウトして、代わりに "commandline": "wsl.exe ~ -d Ubuntu" と書いておく。

2. Windowsのファイルシステム上でWSLのファイルのパーミッションを保存できるようにするために、 sudo vim /etc/wsl.conf で設定ファイルを開いて以下の内容を保存する。

   [automount]
   options = "metadata,umask=22,fmask=111"
   

   マウントした既存のファイルや新たに作成したファイルが全部実行権限付きで認識されるとGitを使うのに不便なので、maskを指定して実行権限がつかないようにしておく。

3. WSLのシェルを一旦閉じて、サービス一覧から LxssManager を探し、再起動する。これで、上記の設定が反映される。
4. ln -s /mnt/c/Users/username/Destop ~/Desktop、ln -s /mnt/c/Users/username/Documents ~/Documents、ln -s /mnt/c/Users/username/Downloads ~/Downloads、ln -s /mnt/c/Users/Public ~/Public などとして、WSLでよく使うWindowsのフォルダにシンボリックリンクを作っておく。

5. シェルでよく使う基本の設定をする。

   1. ~/.bashrc に以下の内容を加えて、コマンド履歴の逆方向検索に Ctrl-S を使えるようにする。

      stty stop undef
      stty start undef
      

   2. ~/.bashrc に以下の内容を加えて、複数のシェルでコマンド履歴を共有するようにする。

      function share_history {
        history -a
        tac ~/.bash_history | awk '!a[$0]++' | tac > ~/.bash_history.tmp
        [ -f ~/.bash_history.tmp ] && mv ~/.bash_history{.tmp,} && history -c && history -r
      }
      PROMPT_COMMAND='share_history'
      shopt -u histappend
      export HISTSIZE=99999
      

   3. ~/.bashrc に以下の内容を加えて、よく使うエイリアスを使えるようにする。

      export LESS='--no-init --RAW-CONTROL-CHARS --LONG-PROMPT --shift 4'
      alias grep!='grep --color=always'
      alias jq!='jq --color-output'
      alias cd='pushd > /dev/null'
      

    

6. SSHの秘密鍵を設置して、他のホストにSSHで接続できるようにする。 基本方針として、WSLのsshクライアントから直接秘密鍵を触らずに、Windows 10に最初から入ってるOpenSSHのssh-agentに鍵を読み込ませて、必ずrupor-github/wsl-ssh-agent経由で利用することにする。

   1. Windowsの「管理ツール」の「サービス」で「OpenSSH Authentication Agent」を手動で有効化し、自動起動するように設定する。
   2. rupor-github/wsl-ssh-agentのリリース一覧から最新版のバイナリのwsl-ssh-agent.7zをダウンロードしてきて展開し、中身をC:\Program Files (x86)\wsl-ssh-agent\あたりに置く。
   3. wsl-ssh-agent-gui.exe へのショートカットを C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp（全ユーザー向けの場合）か、%AppData%\Microsoft\Windows\Start Menu\Programs\Startup（自分のみの場合。Win-Rで shell:startup を実行して開かれるスタートアップフォルダ）に作る。
   4. 作成したショートカットのプロパティを開いて「リンク先」に -socket "%temp%\ssh-agent.sock" と起動オプションを付け足す。これで、毎回起動時にssh-agentのためのソケットが作られるようになる。
   5. この時点ではまだ wsl-ssh-agent-gui.exe が起動していないので、ショートカットをダブルクリックして起動する。
   6. WSLのbashを起動する。
   7. ~/.bashrc に export SSH_AUTH_SOCK=/mnt/c/Users/$USER/AppData/Local/Temp/ssh-agent.sock という行を足す。これで、WSLの環境に入ると自動的にWindows側のssh-agentと繋がるようになる。
   8. source ~/.bashrc を実行して設定を反映する。
   9. 旧環境から ~/.ssh （秘密鍵、公開鍵、設定ファイル）を持ってくる。
   10. chmod 700 ~/.ssh で、ディレクトリのパーミッションを他のユーザーから参照不可能なようにする。
   11. ssh-add ~/.ssh/(秘密鍵) を実行し、秘密鍵を ssh-agent に読み込ませる。
   12. ほかのホストにログインできることを確認する。

   （以下は、Windows 10のOpenSSHを使うようになるまで使ってた、PuTTYのPageantに鍵を読み込ませて、必ずweasel-pageant経由で利用する場合の手順。歴史的資料として残す。

   1. C:\Users\username\.ssh （/mnt/c/Users/username/.ssh）を作成し、旧環境からファイルをコピーする。
   2. PuTTYをインストールする。
   3. puttygen.exeで秘密鍵のid_rsaをインポートして、PuTTY形式の秘密鍵 id_rsa.ppk として保存する。
   4. Win-Rで shell:startup を実行してスタートアップフォルダを開き、pageant.exe のショートカットを作成する。
   5. pageant.exe を起動して、先の id_rsa.ppk を読み込ませる。
   6. weasel-pageantの最新リリース版バイナリをダウンロードし、展開したファイルを C:\Program Files (x86)\wsl-pageant に置く。
   7. マウントオプションで実行権限がつかないようにしているので、chmod +x /mnt/c/Program\ Files\ \(x86\)/weasel-pageant/weasel-pageant /mnt/c/Program\ Files\ \(x86\)/weasel-pageant/helper.exe で明示的に実行権限を設定する。
   8. echo 'eval $(/mnt/c/Program\ Files\ \(x86\)/weasel-pageant/weasel-pageant -r)' >> ~/.bashrc で、weasel-pageantを自動起動するようにする。（weasel-pageantにどのようなオプションを設定するべきかについては、必ず最新の解説を参照すること。）
   9. mkdir ~/.ssh; chmod 700 ~/.ssh で、設定ファイル等の置き場所を用意する。 ln -s /mnt/c/Users/username/.ssh ~/.ssh でシンボリックリンクとして作成してしまうと、次項の設定をしてもSSH接続を受け付けられなくなってしまう（~/.ssh のパーミッションを適切に設定できなくなる）ので、必ずここは普通のディレクトリとして作成しておく。
   10. ほかのホストにログインできることを確認する。

   ）

7. 他のホストからSSHで接続できるようにする。 常時使うわけではないが、必要な時はできるようにしておく。WSLのUbuntuにはopenssh-serverが最初から入っているので、後は必要な設定をするだけで使える。
   1. 前項で /mnt/c/Users/username/.ssh/ 以下に公開鍵等もコピーできているはずなので、/mnt/c/Users/username/.ssh/authorized_keys があるのであれば ~/.ssh/authorized_keys にコピーする。なければ、/mnt/c/Users/username/.ssh/id_rsa.pub を ~/.ssh/authorized_keys にコピーする。
   2. chmod 600 ~/.ssh/authorized_keys として、パーミッションを適切に設定する。
   3. sudo service ssh start してsshdを起動する。
   4. ssh localhost でログインできることを確認する。
   5. Windows Defenderのファイアウォールの詳細設定で、「受信の規則」で以下の内容の規則を作成する。
      • 種類：ポート
      • プロトコル：TCP
      • ポート：22
      • プロファイル：「ドメイン」と「プライベート」だけ残して、「パブリック」はチェックを外す（怖いので）。
      • 名前：ssh
   6. 他のホストからログインできることを確認する。
   7. sudo service ssh stop してsshdを停止する。（以後は、必要な時にだけ起動する）
8. pecoを使えるようにする。
   1. mkdir -p ~/local/bin で、ユーザー固有のバイナリ置き場を用意する。
   2. echo 'export PATH="~/local/bin:$PATH"' >> ~/.bashrc してパスを通しておく。
   3. pecoの最新リリース版から適切なバイナリをダウンロードする（今回は peco_linux_amd64.tar.gz を使った）。
   4. unar peco_linux_amd64.tar.gz でファイルを展開する。
   5. 取り出されたファイル群に含まれる peco を ~/local/bin/ に移動し、chmod +x ~/local/bin/peck で実行権限を設定する。
   6. 私的によく使う設定のまとめをraw形式でダウンロードし、echo 'source ~/peco-commands.sh' >> ~/.bashrc で自動的に読み込むように設定する。

9. bash-git-promptを使うようにする。

   1. cd ~/ して git clone https://github.com/magicmonty/bash-git-prompt.git ~/.bash-git-prompt --depth=1 で必要なファイルをローカルに用意する。

   2. 以下の内容を ~/.bashrc に追加して、機能を有効化する。

      GIT_PROMPT_ONLY_IN_REPO=1
      source ~/.bash-git-prompt/gitprompt.sh
      GIT_PROMPT_THEME=Single_line_Ubuntu
      

   3. 時刻表示の部分が余計なので、以下のように編集する。

      diff --git a/themes/Single_line_Ubuntu.bgptheme b/themes/Single_line_Ubuntu.bgptheme
      index 7dd3a4f..542b259 100644
      --- a/themes/Single_line_Ubuntu.bgptheme
      +++ b/themes/Single_line_Ubuntu.bgptheme
      @@ -15,7 +15,7 @@ override_git_prompt_colors() {
         GIT_PROMPT_COMMAND_OK="${Green}✔ "
         GIT_PROMPT_COMMAND_FAIL="${Red}✘ "
      
      
      -  GIT_PROMPT_START_USER="_LAST_COMMAND_INDICATOR_ ${White}${Time12a}${ResetColor} ${Cyan}${PathShort}${ResetColor}"
      -  GIT_PROMPT_END_USER="${ResetColor} $ "
      -  GIT_PROMPT_END_ROOT="${BoldRed} # "
      +  GIT_PROMPT_START_USER="${Cyan}${PathShort}${ResetColor}"
      +  GIT_PROMPT_END_USER="${ResetColor}\$ "
      +  GIT_PROMPT_END_ROOT="${BoldRed}# "
      

    
10. sudo update-alternatives --config editor でデフォルトのエディタをvim.basicに切り替えておく。

ファイルの移行

ここまででWSL上のrsyncが使えるようになっているので、旧環境から rsync -a xxx.xxx.xxx.xxx:~/path/to/directory/ ~/Public/ みたいにしてパーミッションの情報込みでファイルを持ってこれる。 （シンボリックリンクまで勝手に辿らせると大変なことになりかねないので、シンボリックリンクの先は個別に辿るのがよい気がする。）

今回は移行元がハードウェア上にインストールされたUbuntuだったけれども、移行元がWindows 10マシンの場合も上記の要領であらかじめsshdを起動しておけば、同様にrsyncでファイルを持ってこれる。

Firefoxのビルド環境を整える

最近のMozillaBuildとmozilla-centralはよくできてて、だいたい一発で環境ができあがる。以下、前半は会社のブログに書いた手順の通り。

1. MozillaBuildの最新版リリースをダウンロードし、インストールする。一般的にはc:\mozilla-buildにインストールする。
2. C:\mozilla-sourceの位置にフォルダを作る。Firefoxのソースコード一式はこの配下に置く事になる。
3. c:\mozilla-build\start-shell.batを実行して、MozillaBuildのシェル（Bash）を起動する。
4. echo 'export PATH=$PATH:~/.cargo/bin' >> ~/.bash_profile を実行して、MozillaBuildのシェルを一旦終了し、c:\mozilla-build\start-shell.batで起動し直す。
5. cd /c/mozilla-source して、 hg clone https://hg.mozilla.org/mozilla-central でmozilla-centralをcloneする。
6. cd mozilla-central してリポジトリに入り、./mach bootstrap を実行する。これにより、Visual StudioやRustなどのビルドに必要なソフトウェア群が自動インストールされる。
7. ./mach build して、ビルドできる事を確認する。
8. ./mach run して、ビルドしたFirefoxを起動できる事を確認する。

9. WSLとホームを共用してない関係でBashの設定が素のままなので、~/.bash_profileに以下を追記する。

   # Ctrl-Sで履歴を逆検索できるようにする
   stty stop undef
   stty start undef
   
   # MozillaBuildの環境にはtacが無いので、関数で代用する
   function tac {
     exec sed '1!G;h;$!d' ${@+"$@"}
   }
   
   # 複数のシェルで履歴を共有する
   function share_history {
     history -a
     tac ~/.bash_history | awk '!a[$0]++' | tac > ~/.bash_history.tmp
     [ -f ~/.bash_history.tmp ] && mv ~/.bash_history{.tmp,} && history -c && history -r
   }
   PROMPT_COMMAND='share_history'
   shopt -u histappend
   export HISTSIZE=99999
   

10. Mozillaのサーバーに認証を求める時のユーザー名指定を省略できるようにするために、~/.ssh/configに以下を追記する。

    Host hg.mozilla.org
      User yuki@clear-code.com
    

11. ssh hg.mozilla.org してみて、認証できるかを確認する。（シェルには入れないでそのまま接続が切れるが、それでOK。）

12. tryserverを使うために、~/.hgrcに以下を追記する。

    [paths]
    try = ssh://hg.mozilla.org/try
    

13. ./mach try empty で空のリクエストを送れるかどうか確認する。

14. Phabricatorを使うための準備をする。
15. hg grepfileでワーキングコピーのファイルを対象に検索できるようにするために、hg-grepfileをインストールする。ただし2019年4月16日現在のバージョンは最新のMercurialで動かないため、修正のプルリクエストがマージされるまでの間は独自の修正版を使う必要がある。

タスクビューをすぐに出せるようにする（仮想デスクトップをすぐに切り替えられるようにする）

最近までWindows 10標準で仮想デスクトップ機能があるということを把握してませんでした。今回調べて初めて知りました。

Ubuntuではメインの作業画面とThunderbirdを使う（メールを読み書きする）画面とを分けていて、画面の端にカーソルでちょいっと触れると仮想デスクトップ切り替えの画面が出てくるようになってたんだけど、そういう事をできるようにするにはユーティリティが必要。タスクビューの切り替え画面を出すこと自体は、Windowsキー＋Tabでできるので、任意のジェスチャでこのキー操作を代替すればよい。

マウスジェスチャーソフトの「MouseGestureL.ahk」でマウスホイールにWindows10の「タスクビュー」を割り当てる | PC ウェブログという記事を参考に、以下のようにした。

1. MouseGestureL.ahkをダウンロードする。
2. zipを展開してC:\Program Files配下あたりに適当に置く。
3. Setup.vbsを実行する。
4. インストールされて設定画面が開かれる。
5. 「ジェスチャー」タブに切り替えて、以下のジェスチャーを追加する。
   • 名称：screen-edge
   • ジェスチャ－1：CRB_（画面右下角に接触）
   • ジェスチャー2：CLB_（画面左下角に接触）
6. 「メイン」タブに切り替えて、「デフォルト」の割り当て済みジェスチャーをscreen-edge以外すべて削除する。

7. screen-edgeのアクションスクリプトを以下の通りに書く。

   ;キー操作を発生させる
   Send, #{TAB down}{TAB up}
   

8. 「その他」タブに切り替えて、「スタートアップに登録」で自動起動するようにする。

これで、画面の端に触れるだけで仮想デスクトップを切り替えられるようになる。

2020年5月1日追記。初期設定ではRB（右ボタン）で始まるジェスチャがいくつか定義されてるんだけど、これがあると、Windows全体で右ボタンの動作に影響が及んでしまう。具体的には、window.addEventListener('mousedown', ...)みたいな方法でマウスのボタンが押し下げられたことを検知しようとしても、右ボタンだけmousedownが取れなくなる（ボタンを放したときに初めてmousedownが発火するようになる）。自分はscreen-edgeをトリガーにした操作しか使わないので、RBで始まるジェスチャは全部削除した。

Selection Clipboard的なこと（文字列を選択するだけでコピー）を実現する……のは諦めた

Ubuntuではテキストを選択すると通常のクリップボードとは別の専用のバッファにテキストが格納されてミドルクリックで貼り付けるという動作になってた（これ自体はXの機能とのこと）んだけど、GNOME Terminal（端末）でコピー＆ペーストのキーバインドが他のGUIアプリと違っていたこともあって自分でも驚くくらいに意外と多用していて、Windows環境でWSLを使っているとそのときの感覚が抜けなくてつい戸惑ってしまう。

代わりになりそうなものを探してみたらいくつか情報が見つかったんだけど、どれも今使うにはちょっと厳しい感じだった。

• copipex：32bitアプリだからなのか、64bit版Firefoxや秀丸エディタでは反応してくれなかった。作者の方によると、64bit版作成の予定は無いとのこと。
• True X-Mouse Gizmo：Xのマウス関連操作を再現することを意識しているらしく、Selection Clipboard以外の余計な機能が多くて辛い。特に、mouseoverでフォーカスを切り替える機能のせいでタスクバーがまともに使えなくなるのが致命的。
• AutoCopyX：なんかWindows Defenderでマルウェア判定されるので怖い。

もうちょっと悪あがきしてみようと思って「Windows selection auto copy」という感じのキーワードで検索してみたら、AutoHotKey用のスクリプトの例が出てきた。自分は結局AutoHotKeyは入れずにMouseGestureL.ahkだけで使ってるんだけど、これの実態がほぼ同じ物のようで、MouseGestureL.ahkのインストール先にあるMG_User.ahkのユーザー定義サブルーチンの所に以下のスクリプトを追加してMouseGestureL.ahkを再起動したら普通に使えた。

ただ、Ubuntuの時と違って専用のバッファが使われる訳ではないから、選択→Ctrl-Cでコピー→貼り付けたい箇所にある邪魔なテキストを選択→Ctrl-V という事をしようとすると、貼り付け先の邪魔なテキストの方がクリップボードに入ってしまうという難点があった。なので解説を見ながら試行錯誤して、クリップボードとは別のバッファを持つようなスクリプトを作ってみた。MouseGestureL.ahk単体版ではなくAutoHotKeyの方を使う場合は、上記の内容をSelectionClipboard.ahkという名前で保存し、ファイル名を指定して実行→shell:startupで開かれるスタートアップフォルダの中に置けばいいみたい。

で、しばらく試してみてたんだけど、以下の問題をどうしても解決できなかった。

• テキストが選択されてない状態でも左ボタンのドラッグやダブルクリックで常にCtrl-Cが送信されるので、Windowsのエラー音がその度に鳴ってうざい
• WSLのウィンドウをタイトルバーのドラッグで移動したりリサイズしたりすると、Ctrl-Cが送信されてSIGINTになって実行中のプロセスが終了してしまう（致命的）

Ctrl-Cでクリップボードへのコピーを試行するのが元凶なので、それ無しで選択範囲のテキストを取得できる方法があればいいんだけど、それはエディットコントロールに対してのみ動作する関数しか用意されてなくて、オフィシャルのサンプルの時点で「標準のエディットコントロール以外でも使えるのはCtrl-Cを使う方法だ」と紹介されてるレベルだったので、AutoHotKeyの制限事項としてどうにもならないというのが結論のようです。残念。

Aero Shake（ウィンドウのタイトルバーを付かんで揺すると他のウィンドウが最小化される）を無効化する

これ機能として欲しくなることが無くてまず誤爆で困るばかりなんですけど？

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced にDisallowShakingというDWORDの値を作ってデータを1にすると、この機能が無効化されるそうです。

なんで自動化してないの

そんなに頻繁にやるわけじゃなくて、数年に1回やる程度なので、

• そのためだけにPowerShell覚える気になれない。一生懸命覚えてもLinuxとかBSDとかmacOSとかで使えないし。→と思ってたら他のプラットフォームでも動かせるという指摘を頂きました。
• 数年に1回の実行ペースでは、下手に自動化してると、前回実行時から色々前提が変わっていて途中でこけてドツボにはまりそうで怖い（実際今回もweasel-pageantの推奨設定が以前調べた時と変わっていた）。

という風に思ってます。

毎月やるとか、まとめて10台くらいやるとか、そういう前提が出てきたら重い腰を上げてPowerShell覚えるかもしれないですね。

まだ後から書き足しそう。

（後日談：これとは別のPCについて行った、Bash on Ubuntu on WindowsからストアアプリのUbuntuへの環境引き継ぎの話。ここに書いた話を一部参照した。）

SSDの残り寿命の計算 - Feb 12, 2019

今やHDDより頑丈な「SSDの寿命」と耐久性の凄さ | ちもろぐを読んで「TBW」という指標の存在を初めて知り、自分が今使っている機材の寿命を知りたくなったので計算してみた。

現行機材にはSSDが2つマウントされてる。1つはシステムとデータが両方入ってるSamsung SSD 930 EVO 500GBで、公称値は200TBW。もう1つは仮想マシン置き場にしているSamsung SSD 680 EVO 250GBで、公称値は150TBW。CrystalDiskInfoで総書き込み量と使用時間を調べて計算したら、前者はだいたい残り2年9ヵ月の命、後者は使用頻度が低いせいで残り654年の命と出た。後者はともかく前者は機材更新に備えておかないといけない……

メーカー公称値のTBWとCrystalDiskInfoで表示される数字からの計算が面倒だったので、フォームを埋めるだけで計算してくれるような物を用意してみました。

• 寿命保証：TBW（スペック上の公称値）
• 総書込量：GB
• 使用時間：時間

残り寿命を計算

SH-M03でSDカードを内部ストレージの代わりに使うように設定した - Jun 09, 2017

手厚いサポートの恩恵をほとんど受けてないのでSoftbank MobileをやめてMVNOにしよう、ということで数ヶ月前から準備を進めてて、まずSIMロックのかかってない端末に機種変更した。そこそこ性能が良くてモバイルSuicaが使えること、を条件に検討した結果AQUOSブランドのSH-M03にした（既にこの次のモデルが出てたけど、次のモデルはコストダウンの方に舵を切った結果スペックが落ちてたので……）。

……んだけど、これが本体の内蔵ストレージがめっちゃ少なくて、この前に使ってた203SHは32GBあったのにこれは16GBだからアプリの自動更新が何度か降ってきたらもうそれだけでパンパン。microSDを外部ストレージとして使うようにはもちろんしてたんだけど、それでも全然追っつかない。Kindleのようにデータを自分の領域に保存するアプリはそもそも外部ストレージがいくらあっても使っちゃくれないし。

検索したら、Android 6以降だとSDカードを内部ストレージの追加領域にできるみたいな話が出てきたのでやってみた。結論としては、今まで外部ストレージだったmicroSDがそっくりそのまま内部ストレージになる感じになった。

以下、やったこと。

1. 準備。
   1. Androidのバージョンを確認する。SH-M03はAndroid 6.0.1で、6以上という条件を満たしてるので問題なし。
   2. microSDの内容をPCに退避する。一旦フォーマットする必要があるという説明を見たので。
   3. 設定→ストレージとUSB でmicroSDをタップし、右上のメニューボタンをタップして出てくるメニューからフォーマットを選択する。 この時、SDカードを内部ストレージとして使う機能を解放してる機種で、且つmicroSDの性能が充分にあると「内部ストレージとしてフォーマット」という項目がメニューに表示されて、それを選択すればいいようなんだけど、SH-M03はこの機能が封印されてるのか、使ってるmicroSDのせいなのか、自分の環境では「外部ストレージとしてフォーマット」しか表示されなかった。ので、とりあえずそれを選択してフォーマットし直した。

2. 外部ストレージとしてしか認識されないmicroSDを強制的に内部ストレージにする。（前の手順で内部ストレージとしてフォーマットできてるなら、多分この手順は不要）

   1. 作業用PCにAndroid Studioをインストールする。
   2. コマンドプロンプトから開発ツールを使えるようにするために、環境変数PathにC:\Users\（ユーザー名）\AppData\Local\Android\Sdk\platform-toolsを加える。
   3. Android端末側で、設定→端末情報→ビルド番号 を連打して開発者向けの機能を使えるようにする。
   4. Android端末で設定→開発者向けオプションを開いて機能を有効化し、「USBデバッグ」をONにする。
   5. USBケーブルでPCとAndroid端末を接続する。
   6. コマンドプロンプトを開き、adb shellを実行してAndroid端末に接続する。 USBデバッグ接続を許可するかどうかの確認がAndroid端末の画面に出るので、許可する。
      • この時、2つ以上のAndroid端末がPCに接続されているとどこに繋ぎに行けばいいのか分からないということでerror: more than one device/emulatorというエラーメッセージが出て接続できない（自分の環境ではCintiq Companion Hybridが繋がっててこれにハマった）ので、関係無いAndroid端末は外しておく。

   7. adb shellで無事端末に接続できたら、sm disk-listを実行する。すると、以下のような感じで認識されてるmicroSDの識別子が表示される。

      C:\Users\piro>adb shell
      shell@SH-M03:/ $ sm list-disks
      disk:179,64
      shell@SH-M03:/ $
      

      ここではdisk:179,64がそれにあたる。

   8. sm partition （microSDの識別子） privateを実行する。

      shell@SH-M03:/ $ sm partition disk:179,64 private
      shell@SH-M03:/ $
      

      しばらく待たされて処理が完了する。

      • この時、privateと指定するとmicroSDの領域全体が内部ストレージとして使えるようになるんだけど、文献によっては「全体を内部ストレージにするとおかしくなるのでmixed 50のように指定すること」のように案内してたりする。が、自分の環境で試した限りではmixedを指定しても期待したような効果を得られず、むしろprivateにした方が想定通りの結果を得られた。
       
   9. Android端末を再起動する。
    
3. 内部ストレージとしてフォーマットされたmicroSDに、データを移行する。
   1. 設定→ストレージとUSBを開くとmicroSDが「外部ストレージ」と括られずに「内部ストレージ」のすぐ下に表示されているので、これをタップする。
   2. 右上のメニューボタンをタップして出てくるメニューから「データを移行」を選択する。
   3. 確認の後、本体内蔵のメモリからmicroSDに諸々のデータやアプリが移動される。

この状態でファイルマネージャの類のアプリを起動してみると、以前は内部ストレージとSDカード（外部ストレージ）の2つが見えていたのが、内部ストレージが見えなくなってSDカードだけ表示されるようになっていた。 また、Android端末をPCに接続しても、microSDの分の領域だけが見えるようになっていた。

最初に退避しておいたmicroSDの中身を書き戻すというかマージすれば、移行作業は完了。逆に、microSDを切り離して元の状態に戻したい時は、設定→ストレージとUSB で内部ストレージの項目をタップして、右上のメニューボタンをタップして出てくるメニューから「データを移行」を選択すればいいんだと思う。やる前にmicroSDの中に保存されてるデータを消して内部ストレージに収まる状態にしておかないと、多分、失敗するか警告されて処理を実行できないんじゃないかなあ。

Ubuntu 16.04でduplicityを使おうとしたらPythonのエラーが出る件 - May 22, 2017

Ubuntuのバックアップユーティリティはバックエンドにduplicityというツールを使ってるんだけど、ユーティリティ越しだと大雑把な操作しかできないので、個別にファイルを復元したいみたいな時はduplicityコマンドを直接使う必要がある。それでduplicityを使おうとしたらこんなエラーが出て詰んだ。

$ duplicity --version
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 45, in <module>
    from lockfile import LockFile as FileLock
ImportError: No module named lockfile

エラーメッセージで検索すると英語の情報しか見つからなかったんだけど、どうも、Pythonの複数バージョン使い分けのためにpyenvを入れていると、duplicityがシステムのPythonではなくpyenvのPythonの方を見に行ってしまうのが原因だったようだ。

• Bug #1576514 “After upgrade to Xenial Duplicity crashes “No modu...” : Bugs : duplicity package : Ubuntu
• python - Duplicity install error: ImportError: No module named duplicity - Ask Ubuntu

そういえばGroonga関係のドキュメントを書くのにSphinxを使わないといけなくて、Sphinxが要求するPythonのバージョンがシステムのPythonのバージョンより新しかったからpyenvで乗り切ったような記憶がある。そのせいか。

PythonのことはさっぱりなのでどうやればpyenvとシステムのPythonを共存できるのかやり方を誰か教えて！と社内で聞いたら、デフォルトではシステムにインストールされたバージョンのPythonを使うようにして、特定のディレクトリ配下でだけ必要なバージョンを使うようにすれば良いと教えて貰えた

$ pyenv global system
$ duplicity --version
duplicity 0.7.06

でも同時に、Pythonコミュニティ的にはpyenvを使って欲しくない流れになっているみたいな事も聞いたので、自分の中でのPython触りたくない度合いがまた増してしまった。

Windows 10移行時の環境設定でエクスプローラのアイコンのオーバーレイ表示が効かない奴に遭遇した - May 08, 2017

TortoiseGitのステータス表示が出なくてなんでや、と思って検索したらStack Overflowのスレとか日本語の解説とかがヒットした。要するに HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers以下のキーの文字コード順の並びで上位11個に入ってないやつは反映されないと……んでDropboxもTortoiseGitも登録しすぎと……そのうえOneDriveとかも入ってきてもうすっちゃかめっちゃかや。そういやTwitterのタイムラインでそんな話題が流れてたのを見た記憶がある。

とりあえずどっちが致命的かというとTortoiseGitの方なので、そっちが上に来るようにキー名を編集してみたところ、無事アイコンオーバーレイが有効になった。それにしても上位の取り合いのために名前の前にスペースを入れるとか、今は本当に2017年なんですか？って気分だ。

Windows 7からWindows 10への移行 - May 08, 2017

• 自宅のマシンの動作が最近ちょっと怪しくて、スリープから復帰しないみたいな事が発生する頻度が高くなってきた気がしてた。調べてみたら新調してから5年くらい経っていたので、寿命が近付いているのかもしれない。
• 会社で新調したマシンでWindows 10 on SSDを体験したらあまりに爆速だった。

という理由から、作業途中に突然死して慌てるくらいなら先んじて移行しておいた方がいいだろうと思って自宅マシンを買い換えた。パソコン工房のマンガ描きたい人向けモデルをベースに、メインを500GB SSDにしてサブは250GB SSDというSSDオンリー構成で発注し、届いた後で旧マシンからSATAのHDDを移植した（旧マシンには3台のHDDがあったんだけど、ベイが足りないので容量が一番小さかった1台はドロップアウトした。まだ動くので、USB接続で使うかもしれない）。

元々、2画面＋Cintiq Companion Hybridという計3画面の構成で使っていて、旧マシンでは3画面同時出力にビデオカードが必要だったのでそれも移植したんだけど、実際繋いでみたら新マシンはオンボードグラフィックだけで3画面いけた。追加のビデオカード、ただの電熱器になってもうた……

自分がよくやるWindowsの環境移行は、半分くらい真面目に移行して半分くらいは横着するというパターンで、こんな感じの方針でやった。

1. アプリケーションは、関連付け等きちんと初期化されないとまずいので、全部インストーラーから入れ直す。
2. 旧マシンから移植したHDDから、以下の位置にあるデータの中でよく使うアプリに関係する物を新環境の対応するパスにコピーする。（※ユーザの内部IDが変わっているので、コピーの前に、新環境のユーザにフルコントロールの権限を付与しておく必要がある）
   • *:\Users\(username)\AppData\Roaming （大抵のアプリのユーザ設定はここだけ移行すれば引き継げる）
   • *:\Users\(username)\Documents （ComicStudioとか、ここに設定を保存してる物がある）
   • *:\Users\(username)\Music （iTunesのライブラリはここにある）
   • *:\Users\(username)\.* （GIMPなど、UNIX・Linux系由来のアプリはホーム直下の.で始まる名前のフォルダに設定を保存しがち）
   • *:\ProgramData （作りの古いアプリがここに設定を保存している場合があるのと、比較的最近のアプリもユーザに依らない設定はここに保存してるっぽい）
   • *:\Program Files (x86)\JustSystems\ATOK （ATOKのバージョンに依らない広辞苑とかの辞書はここにある）
   • *:\Windows\Fonts （フォント。ファイルを全選択して新環境のC:\Windows\Fontsにコピーしようとすれば、フォントファイルはフォントとしてインストールして、そうでないファイルは警告が出るという感じでフォントだけ引き継げる）
3. レジストリハイブをロードする方法を使って旧環境のレジストリの内容を以下の要領で読み込む。
   • *:\Users\(username)\NTUSER.DAT→HKEY_USERS\old-(username)にロード
   • *:\Windows\system32\config\SOFTWARE→HKEY_USERS\old-softwareにロード
4. 以下の位置にあるレジストリキーの中から、新環境に引き継ぎたいアプリの設定をエクスポートする。
   • HKEY_USERS\old-(username)\Software
   • HKEY_USERS\old-software
   • HKEY_USERS\old-software\WOW6432Node
5. エクスポートした.regファイルをテキストエディタで開き、以下のように置換する。
   • HKEY_USERS\old-(username)→HKEY_CURRENT_USER
   • HKEY_USERS\old-software→HKEY_LOCAL_MACHINE\Software
6. .regファイルをダブルクリックしてインポートする。

他にもエロゲーとかC:\Program Files (x86)以下やC:\以下にデータを保存するお行儀の悪いアプリがあるので、それらも適宜いい感じに移行してあげるとよいでしょう。僕はこの方法で少なくとも以下のアプリの設定を引き継げています。

• Mozilla Firefox
• Mozilla Thunderbird
• ComicStudio 4.0 Pro
• Adobe Illustrator CS4
• GIMP
• ATOK2017
• 秀丸エディタ
• iTunes（ライブラリ）
• VirtualBox（仮想マシンのイメージの置き場所を変えたため、リンク作成シェル拡張でシンボリックリンクを作ってパスを合わせるようにちまちま調整する必要があったのと、UEFIの設定を変えて仮想化支援機能を有効化する必要があった）

こういう引き継ぎ方をしやすいように、ここ2〜3世代くらいは以下のことに普段から気をつけてる。

• アプリのインストール先は基本的に変えない。
• データの置き場所も変えない。ユーザーのホーム以下か、C:\Users\Public 以下に置く。
• ユーティリティの類はなるべく使わない。OSの環境自体のカスタマイズはなるべくしない。

中学高校の頃に中二病こじらせてアプリのインストール先（起動ドライブは空きを多くとりたい→なら別のドライブにインストール！）やらデータの置き場所（起動ドライブは空きを以下略）やら壁紙やらテーマやらカスタマイズしすぎた結果、移行の度にやれあれができなくなっただのこの設定がなくなっただのとイライラする羽目になったので、「できない事をしようとしない。靴に足を合わせる。自分でこうしたいと思って変えたものは、再現できないとストレスがものすごいが、唯々諾々と受け入れて慣れただけのものは、思い入れが無いから楽に忘れられる。」というデフォルト設定順応派にすっかり改宗してしまったのです。

でもそもそもの話、こういう乱暴な移行の仕方を真似するのはおすすめしません。非正規の方法を取って起こるあらゆるトラブルよりも、正規の手順でアプリの設定やデータをちまちま引き継ぐ手間の方が死ぬほど辛い、起こるトラブルは気合いで解決する、という本末転倒な事に陥っても構わない僕のような近視眼的な人以外は、真面目に普通に設定を移行した方がいいと思います。僕も、再設定が面倒でなかった以下の物は普通に入れ直して設定もやり直しました。

• Git for Windows
• TortoiseGit
• Dropbox

（後日談：ここで移行した先のWindows 10機が死んだのでさらに新しいPCに移行した話。ここに書いた話の発展編。）