たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
自宅のPCではなく業務で使ってる方のWindows 10で、いつの頃からか、タスクバーからの検索(虫眼鏡のボタンをクリックするとパネルが出てくるやつ)やカレンダー(タスクトレイの時計をクリックするとパネルが出てくるやつ)が動作しなくなっていました。この度、現象の回避方法が見つかったので、参考に顛末を記録しておきます。
状況としては、
という具合で、雰囲気的には、何かのプロセスが起動したもののすぐに落ちてしまっているような印象を受けます。
検索はもっぱらregedit.exeなどを起動するために使っていたので、「ファイル名を指定して起動」で代替が効いたのと、カレンダーはThunderbirdのカレンダーで代替できていたのとで、致命的ではなかったため、直し方の見当が付かなかったのもあってそのまま放置していたのですが、今日になって、「Microsoft Store」でアプリ名を入力して検索すると、検索結果が表示される前にアプリが落ちてしまうようになっていたことに気付きました。これはさすがに代替が効かなくてまずいので、いいかげん本腰を入れて直し方を探してみました。
ただ、現象面から思いつく「Windows 検索 動作しない」みたいなキーワードで検索してみても、まるで的外れな情報しか見つかりません。なのでもうちょっと当たりに近付けそうな情報を求めて、現象発生時のエラー情報を調べてみました。
先日導入した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に揃った状態になった。ディスプレイ側で等倍表示されるようになり、文字も絵もクッキリ見える状態になった。これでようやくまともに使える。
他に同じ現象で困った人がこの情報に辿り着けるように、記録を残しておく。
次の号に掲載される予定のシス管系女子の原稿を制作中に、突然画面がグリッチしたかと思ったら無反応になり、電源長押しで再起動を試みても画面は真っ暗のまま、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年保証も付けた。
移行は概ね、過去にやった以下のそれぞれの作業の合わせ技で行った。
最新の情報へのアップデートも兼ねて、改めて書き起こしておく。
業務で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をもう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 PCをメイン環境として使い始めようとしていて、セットアップするのになんやかや詰まったので記録を残しておきます。
何も考えずにMicrosoftアカウントで使い始めると、例えば shimoda.hiroshi
みたいなMicrosoftアカウントだったら C:\Users\shimo
みたいな適当にぶった切られた名前でホームディレクトリができてしまう。C:\Users\piro
みたいに任意の名前のホームディレクトリにするためには、以下の手順を踏まないといけない。
C:\Users\shimo
とか)を管理者権限で削除する。コンピューター名はWindowsの通常使用だと意識する事はあまりなくて、LAN内で参照する時に使う程度だけど、WSLでホスト名として常時目にする事になる。これがランダムっぽい名前だと結構いらつくので、最初に変えておく。(以後はWSLでも勝手にこの情報を参照してくれる)
WSLを有効化してストアからUbuntuをインストールした後にやること。
"source": "Windows.Terminal.Wsl"
をコメントアウトして、代わりに "commandline": "wsl.exe ~ -d Ubuntu"
と書いておく。Windowsのファイルシステム上でWSLのファイルのパーミッションを保存できるようにするために、 sudo vim /etc/wsl.conf
で設定ファイルを開いて以下の内容を保存する。
[automount]
options = "metadata,umask=22,fmask=111"
マウントした既存のファイルや新たに作成したファイルが全部実行権限付きで認識されるとGitを使うのに不便なので、maskを指定して実行権限がつかないようにしておく。
LxssManager
を探し、再起動する。これで、上記の設定が反映される。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のフォルダにシンボリックリンクを作っておく。シェルでよく使う基本の設定をする。
~/.bashrc
に以下の内容を加えて、コマンド履歴の逆方向検索に Ctrl-S を使えるようにする。
stty stop undef
stty start undef
~/.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
~/.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'
SSHの秘密鍵を設置して、他のホストにSSHで接続できるようにする。 基本方針として、WSLのsshクライアントから直接秘密鍵を触らずに、Windows 10に最初から入ってるOpenSSHのssh-agentに鍵を読み込ませて、必ずrupor-github/wsl-ssh-agent経由で利用することにする。
C:\Program Files (x86)\wsl-ssh-agent\
あたりに置く。wsl-ssh-agent-gui.exe
へのショートカットを C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
(全ユーザー向けの場合)か、%AppData%\Microsoft\Windows\Start Menu\Programs\Startup
(自分のみの場合。Win-Rで shell:startup
を実行して開かれるスタートアップフォルダ)に作る。-socket "%temp%\ssh-agent.sock"
と起動オプションを付け足す。これで、毎回起動時にssh-agentのためのソケットが作られるようになる。wsl-ssh-agent-gui.exe
が起動していないので、ショートカットをダブルクリックして起動する。~/.bashrc
に export SSH_AUTH_SOCK=/mnt/c/Users/$USER/AppData/Local/Temp/ssh-agent.sock
という行を足す。これで、WSLの環境に入ると自動的にWindows側のssh-agentと繋がるようになる。source ~/.bashrc
を実行して設定を反映する。~/.ssh
(秘密鍵、公開鍵、設定ファイル)を持ってくる。chmod 700 ~/.ssh
で、ディレクトリのパーミッションを他のユーザーから参照不可能なようにする。ssh-add ~/.ssh/(秘密鍵)
を実行し、秘密鍵を ssh-agent に読み込ませる。(以下は、Windows 10のOpenSSHを使うようになるまで使ってた、PuTTYのPageantに鍵を読み込ませて、必ずweasel-pageant経由で利用する場合の手順。歴史的資料として残す。
C:\Users\username\.ssh
(/mnt/c/Users/username/.ssh
)を作成し、旧環境からファイルをコピーする。puttygen.exe
で秘密鍵のid_rsa
をインポートして、PuTTY形式の秘密鍵 id_rsa.ppk
として保存する。shell:startup
を実行してスタートアップフォルダを開き、pageant.exe
のショートカットを作成する。pageant.exe
を起動して、先の id_rsa.ppk
を読み込ませる。C:\Program Files (x86)\wsl-pageant
に置く。chmod +x /mnt/c/Program\ Files\ \(x86\)/weasel-pageant/weasel-pageant /mnt/c/Program\ Files\ \(x86\)/weasel-pageant/helper.exe
で明示的に実行権限を設定する。echo 'eval $(/mnt/c/Program\ Files\ \(x86\)/weasel-pageant/weasel-pageant -r)' >> ~/.bashrc
で、weasel-pageantを自動起動するようにする。(weasel-pageantにどのようなオプションを設定するべきかについては、必ず最新の解説を参照すること。)mkdir ~/.ssh; chmod 700 ~/.ssh
で、設定ファイル等の置き場所を用意する。
ln -s /mnt/c/Users/username/.ssh ~/.ssh
でシンボリックリンクとして作成してしまうと、次項の設定をしてもSSH接続を受け付けられなくなってしまう(~/.ssh
のパーミッションを適切に設定できなくなる)ので、必ずここは普通のディレクトリとして作成しておく。)
openssh-server
が最初から入っているので、後は必要な設定をするだけで使える。
/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
にコピーする。chmod 600 ~/.ssh/authorized_keys
として、パーミッションを適切に設定する。sudo service ssh start
してsshdを起動する。ssh localhost
でログインできることを確認する。sudo service ssh stop
してsshdを停止する。(以後は、必要な時にだけ起動する)mkdir -p ~/local/bin
で、ユーザー固有のバイナリ置き場を用意する。echo 'export PATH="~/local/bin:$PATH"' >> ~/.bashrc
してパスを通しておく。peco_linux_amd64.tar.gz
を使った)。unar peco_linux_amd64.tar.gz
でファイルを展開する。peco
を ~/local/bin/
に移動し、chmod +x ~/local/bin/peck
で実行権限を設定する。echo 'source ~/peco-commands.sh' >> ~/.bashrc
で自動的に読み込むように設定する。bash-git-promptを使うようにする。
cd ~/
して git clone https://github.com/magicmonty/bash-git-prompt.git ~/.bash-git-prompt --depth=1
で必要なファイルをローカルに用意する。以下の内容を ~/.bashrc
に追加して、機能を有効化する。
GIT_PROMPT_ONLY_IN_REPO=1
source ~/.bash-git-prompt/gitprompt.sh
GIT_PROMPT_THEME=Single_line_Ubuntu
時刻表示の部分が余計なので、以下のように編集する。
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}# "
sudo update-alternatives --config editor
でデフォルトのエディタをvim.basic
に切り替えておく。ここまででWSL上のrsyncが使えるようになっているので、旧環境から rsync -a xxx.xxx.xxx.xxx:~/path/to/directory/ ~/Public/
みたいにしてパーミッションの情報込みでファイルを持ってこれる。
(シンボリックリンクまで勝手に辿らせると大変なことになりかねないので、シンボリックリンクの先は個別に辿るのがよい気がする。)
今回は移行元がハードウェア上にインストールされたUbuntuだったけれども、移行元がWindows 10マシンの場合も上記の要領であらかじめsshdを起動しておけば、同様にrsyncでファイルを持ってこれる。
最近のMozillaBuildとmozilla-centralはよくできてて、だいたい一発で環境ができあがる。以下、前半は会社のブログに書いた手順の通り。
c:\mozilla-build
にインストールする。C:\mozilla-source
の位置にフォルダを作る。Firefoxのソースコード一式はこの配下に置く事になる。c:\mozilla-build\start-shell.bat
を実行して、MozillaBuildのシェル(Bash)を起動する。echo 'export PATH=$PATH:~/.cargo/bin' >> ~/.bash_profile
を実行して、MozillaBuildのシェルを一旦終了し、c:\mozilla-build\start-shell.bat
で起動し直す。cd /c/mozilla-source
して、 hg clone https://hg.mozilla.org/mozilla-central
でmozilla-centralをcloneする。cd mozilla-central
してリポジトリに入り、./mach bootstrap
を実行する。これにより、Visual StudioやRustなどのビルドに必要なソフトウェア群が自動インストールされる。./mach build
して、ビルドできる事を確認する。./mach run
して、ビルドしたFirefoxを起動できる事を確認する。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
Mozillaのサーバーに認証を求める時のユーザー名指定を省略できるようにするために、~/.ssh/config
に以下を追記する。
Host hg.mozilla.org
User yuki@clear-code.com
ssh hg.mozilla.org
してみて、認証できるかを確認する。(シェルには入れないでそのまま接続が切れるが、それでOK。)
tryserverを使うために、~/.hgrc
に以下を追記する。
[paths]
try = ssh://hg.mozilla.org/try
./mach try empty
で空のリクエストを送れるかどうか確認する。
hg grepfile
でワーキングコピーのファイルを対象に検索できるようにするために、hg-grepfileをインストールする。最近までWindows 10標準で仮想デスクトップ機能があるということを把握してませんでした。今回調べて初めて知りました。
Ubuntuではメインの作業画面とThunderbirdを使う(メールを読み書きする)画面とを分けていて、画面の端にカーソルでちょいっと触れると仮想デスクトップ切り替えの画面が出てくるようになってたんだけど、そういう事をできるようにするにはユーティリティが必要。タスクビューの切り替え画面を出すこと自体は、Windowsキー+Tabでできるので、任意のジェスチャでこのキー操作を代替すればよい。
マウスジェスチャーソフトの「MouseGestureL.ahk」でマウスホイールにWindows10の「タスクビュー」を割り当てる | PC ウェブログという記事を参考に、以下のようにした。
C:\Program Files
配下あたりに適当に置く。Setup.vbs
を実行する。screen-edge
CRB_
(画面右下角に接触)CLB_
(画面左下角に接触)screen-edge
以外すべて削除する。screen-edge
のアクションスクリプトを以下の通りに書く。
;キー操作を発生させる
Send, #{TAB down}{TAB up}
「その他」タブに切り替えて、「スタートアップに登録」で自動起動するようにする。
これで、画面の端に触れるだけで仮想デスクトップを切り替えられるようになる。
2020年5月1日追記。初期設定ではRB
(右ボタン)で始まるジェスチャがいくつか定義されてるんだけど、これがあると、Windows全体で右ボタンの動作に影響が及んでしまう。具体的には、window.addEventListener('mousedown', ...)
みたいな方法でマウスのボタンが押し下げられたことを検知しようとしても、右ボタンだけmousedownが取れなくなる(ボタンを放したときに初めてmousedownが発火するようになる)。自分はscreen-edge
をトリガーにした操作しか使わないので、RB
で始まるジェスチャは全部削除した。
Ubuntuではテキストを選択すると通常のクリップボードとは別の専用のバッファにテキストが格納されてミドルクリックで貼り付けるという動作になってた(これ自体はXの機能とのこと)んだけど、GNOME Terminal(端末)でコピー&ペーストのキーバインドが他のGUIアプリと違っていたこともあって自分でも驚くくらいに意外と多用していて、Windows環境でWSLを使っているとそのときの感覚が抜けなくてつい戸惑ってしまう。
代わりになりそうなものを探してみたらいくつか情報が見つかったんだけど、どれも今使うにはちょっと厳しい感じだった。
もうちょっと悪あがきしてみようと思って「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でクリップボードへのコピーを試行するのが元凶なので、それ無しで選択範囲のテキストを取得できる方法があればいいんだけど、それはエディットコントロールに対してのみ動作する関数しか用意されてなくて、オフィシャルのサンプルの時点で「標準のエディットコントロール以外でも使えるのはCtrl-Cを使う方法だ」と紹介されてるレベルだったので、AutoHotKeyの制限事項としてどうにもならないというのが結論のようです。残念。
これ機能として欲しくなることが無くてまず誤爆で困るばかりなんですけど?
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
にDisallowShaking
というDWORDの値を作ってデータを1
にすると、この機能が無効化されるそうです。
そんなに頻繁にやるわけじゃなくて、数年に1回やる程度なので、
という風に思ってます。
毎月やるとか、まとめて10台くらいやるとか、そういう前提が出てきたら重い腰を上げてPowerShell覚えるかもしれないですね。
まだ後から書き足しそう。
(後日談:これとは別のPCについて行った、Bash on Ubuntu on WindowsからストアアプリのUbuntuへの環境引き継ぎの話。ここに書いた話を一部参照した。)
今や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で表示される数字からの計算が面倒だったので、フォームを埋めるだけで計算してくれるような物を用意してみました。
手厚いサポートの恩恵をほとんど受けてないのでSoftbank MobileをやめてMVNOにしよう、ということで数ヶ月前から準備を進めてて、まずSIMロックのかかってない端末に機種変更した。そこそこ性能が良くてモバイルSuicaが使えること、を条件に検討した結果AQUOSブランドのSH-M03にした(既にこの次のモデルが出てたけど、次のモデルはコストダウンの方に舵を切った結果スペックが落ちてたので……)。
……んだけど、これが本体の内蔵ストレージがめっちゃ少なくて、この前に使ってた203SHは32GBあったのにこれは16GBだからアプリの自動更新が何度か降ってきたらもうそれだけでパンパン。microSDを外部ストレージとして使うようにはもちろんしてたんだけど、それでも全然追っつかない。Kindleのようにデータを自分の領域に保存するアプリはそもそも外部ストレージがいくらあっても使っちゃくれないし。
検索したら、Android 6以降だとSDカードを内部ストレージの追加領域にできるみたいな話が出てきたのでやってみた。結論としては、今まで外部ストレージだったmicroSDがそっくりそのまま内部ストレージになる感じになった。
以下、やったこと。
外部ストレージとしてしか認識されないmicroSDを強制的に内部ストレージにする。(前の手順で内部ストレージとしてフォーマットできてるなら、多分この手順は不要)
Path
にC:\Users\(ユーザー名)\AppData\Local\Android\Sdk\platform-tools
を加える。adb shell
を実行してAndroid端末に接続する。
USBデバッグ接続を許可するかどうかの確認がAndroid端末の画面に出るので、許可する。
error: more than one device/emulator
というエラーメッセージが出て接続できない(自分の環境ではCintiq Companion Hybridが繋がっててこれにハマった)ので、関係無いAndroid端末は外しておく。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
がそれにあたる。
sm partition (microSDの識別子) private
を実行する。
shell@SH-M03:/ $ sm partition disk:179,64 private
shell@SH-M03:/ $
しばらく待たされて処理が完了する。
private
と指定するとmicroSDの領域全体が内部ストレージとして使えるようになるんだけど、文献によっては「全体を内部ストレージにするとおかしくなるのでmixed 50
のように指定すること」のように案内してたりする。が、自分の環境で試した限りではmixed
を指定しても期待したような効果を得られず、むしろprivate
にした方が想定通りの結果を得られた。この状態でファイルマネージャの類のアプリを起動してみると、以前は内部ストレージとSDカード(外部ストレージ)の2つが見えていたのが、内部ストレージが見えなくなってSDカードだけ表示されるようになっていた。 また、Android端末をPCに接続しても、microSDの分の領域だけが見えるようになっていた。
最初に退避しておいたmicroSDの中身を書き戻すというかマージすれば、移行作業は完了。逆に、microSDを切り離して元の状態に戻したい時は、設定→ストレージとUSB で内部ストレージの項目をタップして、右上のメニューボタンをタップして出てくるメニューから「データを移行」を選択すればいいんだと思う。やる前にmicroSDの中に保存されてるデータを消して内部ストレージに収まる状態にしておかないと、多分、失敗するか警告されて処理を実行できないんじゃないかなあ。
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の方を見に行ってしまうのが原因だったようだ。
そういえばGroonga関係のドキュメントを書くのにSphinxを使わないといけなくて、Sphinxが要求するPythonのバージョンがシステムのPythonのバージョンより新しかったからpyenvで乗り切ったような記憶がある。そのせいか。
PythonのことはさっぱりなのでどうやればpyenvとシステムのPythonを共存できるのかやり方を誰か教えて!と社内で聞いたら、デフォルトではシステムにインストールされたバージョンのPythonを使うようにして、特定のディレクトリ配下でだけ必要なバージョンを使うようにすれば良いと教えて貰えた
$ pyenv global system
$ duplicity --version
duplicity 0.7.06
でも同時に、Pythonコミュニティ的にはpyenvを使って欲しくない流れになっているみたいな事も聞いたので、自分の中でのPython触りたくない度合いがまた増してしまった。
TortoiseGitのステータス表示が出なくてなんでや、と思って検索したらStack Overflowのスレとか日本語の解説とかがヒットした。要するに HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers
以下のキーの文字コード順の並びで上位11個に入ってないやつは反映されないと……んでDropboxもTortoiseGitも登録しすぎと……そのうえOneDriveとかも入ってきてもうすっちゃかめっちゃかや。そういやTwitterのタイムラインでそんな話題が流れてたのを見た記憶がある。
とりあえずどっちが致命的かというとTortoiseGitの方なので、そっちが上に来るようにキー名を編集してみたところ、無事アイコンオーバーレイが有効になった。それにしても上位の取り合いのために名前の前にスペースを入れるとか、今は本当に2017年なんですか?って気分だ。