本セッションは「オープンソースになりクロスプラットフォーム化したPowerShellを普段LinuxやMacを使う人やPowerShellになじみのない人にも学んでもらおう。」という趣旨で行いました。
イベントがオープンソースカンファレンスであったため、クロスプラットフォームよりはオープンソースという単語を表に出した方が通りが良いだろうと思いこの様なタイトルにしたのですが、確かに配慮に欠ける部分がありました。
結果論ではありますが、「クロスプラットフォームになったPowerShellを学ぼう(Linux/Macユーザー向けのPowerShell入門)」といったタイトルの方が正確だったと思います。

本セッションに参加していただいた方の中に上記の様なソースコードに対する解説やソースコードリーディングを期待した方がいたら申し訳ありませんでした。

当初の趣旨とは外れているのでセッションでは触れませんでしたが、実際にソースコードを読んで挙動を確かめるというのはPowerShellを学ぶ上でとても重要です。

本ブログでもいくつかのエントリでソースコードから実際の挙動を確かめるといった事をしています*1ので、セッションで触れなかった代わりにこちらで紹介させて頂きます。

blog.shibata.tech

*1:まだまだソースコードの読み込みが甘くレベルが低いので精進します...

2017-06-16

次期Nano Server(Version 1709)のPowerShellについて

NanoServer PowerShell

元ネタはこちら。

docs.microsoft.com

blogs.technet.microsoft.com

次期Windows ServerおよびSemi-annual Channelについては山市さんがサクッとまとめてくれています。

yamanxworld.blogspot.jp

次期Nano Serverはコンテナ専用になる話

今年の9月リリース予定の次期Nano Server(Version 1709)は元ネタに

However, starting with the new feature release of Windows Server, version 1709, Nano Server will be available only as a container base OS image.

とある様にコンテナ専用となり、Docker Hubからのみイメージの取得および更新ができる様になるそうです。

また、サーバーの用途を.NET Coreアプリケーションをホストすることに最適化し、コンテナのサイズもこれまでよりさらに減らすそうです。*1

次期Nano ServerのPowerShellについて

で、ここからが本題で、

Windows PowerShell, .NET Core, and WMI are no longer included by default, but you can run them in a separate container.

とのことで、次期Nano ServerではデフォルトでWMIやPowerShellが含まれないそうです。
by defaultとあるので追加でインストールすることはできるだろうと予想されますが、まだ確定的な情報はありません。

個人的な予想として、明確な根拠があるわけではないのですが、「今開発中のPowerShell 6.0を追加でインストールしてね。」という流れにしたいのかなと思っています。

デフォルトでWMIやPowerShellがインストールされないことに関しては、Nano Severがコンテナ専用になる以上妥当だと思います。

と言ってもPowerShellがいらない子だと言うわけではなく、コンテナの運用は基本的に作り直し・使い捨てのDisposableなモデルになるかと思います。このモデルおいては重厚な管理フレームワークであるWMIやPowerShellは不要なケースの方が多いでしょう。
単純にコンテナ内部にPowerShellが必須ではないというだけです。

ただ、PowerShellが無いことでコンテナイメージの作成はどうすべきなのかという疑問はあります。
まさかコマンドプロンプトですべてを賄うというわけにはいかないでしょうし、Nano Server専用のツールセットといったものが今後出たりするんでしょうかね？

このあたりは今後の情報を期待して追いかけていきたい感じです。

*1:サイズに関してはWindows Updateでモリモリ増えていくザマを見てどこがNanoなのかと思うことしきりだったのでうれしいですね…

2017-05-26

Windows 10 Creators UpdateでSQL*Plusを使うと日本語が文字化けする件について

Windows Oracle PowerShell

【2017/06/05追記】

本現象は先日出た累積更新(KB4020102)で解消されています。

【追記ここまで】

きっかけは @masaru_b_cl さんのこのツイートから。

SQL*Plusが出力する日本語が、Windows 10の新コンソールだと文字化けする……なんだこれ？
— 白い高野さん (@masaru_b_cl) 2017年5月26日

手元の環境でこの現象が再現して回避策を見つけることができたのでここにメモっておきます。

環境について

今回、以下の環境で文字化けが起きることを確認しました。

クライアント
- 64Bit版 Windows 10 Pro / Creators Update(1703)
  - 今月の更新まで適用済み
- Oracle Instant Client for Microsoft Windows (x64) 12.2.0.1.0
  - Instant Client Package - Basic
  - Instant Client Package - SQL*Plus
    をインストールしてSQL*Plusを実行可能に設定
- NLS_LANG = Japanese_Japan.JA16SJISTILDE
サーバー
- Windows Server 2012 R2
- Oracle Database Enterprise Edition 12.1.0.2.0
- データベースのキャラクタセット = JA16SJISTILDE

テスト用にTEST_TABLEテーブルを用意し、投入したデータは以下の様な感じです。

f:id:stknohg:20170526215041p:plain

現象の確認

とりあえずデータベースに接続して以下のクエリを流してみます。

SELECT VALUE FROM TEST_TABLE ORDER BY KEY;

結果はこんな感じで思いっきり日本語が化けます。
よく見るとログイン時のメッセージも化けています。　　

f:id:stknohg:20170526215209p:plain

ちなみにPowerShellからSQL*Plusを実行しても同じ感じになります。

f:id:stknohg:20170526215305p:plain

原因と回避策

原因はCreators Updateで仕込まれたバグの様です。

新コンソールはマルチバイト文字のハンドリングにBUGがあるらしく。 https://t.co/JxEBWlBOS2 Creators Update ではBUGったまま出荷されている模様。最新のIPでは直っています。マイケルに期待している
— Takekazu Omi (@takekazuomi) 2017年5月26日

@takekazuomi さん曰く最新のInsider Previewではこの現象は改善されているそうなので、しばらく我慢すればパッチも出るんじゃないかと思います。

とりあえず現状としては以下の回避策で対処することが可能です。

追記. 従来のコンソールを使う

本エントリを公開した瞬間に@takekazuomi さんよりコメント頂きました。

これでは回避できませんか？ pic.twitter.com/pwDhI97QxU
— Takekazu Omi (@takekazuomi) 2017年5月26日

f:id:stknohg:20170526222749p:plain

コマンドプロンプトのプロパティで従来のコンソールを使うにチェックを入れてコマンドプロンプトを再起動することで本現象を回避することができました。
この方法が一番手っ取り早く確実ですね。

私の調査は一体何だったのかという気持ちでいっぱいですが気にしないことにします....

1. 先頭にダミーカラムを追加する

この現象はコンソールに表示される最初の文字が日本語でなければ良いっぽく、

SELECT '', VALUE FROM TEST_TABLE ORDER BY KEY;

な感じで先頭にダミーカラムを付けて最初にスペースが表示される様にするだけでも問題は解決します。

f:id:stknohg:20170526215543p:plain

とりあえずこれで問題は回避できますが、非常にトホホな気分になります...

2. クライアントの文字セットをUTF8にする

真っ当な回避策としてはクライアント側の文字セットをユニコードにしてしまう方法があります。
今回はUTF8に変更することで対処してみます。

NLS_LANGの文字セットをAL32UTF8に変えればクライアント側の文字コードをUTF8にできます。
これだけだとコマンドプロンプトで文字を表示できないのでCHCPコマンドでコードページも変える必要があります。

実行するコマンドは以下の様な感じになります。

CHCP 65001
SET NLS_LANG=Japanese_Japan.AL32UTF8

この状態であれば下図の様に文字化けを回避することができます。

f:id:stknohg:20170526215645p:plain

ちなみにPowerShellであれば、CHCPコマンドの代わりに[Console]::OutputEncodingの設定を変えることでも対応可能です。

[Console]::OutputEncoding=[Text.Encoding]::UTF8
$env:NLS_LANG='Japanese_Japan.AL32UTF8'

f:id:stknohg:20170526215701p:plain

最後に

残念の一言につきるので早く修正パッチが提供されることを望みます。

しばたテックブログ

気分で書いている技術ブログです。

オープンソースカンファレンス2017 Hokkaidoで登壇しました

セッション資料

セッション内容に関する補足

セッション内容の訂正に関して

セッション後に頂いた批判に関して