PowerShellの.bash_historyはどこにある?
PowerShellには .bash_history みたいな記録ファイルがないから不便だなと思っていたら、ちゃんとあるじゃないですか。
PowerShell Commands History | Windows OS Hub
& (Get-PSReadlineOption).HistorySavePath
と入力すると、コマンドライン履歴を記録したファイルを開くことができる。
よく読むと、このPSReadlineってやつはWindows10から有効になった機能っぽい。
同モジュールは他にもショートカットキーの設定に対応してて、例えば
Get-PSReadlineKeyHandler -Bound
とやると現在有効になっているショートカットキーの一覧が得られる。
Windows10なのにmklinkがない?
PowerShellからGet-Command mklink
とかやってるのに見つからない。
よく調べたら mklink って内部コマンドじゃないか。
知ってるとは思うけど軽く説明すると、DOSコマンドには2種類ある。1つは外部コマンドで、“○○.exe”とか“○○.com”とかいうファイルとして存在している。もう1つは内部コマンドで、こいつはシェルの内部に実装されている。
コマンドプロンプトもこの伝統を引き継いていて、大抵の外部コマンドは C:\Windows\System32 などにファイルとして存在している。そうして、こういう外部コマンドはPowerShellからも実行できる。一方で、内部コマンドはコマンドプロンプトの方に実装されているので、実行するにはcmdを起動させる必要がある。
cmd /c mklink /?
その他、assoc
とかftype
なども内部コマンドだから、PowerShellからは直接使えない。一方で、pause
とかmore
みたいなコマンドはPowerShellの方にも関数として機能が再現されている。
Ubuntuのシェルとか使ってて入力をミスると、「もしかしてこれのことか?」とか「それならこのパッケージに入ってる」とか自動で言ってくるけど、PowerShellにもそんな機能があったらいいよねってふと思った。
小生の関連付けの方針
Windowsの関連付けってどうやるのが正解なんだろう? なんかバージョンが進むにつれ、どんどん仕組みが複雑化してるよな。最初はassoc
とftype
だけの単純な構造だったのにね。
自分が知っている限り、関連付けに関連があるキーは以下の4つ。
- HKEY_CLASSES_ROOT
- こいつは以下の2つのキーの合成
- HKCU\Software\Classes
- HKLM\Software\Classes
- こいつは以下の2つのキーの合成
- HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts
- HKCU\SOFTWARE\Microsoft\Windows\Roaming\OpenWith\FileExts
( HKCU := HKEY_CURRENT_USER, HKLM := HKEY_LOCAL_MACHINE )
で、色々調べたんだけど、以下の方法に落ち着いた。
① まともそうなアプリは、その関連付け機能を利用する。
② HKCU\Software\Classesの方だけいじる。
HKLMの必要な部分だけをHKCU側で上書きさせるようにする。
例えば edit\command だけ上書きするとかできる。
③ 関連付けの完全自動化は諦める。
エクスプローラーはユーザーに必ず一度はお伺いを立てるような仕組みになってます。
レジストリを書き換えて、はい完了、ということにはできない。
HTML5の<br>と<br />
HTML5の解説本にどっちでもいいと書いてあった覚えがあるけど、巷のサイトでは混乱しているので仕様書に当たる。結果、「スラッシュは入れてもいいけど何の効果もないよ」という文を発見。よかった、小生の記憶は間違ってなかった。
if the element is one of the void elements, (省略) then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements,
https://www.w3.org/TR/html51/syntax.html#ref-for-void-elements-6
ちなみに、終了タグがないのはこいつら(void elements)だ。imgとかhrとかは常識的にわかるけど、inputもない。
次XHTML。しかし、XHTMLなんぞは失敗した過去の遺物であり、仕様書を調べるのが面倒くさいので英語版ウィキペディアから。
Note that any of these is acceptable in XHTML:
https://en.wikipedia.org/wiki/XHTML#Common_errors<br></br>
,<br/>
, and<br />
. Older HTML-only browsers interpreting it as HTML will generally accept<br>
and<br />
.
<br></br>
<br/>
<br />
以上の書き方はみんな正しい。でも古いブラウザ(当時)は <br/>
を理解できないことがある。
TwitterとEvernoteの違和感
TwitterとEvernoteはもうだめかもしれないなって思うことがある。
別に特段の理由があるわけではないのだが、なんか使ってて「違和感」を覚えるのだ。
具体的にダメな点なら指摘できる。例えば、Twitterなら検索機能が何年も使いにくいままだとか、不良ユーザーが野放しになってるとか。Evernoteならクライアントのバグが何年も放置されてるとか、ウェブ版の使い勝手が悪いとか。
でも、これらが直接的な原因なのではない。何となく使ってて「いやー」な感じがするのだ。運営にやる気がないのではないか、開発者がこっちを向いてないのではないか、そう思うことがよくある。もし小生が株をやってたら絶対に売ってると思う。
まぁ、終わった終わったと言われ続けた2chにもなんだかんだで続いているし、潰れることはないだろうけど。それに、今現在、使っているのだから潰れてもらったら困る。ただ将来的に何か別のものに乗り換えるのではないか、そんな予感がした。
ごく初歩的な方法でPythonからPowerShellにデータ渡す
Channel 9 というサイトを見つけたので、いくつか動画を見てみたのだが、Windowsの最新テクノロジーに関する動画もあれば、こんな身近な話題もある。
上での動画で説明しているのは基本的なことで、
例えばPowerShellのスクリプトにPythonのコードを埋め込むときはヒアドキュメントにする。
py -c @' print('hello world') print('日本語') '@
Pythonから構造のあるデータを返すときはJSONにして返す。
# 一旦aに受ける $a = py -c @' import json data = [ {'name' : 'nextugi', 'job' : 'neet'}, {'name' : 'yamada', 'height' : 170}, ] print(json.dumps(data)) '@ | ConvertFrom-Json # nameを取り出す $a.name
こんな感じ。別にPythonに限った話ではなく、他のスクリプト言語やコンソールコマンドでも同じだね。
VisualStudioの件もあるし、そのうちPowerShellの中にPythonを組み込む方法が出てくるかもね。
Python3.6からWinでもファイルステムがUTF-8化した
Python3.6からWindowsでもstdoutなどがUTF-8化してた。sys.getfilesystemencoding() とか sys.stdout.encoding とかも UTF-8 を返す。まるで OS が UTF-8 化したかのようだな。
どういうことかというと、文字列をコンソールに出力したとする。そうすると、まずPythonの文字列をUTF-8に変換する。それからOSの手前当たりで UTF-16LE に変換する。それから Windows API の *W系関数を使って文字列を画面に表示する。こんな感じ。
これまでsys.stdout.bufferにバイナリを入力できて、とても見通しがよかったのだが。う~ん、これでいいのかなあ。確かにWindows自体は全てがUTF-16化されてるわけだし、*W系の関数を使うべきだけど。それならそれでPythonの方も UTF-16 にしておくべきでは? まぁ、今回の件に関するPEPとかよく読んでないから、この不満は見当違いかもしれないけど。
あ、そうだ、 locale.getpreferredencoding() は相変わらず cp932 なので、open関数で encoding を省略すると、旧来の文字コードになるのは一緒です。はい。
それにしてもWindowsがコードページの概念から開放されるのはいつになるんでしょう。10年後ぐらい? 旧式のWindows APIもなくなると言われてもう15年くらいたつけど依然として残ってるし、Component Object Model も滅びずにロストテクノロジー化してるわけで、そう考えるとWindowsは新しいようで結構古い。
最近、Windows Subsystem for Linux をちょっと触ってみたんですけど、結構デキがよろしいように見える。10年後にはWindowsもMacと同じようにUNIX化してたりしてね。