Windows10なのにmklinkがない?

PowerShellからGet-Command mklinkとかやってるのに見つからない。

よく調べたら mklink って内部コマンドじゃないか。

知ってるとは思うけど軽く説明すると、DOSコマンドには2種類ある。1つは外部コマンドで、“○○.exe”とか“○○.com”とかいうファイルとして存在している。もう1つは内部コマンドで、こいつはシェルの内部に実装されている。

コマンドプロンプトもこの伝統を引き継いていて、大抵の外部コマンドは C:\Windows\System32 などにファイルとして存在している。そうして、こういう外部コマンドはPowerShellからも実行できる。一方で、内部コマンドはコマンドプロンプトの方に実装されているので、実行するにはcmdを起動させる必要がある。

cmd /c mklink /?

f:id:nextugi:20170607180730p:plain

その他、assocとかftypeなども内部コマンドだから、PowerShellからは直接使えない。一方で、pauseとかmoreみたいなコマンドはPowerShellの方にも関数として機能が再現されている。

Ubuntuのシェルとか使ってて入力をミスると、「もしかしてこれのことか?」とか「それならこのパッケージに入ってる」とか自動で言ってくるけど、PowerShellにもそんな機能があったらいいよねってふと思った。

小生の関連付けの方針

Windowsの関連付けってどうやるのが正解なんだろう? なんかバージョンが進むにつれ、どんどん仕組みが複雑化してるよな。最初はassocftypeだけの単純な構造だったのにね。

自分が知っている限り、関連付けに関連があるキーは以下の4つ。

  • HKEY_CLASSES_ROOT
    • こいつは以下の2つのキーの合成
      • HKCU\Software\Classes
      • HKLM\Software\Classes
  • 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: <br></br>, <br/>, and <br />. Older HTML-only browsers interpreting it as HTML will generally accept <br> and <br />.

https://en.wikipedia.org/wiki/XHTML#Common_errors
  • <br></br>
  • <br/>
  • <br />

以上の書き方はみんな正しい。でも古いブラウザ(当時)は <br/> を理解できないことがある。

結論

  • HTML5なら<br>
    • ただし<br />と書いてもよい
  • XHTMLなら<br/>
    • ただし前方互換を意識して<br />にしてもよい

TwitterとEvernoteの違和感

TwitterEvernoteはもうだめかもしれないなって思うことがある。

別に特段の理由があるわけではないのだが、なんか使ってて「違和感」を覚えるのだ。

具体的にダメな点なら指摘できる。例えば、Twitterなら検索機能が何年も使いにくいままだとか、不良ユーザーが野放しになってるとか。Evernoteならクライアントのバグが何年も放置されてるとか、ウェブ版の使い勝手が悪いとか。

でも、これらが直接的な原因なのではない。何となく使ってて「いやー」な感じがするのだ。運営にやる気がないのではないか、開発者がこっちを向いてないのではないか、そう思うことがよくある。もし小生が株をやってたら絶対に売ってると思う。

まぁ、終わった終わったと言われ続けた2chにもなんだかんだで続いているし、潰れることはないだろうけど。それに、今現在、使っているのだから潰れてもらったら困る。ただ将来的に何か別のものに乗り換えるのではないか、そんな予感がした。

ごく初歩的な方法でPythonからPowerShellにデータ渡す

Channel 9 というサイトを見つけたので、いくつか動画を見てみたのだが、Windowsの最新テクノロジーに関する動画もあれば、こんな身近な話題もある。

channel9.msdn.com

上での動画で説明しているのは基本的なことで、
例えば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年後にはWindowsMacと同じようにUNIX化してたりしてね。

ReadyBoostが意外と効く

手元の余ってるUSBメモリーをReadyBoost用にしてみたら意外と効いた。特にOSの起動にかかる時間が4割くらい減ったような気がする。

このパソコン、CPUは4コアで計算能力は足りてるのだが、HDDが古い上にSATA2.0なので、データの読み込み速度が足を引っ張ってるよう見える。タスクマネージャーでもHDDは起動直後100%になってるし。そこでReadyBoostを試してみたところいい感じ。古いPCを使ってるのなら試してみることをすすめる。

ちなみに、USBメモリーは手元に余ってるやつの中からCheck Flashで速度を測ってから選んだのだが、種類によってかなり速度差がある。古くても早かったり、新しくても遅かったりすることもあった。