LinuxでPowerShellを動かしてみた――初期プレビュー版の使用感レビュー

昔々、筆者はPowerShellについて、そのLinux的な性質を称賛する記事を書いたことがあります。当時の記事には読者を楽しませるアニメーションまで添えていました。時が流れて数年後、MicrosoftはPowerShellをオープンソース化し、なんとLinux向けにも提供することを決定。現在、早期テスト版が利用可能になっています。

この動きには多くの理由から賛同できます。開発やシステム保守において共通の土台が築かれ、しかもWindows側ではBashも提供されているため、双方の取り組みが美しく対応し合っているのが分かります。長期的には2つのOSがより効果的に連携できるようになり、その真の受益者はシステム管理者や開発者、そしてエンドユーザーとなるでしょう。それでは、実際にどう動くのか見ていきましょう。

PowerShellのセットアップ

今回のテスト環境はCentOS 7.2(Xfce搭載)マシンで、サポート対象のLinuxディストリビューションの1つです。Microsoftは現在、Ubuntu(2つのLTS世代)とCentOS向けにインストーラーを公開しています。ダウンロードページでパッケージを見つけるのが少々紛らわしいものの、セットアップ自体はごく簡単です。yumでローカルインストールし、コマンドラインから起動しましょう。

yum install powershell-6.0.0_alpha.9-1.el7.centos.x86_64.rpm

さて、何ができる?

筆者は決してPowerShellの熟練ユーザーではありません。しかしシェルである以上、構文を覚えて使い始めるだけで十分です。では、BASHなどを置き換えられるのか?正直に言えば難しいですが、それが目的ではありません。まずは基本的なコマンドをいくつか入力して、操作感をつかむことにしました。

最初のうちは、Linuxユーザーには使い方のモデルがやや直感に反すると感じるかもしれません。しかし本質は変わりません。現状のPowerShell実装で気になった点は、カラースキームです。白背景に黄色の文字は視認性が悪いため、別のターミナルテーマへの変更をおすすめします。

困ったときは、help <コマンド> でヘルプを呼び出せます。さらに便利なのが get-help <コマンド> -examples で、正しい構文と具体的な使用例をその場で確認できます。これは非常に助かります。コマンドは大文字・小文字を区別しませんが、正式な表記では大文字が使われるケースもあります。

一部のコマンド(cmdlet)には短縮形も用意されています。たとえば Get-ChildItem は、UNIXの find に相当する機能としてはかなり分かりにくい名前ですが、gci と省略可能です。最初は少し戸惑うかもしれませんが、慣れれば大したことはありません。

gci -path /* -include "igor" -recurse

もう1つ混乱しやすいのがパスの指定方法です。ルートはもちろん末尾にスラッシュを付けて表記しますが、パスを扱う多くのコマンドを正しく動作させるには、スラッシュの後ろにアスタリスク(*)を追加する必要があります。不思議な仕様ですね。とはいえ、筆者も皆さんと同じく、一歩ずつ学んでいる段階です。

必要な機能はひと通り揃っています。見た目や操作感はやや異なり、名前は確実に違いますが、概ね問題なく動作します。シェル自体はかなり安定していました。唯一のトラブルは、非常に長い再帰的なファイル検索の処理時間を計測していた際にPowerShellがハングしたことです。応答が止まりましたが、実行を中断することはできました。

エラー表示について

PowerShellはメッセージが非常に冗長で、エラーも頻繁に表示されます。赤い文字で、しかもエラーが非常に長いテキストブロックとして出力されるため(Windowsと同じ挙動です)、一見すると不安になるかもしれません。しかし、その多くは無害なもので、たとえばコマンドラインでのファイル検索中に発生する「アクセス許可がない」エラー程度のものです。

もう1つ例を挙げると、measure-command コマンドレット(ある意味、Linuxの time に相当)は引数を波括弧 { } で囲む必要があります。これを忘れると、かなり仰々しい大きなエラーが表示されますが、実際にはまったく無害です。他の多くのコマンドレットでも同様のことが起こります。

これはエラーの上半分にすぎません。この先もまだ続きます。

Fedoraユーザーはどうすればいい?

MicrosoftがUbuntuとCentOS向けにPowerShellをリリースしたことは前述のとおりです。ではFedoraは使えるのか?答えを知りたかったので、実際に試してみました。結果として、この小さな実験は期待したほど滑らかにはいきませんでした。インストール直後にPowerShellを実行しようとすると、次のエラーに遭遇しました。

powershell
Failed to initialize CoreCLR, HRESULT: 0x80131500

これはかなり汎用的なエラーで、GitHubでもこのトピックに関する長い議論が交わされています。しかし、提案を鵜呑みにする前に、まずlibicu関連の依存関係に問題があることを自分で確認したいと思いました。そこで活躍したのが strace です。デバッグ作業で重宝するツールの1つです。

open("/usr/lib64/libicuuc.so.50", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

確かに、いくつかのライブラリが不足していました。問題は、該当パッケージ自体はFedoraに存在するものの、PowerShellが要求するバージョンより新しいという点です。シンボリックリンクを作成して回避を試みたところ、状況は多少改善しました。

ln -s /usr/lib64/libicui18n.so.56 /usr/lib64/libicui18n.so.50

しかし最終的に、エラーは「汎用的な起動失敗」から「共有オブジェクト内のシンボルに関する問題」へと変わりました。これはこちらの都合だけでは解決できません。

powershell
powershell: symbol lookup error: /opt/microsoft/powershell/6.0.0-alpha.9/System.Globalization.
Native.so: undefined symbol: uloc_getDefault_50

解決策は、古いバージョンのlibicuをダウンロードして任意の場所に展開し、PowerShellがlibicuの依存関係を優先的に読み込めるようライブラリパスを設定することです。たとえば次のようにします。

export LD_LIBRARY_PATH=<libicuフォルダ>/:$LD_LIBRARY_PATH

まとめ

ここまで来ました。2016年、Windows上でBashをネイティブに実行でき、Linux上でPowerShellをネイティブに実行できる時代になりました。英語で「Bob's your uncle(これで万事解決)」と言いますが、もはやあなた自身がBobのおじさんになれるのです!この流れは大いに歓迎すべきであり、長期的にはすべての人に利益をもたらすでしょう。

PowerShellは筆者の第一選択のスクリプトツール・言語・フレームワークではありませんが、それなりの魅力があります。複数OS混在環境を管理する必要がある方にとっては、管理業務を大幅に簡素化してくれる可能性があります。初期アルファビルドはテスト用途には十分安定していますが、本番環境での本格的な検証、特にroot権限での使用は強くおすすめしません。安全第一です。全体としては、なかなか良好な出来栄えです。それでは、キーボードを叩きにいきましょう。

それでは、また。