「PowerShell」の記事 - Crieit

後ほどミュートを解除しておく PowerShell スクリプト

2023-12-01T01:13:10+09:00

本記事はシェルスクリプト＆PowerShell Advent Calendar 2023 の1日目の記事だ。
如何にハードルを下げるかを考え、しょーもない内容となることを意識している…と言い訳しておこう。

何故ミュートを解除したいのか

さて、一時的に PC をミュートにしておきたい事がある。

コロナ禍を経て、 Cisco や Polycom といったテレビ会議システムに替わって、 Zoom などのWeb会議ソフトが普及した。
しかし、近年出社を強要されるのが一般化してくると、結局以前のように会議室に集まって、離れた拠点の相手とビデオ会議を行うことになる。
このとき、全員各々のPCでビデオ会議には参加するものの、音声は卓上マイク＆スピーカー使う事があり、ハウリングを避ける為に卓上マイクを使う人以外はスピーカー・マイクをミュートにするだろう。

ところが、会議終了後ミュートしっぱなしにしてしまい、通知等に気づきにくくなることがあるので、一定時間後にミュートを簡単に解除できるようにしておきたい。

それだけのために、スクリプト経由で MMDevice API 呼ぶのも仰々しいなぁと思っていた所、よく考えたらキーボードにあるミュート状態をトグルキーを仮想的に押せばいいじゃないかと気づいた。

ということで、早速 PowerShell でキーボードのマルチメディアキーを押すスクリプトを書いてみる。

早速コード例

#Requires -Version 5
$addTypeOptions = if ($PSVersionTable.PSVersion -lt [version]'6.0') { @{ Language = 'CSharpVersion3' }; } else { @{}; };
$typeKeyboard = Add-Type -PassThru @addTypeOptions -TypeDefinition @'
using System;
using System.Runtime.InteropServices;
namespace D8B35E79FC964E69854B61A2C9FB3C08 {
    public static class Keyboard {
        [StructLayout(LayoutKind.Sequential)]
        struct MOUSEINPUT {
            public Int32 dx; public Int32 dy; public UInt32 mouseData; public UInt32 dwFlags; public UInt32 time; public IntPtr dwExtraInfo;
        }
        [StructLayout(LayoutKind.Sequential)]
        struct KEYBDINPUT {
            public UInt16 wVk; public UInt16 wScan; public UInt32 dwFlags; public UInt32 time; public IntPtr dwExtraInfo;
        }
        // Define the unused MOUSE structure due to the UNION_INPUT structure size determination.
        [StructLayout(LayoutKind.Explicit)]
        struct UNION_INPUT {
            [FieldOffset(0)] public MOUSEINPUT mi;
            [FieldOffset(0)] public KEYBDINPUT ki;
        }
        [StructLayout(LayoutKind.Sequential)]
        struct INPUT {
            public int type;
            public UNION_INPUT ui;
        }

        [DllImport("user32.dll", SetLastError = true)]
        extern static uint SendInput(uint nInputs, INPUT[] pInputs, int cbSize);

        public static void TypeKey(UInt16 vk) {
            var inputs = new INPUT[2];
            inputs[1].type = inputs[0].type = 1; // INPUT_KEYBOARD
            inputs[1].ui.ki.wVk = inputs[0].ui.ki.wVk = vk;
            inputs[0].ui.ki.dwFlags = 0x0000; // KEYEVENTF_KEYDOWN
            inputs[1].ui.ki.dwFlags = 0x0002; // KEYEVENTF_KEYUP
            var uSent = SendInput(2, inputs, Marshal.SizeOf(inputs[0]));
            if (uSent != 2) {
                throw new System.ComponentModel.Win32Exception(Marshal.GetLastWin32Error());
            }
        }
    }
}
'@ | Where-Object Name -EQ Keyboard;
$typeKeyboard::TypeKey(<# VK_VOLUME_MUTE #> 0xAD);

これを Push-MuteKey.ps1 等の名前で保存しておいて、

Start-Sleep -Seconds ([datetime]'11:01' - [datetime]::Now).TotalSeconds; .\Push-MuteKey.ps1;

などと指定して実行すれば、指定時間にミュートキーが押されてミュートが解除される。

Win32 API C# 経由で叩く場合、 32bit か 64bit どちらのプロセスでも問題なく動くよう気をつける必要があったり、 PowerShell のバージョン (5 か 7以降か) でコンパイル時の挙動が異なるので、そこらへんも気をつけて実装した。
うーん、 Win32 API 叩くために色々構造体を定義する必要もあって、結局仰々しいなぁ。。。

おわりに

シェルスクリプト＆PowerShell Advent Calendar 2023 は、執筆者募集中です！
こんな割としょうも無い内容で構わないので、久々になんか書いてみませんか！？

Pester v3 & v5 互換のテストコードを書く (PowerShell)

2023-10-03T09:07:43+09:00

PowerShell のテストフレームワークである Pester は、単体テストや自動テストなどを手軽に書けるので、スクリプトやコードの品質を保つのに役立つ。

しかし、 Pester は v3 から v5 にかけてかなり大きな破壊的変更がある。

この記事では、 Pester v3 と v5 の両方に互換があるテストコードの書き方について紹介したい。

何故 v3 と v5 で互換を取りたいか

Windows 10 や 11 では、デフォルトで Windows PowerShell 5.1 がインストールされており、更にそこには Pester モジュールの v3.4.0 もインストールされている。
Windows 上の PowerShell モジュールディレクトリはシステム全体で共通のため、たとえ別途 PowerShell 7.3 LTS などをインストールしていたとしても、既定では Pester v3.4.0 が読み込まれるわけだ。

一方、 Linux 等のそれ以外のシステムで PowerShell をインストールした場合は、 Pester が自動的にインストールされることはないため、 Pester モジュールを追加でインストールすることになる。
このとき、普通は最新版の v5 が入るだろう。

Windows PowerShell の Pester を v5 に更新させたり、 Linux 等のシステムでインストールする Pester モジュールを v3.4 に抑えさせたりできればよいが、まぁなかなかそうも行かない時がある。

そんなのっぴきならん状況だと、多少苦労してでもテストコード側を Pester v3 と v5 どちらにも互換を取ってしまったほうが手っ取り早いかも…なんて状況が地球上の何処かには存在するかもしれない。

テストコードの書き方

v3 と v4 の間の破壊的変更で一番デカいのは、 Should 構文の変更で互換切りを行っている部分だ。

https://pester.dev/docs/migrations/breaking-changes-in-v5

Legacy syntax Should Be (without -) is removed, see Migrating from Pester v3 to v4

構文自体の変更自体は v4 で行われたものだが、このときは以前の構文も互換性が残されていた。
ところが、 v5 で早速この互換が切られてしまっている。

コレのせいで、ほぼすべてのテストコードが、そのままでは v3 と v5 の間で互換を取ることが不可能になっている。
何考えてんだ……

位置指定パラメータからスイッチパラメータに変わっているため、このどちらにも渡せるようにするためには Splatting 表記に頼ることにする。
v3 で使える Should のオペレーターそれぞれについて、 v3 以下なら位置指定パラメータで渡す方法で、 v4 以上ならスイッチパラメータで渡す方法で、それぞれ $BeForCompat のような形で $*ForCompat, $Not*ForCompat の形式の変数をテストコード開始時に定義する。
そして、その変数を Should で @BeForCompat のように Splatting 表記にて使用する。

また、 v4 では Contain/ContainExactly オペレーターが -FileContentMatch/-FileContentMatchExactly にリネームされていたり、
v5 では *.Tests.ps1 ファイル先頭や、 Context, Describe 直下にセットアップコードが記載できなくなっているので、全て BeforeAll ブロック内に記述する必要がある。

これらのマイグレーションをまとめると、 v3/v5 互換の Pester テストコードは以下のようになる。
(v3-to-v5-Migrations.Tests.ps1 というファイル名で保存されているものとする)

#Requires -Version 5
#Requires -Modules @{ ModuleName="Pester"; ModuleVersion="3.0" }
trap { break; }

$GlobalBeforeAll = {
    # Write here the code that needs to be executed at the start of the test
    $shouldParams = 'Be','BeExactly','BeGreaterThan','BeLessThan','BeLike','BeLikeExactly','BeNullOrEmpty','BeOfType','Exist','Match','MatchExactly','Throw';
    if ((Get-Module Pester).Version -ge [version]'4.0') {
        $shouldParams | ForEach-Object {
            Set-Variable "${_}ForCompat" @{ $_ = $true };
            Set-Variable "Not${_}ForCompat" @{ Not = $true; $_ = $true };
        };
        $FileContentMatchForCompat = @{ FileContentMatch = $true };
        $FileContentMatchExactlyForCompat = @{ FileContentMatchExactly = $true };
        $NotFileContentMatchForCompat = @{ Not = $true; FileContentMatch = $true };
        $NotFileContentMatchExactlyForCompat = @{ Not = $true; FileContentMatchExactly = $true };
    } else {
        $shouldParams | ForEach-Object {
            Set-Variable "${_}ForCompat" @($_);
            Set-Variable "Not${_}ForCompat" @('Not', $_);
        };
        $FileContentMatchForCompat = @('Contain');
        $FileContentMatchExactlyForCompat = @('ContainExactly');
        $NotFileContentMatchForCompat = @('Not','Contain');
        $NotFileContentMatchExactlyForCompat = @('Not','ContainExactly');
    }
}
if ((Get-Module Pester).Version -ge [version]'5.0') {
    BeforeAll $GlobalBeforeAll;
} else {
    . $GlobalBeforeAll;
}

Describe 'Pester v3, v5 compatibility notation test' {
    BeforeAll {
        # DON'T use $MyInvocation.MyCommand.Path
        $filePath = '.\v3-to-v5-Migrations.Tests.ps1';
    }

    It "Pattern: (, )" -TestCases @(
        @{A=1; B=2};
        @{A=3; B=4};
    ) {
        param ($A, $B);
        ($A / $A) | Should @BeForCompat 1;
        ($B * $A) | Should @NotBeForCompat 0;
        $filePath | Should @FileContentMatchExactlyForCompat 'BeforeAll';
    }
}

PS > # Pester 3.4.0 の場合 PS > Get-Module Pester ModuleType Version PreRelease Name ---------- ------- ---------- ---- Script 3.4.0 Pester PS > Invoke-Pester Describing Pester v3, v5 compatibility notation test [+] Pattern: (1, 2) 74ms [+] Pattern: (3, 4) 5ms Tests completed in 53ms Passed: 2 Failed: 0 Skipped: 0 Pending: 0 Inconclusive: 0 PS >

PS > # Pester 5.5.0 の場合 PS /> Get-Module Pester ModuleType Version PreRelease Name ---------- ------- ---------- ---- Script 5.5.0 Pester PS > Invoke-Pester Starting discovery in 1 files. Discovery found 2 tests in 21ms. Running tests. [+] .../v3-to-v5-Migrations.Tests.ps1 115ms (82ms|13ms) Tests completed in 117ms Tests Passed: 2, Failed: 0, Skipped: 0 NotRun: 0 PS >

うーん、面倒くさいね。
Tips

こんなアホなことはせずに、Pester v3 なら v3 のコードで、 v5 なら v5 のコードで記述する場合、せめてテストコードの先頭で #Requires 構文を書いて、どのバージョンの Pester をターゲットにしているかしっかり明示しよう。

# Pester v3, v4 をターゲットにする場合 #Requires -Modules @{ ModuleName="Pester"; ModuleVersion="3.0"; MaximumVersion="4.99" } (Get-Module Pester).Version; Describe 'desc' { It 'it' { 1 | Should Be 1; }; };

# Pester v5 以降をターゲットにする場合 #Requires -Modules @{ ModuleName="Pester"; ModuleVersion="5.0" } BeforeAll { (Get-Module Pester).Version; }; Describe 'desc' { It 'it' { 1 | Should -Be 1; }; };

本来 #Requires 構文には、必要なモジュールが現在のセッションにない場合自動でインポートする機能があり、例えば複数のバージョンのモジュールがサイドバイサイドでインストールされていた場合だと、条件に一致するバージョンのものがインポートされる便利な機能がある。
しかし Pester の場合は、必ずしも良い感じには機能してくれるとは限らない。

テストコードが読み込まれる前 Invoke-Pester した時点で Pester モジュールのインポートが走ってしまうことや、複数のバージョンのモジュールがインポートされた状態になると、いずれか一つのモジュールが条件を満たせば #Requires の検証をパスしてしまうのに、インポートされたもののうち最も古いバージョンのモジュールで実行されてしまうような挙動をとるためだ。

それでも、 Pester モジュールがひとつしかインストールされていないような多くの状況では、バージョンを明示しておくことでエラー原因がわかりやすくはなるはずだ。

エクスプローラーのキャッシュを削除

2023-03-19T17:06:25+09:00

■ExplorerCashDel.vbs

Option Explicit Const cmd = "Remove-Item C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations/*-ms" Dim processName : processName = "エクスプローラーキャッシュ削除処理" PeriodicExecution cmd,processName '========================================================= '機能名 : Sub PeriodicExecution '引数 : pm_cmd PowerShellコマンド ' : pm_processName 処理名 '処理 : PowerShell定期実行用 '========================================================= Sub PeriodicExecution(pm_cmd ,pm_processName) Dim objFS Dim x Dim strName,strPath 'ファイルシステムオブジェクト作成 Set objFS = CreateObject("Scripting.FileSystemObject") 'ファイル名を取得 strName = objFS.GetFileName(strPath) x = Msgbox ( pm_processName & "を実行しますか？" & strName , vbOkCancel , pm_processName ) If x = vbOk then ' WSHオブジェクトの作成 Dim objShell Set objShell = CreateObject("WScript.Shell") ' PowerShellコマンドの実行 objShell.Run "powershell -ExecutionPolicy RemoteSigned -Command " & pm_cmd, 0 Msgbox "完了しました" , , pm_processName End If ' WSHオブジェクトの破棄 Set objShell = Nothing End Sub

【M365】PowerShellで複数のユーザーアカウントのパスワードを変更する

2023-03-07T15:07:01+09:00

初めてPowerShellで操作する場合は、こちらを参考にM365の管理モジュールをインストールすること

Azure Active Directory への接続を開始

> Connect-MsolService

複数ユーザーアカウントのパスワード一括変更に使用するCSVの作成例

UserPrincipalName Password

[email protected] hogehogepassword1

[email protected] hogehogepassword2

複数ユーザーアカウントのパスワード一括変更(CSVインポート)

インポートするCSVファイル（NewAccounts.csv）がC:\M365tools\2023にある場合の例

> Import-Csv -Path "C:\M365tools\2023\ChangePW.csv" | foreach {Set-MsolUserPassword -NewPassword $_.Password -UserPrincipalName $_.UserPrincipalName -ForceChangePassword $False}

【M365】PowerShellで複数のユーザーアカウントの表示名を変更する

2023-03-07T15:03:40+09:00

初めてPowerShellで操作する場合は、こちらを参考にM365の管理モジュールをインストールすること

Azure Active Directory への接続を開始

> Connect-MsolService

複数ユーザーアカウントの表示名一括変更に使用するCSVの作成例

UserPrincipalName DisplayName

[email protected] user1(AbeT)

[email protected] user2(SatoK)

複数ユーザーアカウントの表示名一括変更(CSVインポート)

インポートするCSVファイル（NewAccounts.csv）がC:\M365tools\2023にある場合の例

> Import-Csv -Path "C:\M365tools\2023\ChangeDN.csv" | foreach {Set-MsolUser -DisplayName $_.DisplayName -UserPrincipalName $_.UserPrincipalName}

【M365】PowerShellで複数のユーザーアカウントを作成する

2023-03-07T14:11:02+09:00

初めてPowerShellで操作する場合は、こちらを参考にM365の管理モジュールをインストールすること

Azure Active Directory への接続を開始

> Connect-MsolService

ライセンスの状態を確認

ユーザーに割り当てるライセンスのID（以下CSVのAccountSkuId）を確認し、インポートするCSVに入力する

> Get-MsolAccountSku

新規ユーザーの一括作成に使用するCSVの作成例

UserPrincipalName FirstName LastName DisplayName Password UsageLocation AccountSkuId

[email protected] Taro Abe user1(Abe) hogepassword1 JP hoge:O365_BUSINESS_PREMIUM

[email protected] Ken Sato user2(Sato) hogepassword2 JP hoge:O365_BUSINESS_PREMIUM

新規ユーザーの一括作成(CSVインポート)

インポートするCSVファイル（NewAccounts.csv）がC:\M365tools\2023にある場合の例

> Import-Csv -Path "C:\M365tools\2023\NewAccounts.csv" | foreach {New-MsolUser -DisplayName $_.DisplayName -FirstName $_.FirstName -LastName $_.LastName -Password $_.Password -UserPrincipalName $_.UserPrincipalName -UsageLocation $_.UsageLocation -LicenseAssignment $_.AccountSkuId} | Export-Csv -Path "C:\M365tools\2023\NewAccountResults.csv"

バッチファイルからPowerShellを呼び出し、Powershellコマンドでリネーム

2023-02-20T07:35:41+09:00

■バッチファイル側
ps_call.bat

@echo off echo PowerShell呼び出し中です。 powershell -NoProfile -ExecutionPolicy Unrestricted .\rename.ps1 echo 完了しました pause > nul exit

■powershell側
rename.ps1

Set-Location C:\XXXXXX Get-ChildItem *.txt| Rename-Item -NewName {$_.Name -replace '^([0-9])月','0$1月'} Get-ChildItem *.txt| Rename-Item -NewName {$_.Name -replace '月([0-9])日','月0$1日'} Get-ChildItem *.txt| Rename-Item -NewName {$_.Name -replace '([0-9][0-9])月([0-9][0-9])日','$1$2'}

PowerShell で中身がランダムな大きめのファイルを高速に作る

2023-02-14T12:41:19+09:00

色々テストをしていると、ユニークなランダムの中身で、任意サイズのファイルが欲しくなることがままある。

デバイスを全てファイルとして扱う Unix や Linux なら、 /dev/urandom 擬似デバイスを使って dd if=/dev/urandom of=out.bin bs=1M count=64 みたいに任意サイズでファイルをコピーして作れば良い。

しかし API ベースの Windows だとそういうわけにいかないので、何らかのスクリプトから API を呼んでやる必要がある。

呼ばせるスクリプトは、 Windows に標準で搭載されていて追加でインストール不要な、毎度おなじみ PowerShell が良いだろう。
作りたいランダムなファイルのサイズが小さければ、 PowerShell 上で以下のような雑なコードを実行すればよい。

$Size = 16KB; [byte[]]$bin = &{foreach($i in 1..$Size) { Get-Random -Maximum 255 }}; [System.IO.File]::WriteAllBytes((Join-Path (Get-Location) .\out.bin), $bin);

しかし、 MiB オーダーを越えてくると、上記のコードでは速度が実用的ではなくなる。

と言うことで、出力速度も気にしながら、大きめなランダムなファイルを作成するコードを考えてみる。

コード

function Make-RandomFile ([Parameter(Mandatory=$true)][string]$OutPath, [Parameter(Mandatory=$true)][long]$FileSize, [int]$ChunkSize = 16MB) { $bin1 = [byte[]]::new($ChunkSize); $bin2 = [byte[]]::new($ChunkSize); $r = [System.Random]::new(); [long]$progress = 0; [int]$nextLen = 0; $fs = [System.IO.File]::Create([System.IO.Path]::Combine($PWD, $OutPath)); try { do { $task = $fs.WriteAsync($bin1, 0, $nextLen); $r.NextBytes($bin2); $task.Wait(); $bin1, $bin2 = $bin2, $bin1; $progress += $nextLen; $nextLen = [System.Math]::Min([long]$ChunkSize, $FileSize - $progress); } while ($nextLen -gt 0); } finally { $fs.Dispose(); } }

上記のような関数をコンソールに貼り付けて定義し、あとは以下のように実行すれば良い。

Make-RandomFile .\out.bin -FileSize 1GB;

解説

大きなファイルを作る際、最初に挙げたような雑なコードだと、一旦全てのデータをメモリ (RAM) に置いてしまうため、メモリ不足になったり動作が遅くなったりしかねない。
そこで、適当なチャンクサイズ (上記コードだと標準では 16MiB) 毎にランダムなデータを作って、それを書き込んでいる。

また、ランダムな配列を作るのも、その配列をファイルに書き込むのも、それぞれ時間がかかるため、それらを同期的に逐次実行すると効率が悪い。
そこでバッファを2つ用意して、片方のバッファでファイルを非同期的に書き込んでいる間に、もう一方のバッファでランダムなデータを生成することで、効率を上げている。

補足

ちなみに、 .NET 5 以前の System.Random の擬似乱数生成器は、あまり乱数精度が高くないと言われているので、セキュリティ的に精度の高いランダム性であることが重要な場合は、より乱数精度の高い別の API を使った方が良いかもしれない。

とりあえず、ちょっとしたテストファイルでランダムなデータが欲しいだけなら、 System.Random で十分だと思うが。

また、ストレージの速度が十分に速い状況でより速く実行させたいなら、 Windows 10/11 標準の Windows PowerShell 5.1 より PowerShell 7.2 以降で実行したほうが、圧倒的に速いはずだ。 ¹

Windows PowerShell 5.1 では .NET Framework 4.8 が、 PowerShell 7.2 LTS では .NET 6 が、それぞれ使われているが、その .NET 6 以降では、擬似乱数生成器が性能の良いものに切り替わった為 (.NET 6 (Preview) における System.Random の実装変更 - 屋根裏工房改) ↩︎

PowerShell:指定フォルダのbatを実行するLauncherを作ってみた

2022-05-26T20:41:56+09:00

はじめに

お仕事とかでテスト用batとか作ってしょっちゅうたたくけどいちいちコマンドプロンプトに打つのも面倒なので画面のはじっこにでもbat実行用のLauncherでも置いとけばいいかなと思って作ってみた。
最初は適当にexe作ろうと思ったけどたまにはPowerShellでForm作るの復習がてらやってみようってことで昼休みに作ってたらまんまと罠にはまって一旦諦め。
解決はしたものの悔しさと絶対覚えてられない自身があったので記事に残す。

やりたいこと

引数で渡されたPathにある.batファイルをそれぞれボタンコントロールにして一列に並べる。

ボタンをクリックすると対応するbatを実行する

後ろに隠れると不便だからTopMost

batファイルがなければエラーメッセージでもだして終了

単純にFormの話

最初のおまじないさえ知っておけばそんなに難しくない

こういうの(アセンブリ)使うよって教えてあげて

Add-Type -AssemblyName System.Windows.Forms Add-Type -AssemblyName System.Drawing

Form(外側)作ってあげて

$Form = New-Object System.Windows.Forms.Form $Form.Text = "BatToolLauncher" $Form.Width = 180 $Form.Height = $BatList.Count*30 + 50 $Form.TopMost = $true

ボタンを配置する

$Button = New-Object System.Windows.Forms.Button $Button.Location = New-Object System.Drawing.Point(0,0) $Button.Top = $Button.Top + $i * 30 $Button.Size = New-Object System.Drawing.Size(160,30) $Button.Text = $x.BaseName $Form.Controls.Add($Button)

※$BatListはbatの一覧(Get-ChildItemの結果)
※$xは$BatListをforeachで回した時の一時変数

ボタンクリック時の挙動を設定する(今回の鬼門)

ボタンクリック時の挙動を書くことだけは簡単。
「Add_イベント」の形で定義してあげればいい。クリックイベントなら下の{}の中に書けばいい。

$Button.Add_Click({})

簡単。なはずだった。
とにもかくにも失敗例↓

$Button.Add_Click({Start-Process -WindowStyle Hidden $x.FullName})

これは$x.FullNameでbatのフルパスが入るからそいつをStart-Processするだけ簡単だよね、と思って頭を抱えたもの。
何が起こるかというと、実際のクリック時の$xを参照してくれる。foreachでぐるぐる回していたので、$xが指すのは最後のbat。つまり、どのボタンを押しても最後のbatファイルが実行される。
というわけで半日かけて試行錯誤・調査して解決策↓

$Button.Add_Click({Start-Process -WindowStyle Hidden $x.FullName}.GetNewClosure())

GetNewClosure()
を書くことでこの{}で囲まれた部分はスクリプトブロックじゃなくてクロージャだよ、となるらしい。今回の話に沿わせるとこの行を書いた時点の変数の内容でFixしてくれるらしい。
ちょっと説明の言葉が怪しい自覚はある。

スクリプト全体

結果的にこんな感じ。

Add-Type -AssemblyName System.Windows.Forms Add-Type -AssemblyName System.Drawing if($args.Length -gt 0) { $TargetDir = $args[0] } else { $MyPath = $MyInvocation.MyCommand.Path $TargetDir = Split-Path -Parent $MyPath } # batファイルのリスト作成 $BatList = Get-ChildItem $TargetDir -Filter "*.bat" if($BatList -eq $null) { [System.Windows.Forms.MessageBox]::Show("no bat files", "Error") return } # Form作成 $Form = New-Object System.Windows.Forms.Form $Form.Text = "BatToolLauncher" $Form.Width = 180 $Form.Height = $BatList.Count*30 + 50 $Form.TopMost = $true # ボタン作成 $i = 0 foreach($x in $BatList) { $Button = New-Object System.Windows.Forms.Button $Button.Location = New-Object System.Drawing.Point(0,0) $Button.Top = $Button.Top + $i * 30 $Button.Size = New-Object System.Drawing.Size(160,30) $Button.Text = $x.BaseName # GetNewClosure様をたたえる！ $Button.Add_Click({Start-Process -WindowStyle Hidden $x.FullName}.GetNewClosure()) $Form.Controls.Add($Button) $i++ } # 表示 $Form.ShowDialog()

おまけ

ps1ファイルってそのままたたけないのでいつも汎用性持たせて作ってるbat

powershell -ExecutionPolicy RemoteSigned %~dpn0.ps1 %*

同じ場所にある同名ps1を実行するbat
いつもの使いまわしファイルがどこかにいったので久しぶりに手書きしたけどだいたいこんなだったはず。

Teamsの管理コマンド備忘メモ

2022-04-11T12:19:26+09:00

チームの作成

> New-Team -DisplayName "表示名" -MailNickName "MailNickName属性値" -Owner "所有者のUPN" -Visibility "public or private" -Description "説明"

チームの一括ユーザー登録

> Import-Csv -Path ".\teamusers.csv" | foreach{Add-TeamUser -GroupId $_.grpID -user $_.userPN -Role $_.role}

teamusers.csv (CSVの作成例)

grpIDはGet-Teamで確認したチームのGroupIdを入れる
userPNはユーザーのメールアドレスを入れる
roleは所有者ならownerでメンバーはmember

grpID userPN role

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx [email protected] member

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx [email protected] owner

チャンネルの作成

標準チャンネルで作成されます

> New-TeamChannel -GroupId "Get-Teamで確認したチームのGroupId" -DisplayName "表示名"

PowerShellにM365やTeamsの管理モジュールをインストールする

2022-04-11T11:41:03+09:00

M365のユーザーアカウントやTeamsを管理するコマンドを実行するために、事前にインストールが必要

AzureADモジュールのインストール

> Install-Module -Name AzureAD

M365モジュールのインストール

> Install-Module -Name MSOnline

Microsoft Teamsモジュールのインストール

> Install-Module -Name MicrosoftTeams

Microsoft Teamsに接続

コマンド実行後に、ブラウザが起動してM365のサインイン画面が出てきますので、管理権限のあるユーザーでサインインします。

> Connect-MicrosoftTeams

チーム一覧を出力

> Get-Team

macOSにPowerShellをインストールする

2022-04-11T11:27:58+09:00

MacでM365やTeamsをコマンドで管理する時に便利

PowerShellインストール

$ brew install --cask powershell

PowerShellの起動

$ pwsh

OSの設定をPowershellで変える(言語編)

2022-01-28T18:32:09+09:00

はじめに

多国語の対応とかしてると確認のためにいちいちシステム言語を切り替えて云々が発生してうっとおしいのでバッチにしてしまえ、たぶんPowerShellでできるはずだ、ということで調べた結果を垂れ流す。
なお、システム設定いじくるので管理者として実行してあげる必要がある。
それも面倒なので権限昇格するようにバッチで行う。(そのうち別記事で書く)

サポート言語の追加

[Windows設定]→[時刻と言語]→[言語]のページの下の方の[言語の追加]。

Get-WinUserLanguageList/Set-WinUserLanguageList

Get～で現在のサポート言語のリストをとってくる
Set～でサポート言語リストをセットする
ので
1.Getする
2.追加する(言語コードをAdd)
3.Setする
でいける

例えばドイツ語なら

$CurrList = Get-WinUserLanguageList $CurrList.Add("de-DE") Set-WinUserLanguageList $CurrList -Force

-Forceは自動化したいから。ないと確認メッセージが出ます。

地域設定(形式)

[Windows設定]→[時刻と言語]→[地域]のページの2こめくらい。

Get-Culture/Set-Culture

ただ言語デフォルトに変更したいだけならSet-Cultureで言語コードを渡せばいい。
だけど言語デフォルトでありがちな罠の小数点(たまにカンマの国がある)を変更したいなら
1.Set 言語デフォルト
2.Get
3.編集
4.Set 編集したの
という手順になるが、どうも1の直後に2を呼ぶと反映されてなかったのでps1ファイルを分けた。

# ChangeCulture_1.ps1 Set-Culture "de-DE"

# ChangeCulture_2.ps1 $Cult = Get-Culture $Cult.NumberFormat.NumberDecimalSeparator = "." Set-Culture $Cult

システムロケール

[Windows設定]→[時刻と言語]→[地域]→[関連設定：日付、時刻、地域の追加設定]→[地域]→[管理]タブ→[Unicode対応ではないプログラムの言語]
※遠い、正直コントロールパネル出した方が早く着く

Get-WinSystemLocale/Set-WinSystemLocale

確認したいならGetで。Setで言語コードを入れれば終わり。

Set-WinSystemLocale "de-DE"

再起動は必須なのでお好みに合わせて
Restart-System
をスクリプトに含めるなり、そこは手でやるなりご自由に。

カンタン！

Windows の hosts ファイルを管理者権限のメモ帳で開くワンライナー

2021-12-24T23:56:32+09:00

経緯

hosts を毎度毎度手動で開く (管理者権限でメモ帳を開いて、メモ帳から %windows%\system32\drivers\etc\hosts を開く) のは面倒になってきたので、ワンライナーを作ることにしました。

コード

cd /d %~dp0 PowerShell -NoProfile -ExecutionPolicy unrestricted -Command "start notepad C:\Windows\System32\drivers\etc\hosts -verb runas"

最初の一行はなくても良いので実質ワンライナー。

これを bat ファイルとして保存すれば、ダブルクリックで hosts を開くことができます。

……ただ、 bat はスタート画面にピン止めすることはできないのですね。

スタート画面にピン止め

bat そのものはピン止めできませんが、 cmd.exe (コマンドプロンプト) はできます。

そこで、ショートカットで「コマンドプロンプトを開きつつ、実行するコマンドとして上述ワンライナーを指定する」ことでピン止めすることにしました。

bat ファイルのショートカットを作成

1.のショートカットを右クリック→「プロパティ」でプロパティ画面を開く

ショートカットのリンク先の先頭に、 cmd /cを挿入する

これで、上述の「コマンドプロンプトを開きつつ、実行するコマンドとして上述ワンライナーを指定する」を実現しました。

これでスタート画面にもピン止めできて、ダブルクリックで hosts を開くことができるようになりました。便利。

参考

hosts を開く

管理者権限でメモ帳を開いてhostsを編集するコマンド - Qiita

WindowsのPowerShellを管理者権限で起動する方法 - Qiita

Windows10でメモ帳を管理者権限で一瞬で開く方法 | あいしんくいっと

ピン止め

Windows10でバッチファイルをスタート画面にピン留めする - ドナドナされるプログラマのメモ

PowerShellで正規表現で対象行を抽出する方法

2021-09-05T21:34:35+09:00

PowerShellで特定の行を抽出する方法

小数点以下n桁以上の値を持つ行を出力するコマンド

$re ='[0-9]\.[0-9]{n,}' select-string -path .\powershell.csv -pattern $re

出力結果は下記のようになる。
powershell.csv:8:1.0 110.0 10.0 1.899999999
powershell.csv:11:1.0 110.0 10.0 1.899999999

出力結果に含まれるファイル名部分を削除して、抽出した行のみ出力する方法

select-string powershell.csv -pattern $re | foreach-object { $($_ -split ":" )[3] }

出力結果は下記のようになる。
1.0 110.0 10.0 1.899999999
1.0 110.0 10.0 1.899999999

PowerShell でインストール済プログラム一覧を取得する

2021-02-19T02:27:51+09:00

PowerShell を Windows の管理ツールとしてみたときに、割と昔から意味がわからないと思っていることが 1点ある。
Windows のインストール済みプログラム一覧を取得するコマンドがないことだ。

もう少し具体的に言うと、appwiz.cpl で開ける、コントロールパネルのプログラムと機能の一覧や、設定の「アプリと機能」の一覧を取得するコマンドレットがない。
コマンドレットがないだけじゃなく、コードを書いて取得する確立して手段すら存在しないのだ。

とりあえず、それに近い情報がとれる代替方法として、レジストリのアンインストーラー一覧を取得する方法が知られている。
ただ、ググってもあまり PowerShell らしい綺麗 (?) なコードで書かれているサンプルが少なかったので、ワンライナーで書いてみる。

Get-ChildItem -LiteralPath (('HKLM:', 'HKCU:' | %{ "${_}\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" }) + 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall') | Get-ItemProperty -Name DisplayName, DisplayVersion, Publisher, InstallDate -ErrorAction Ignore;

これで取得した内容を | Sort-Object DisplayName, DisplayVersion や | Select-Object DisplayName, DisplayVersion などにパイプしてから使うと良いだろう。

ちなみに WMI の Win32_Product クラスを使って取得する方法 (Get-CimInstance -ClassName Win32_Product) は、

MSI でインストールしたアプリしか取得できない

コンピューターはMSIがインストールされているすべてのアプリケーションを再検証するので、負荷がかかるし遅い

と言うことから使うべきではないとされている。
Get-WmiObject -class win32_product doesn't list all installed Applications - PowerShell for Windows - Ask the Experts - IDERA Community

(PowerShell) PSCustomObject をループさせつつキーと値の両方にアクセスする

2021-01-12T23:48:54+09:00

引き続き PowerShell のお話。今度は PSCustomObject をループさせつつキーと値の両方にアクセスする方法が分からず躓きました。

現象

{ "common": { "config": { "user.name": "testuser", "user.id": 12345, "user.email": "[email protected]" } } }

例えばこんな config.json があるとします。

この JSONファイルを読み込んでループさせつつ、キーと値の双方にアクセスしたい。

そこで foreach($confgi in $configData.GetEnumerator()){} としたり、 foreach($confgi in $configData.Keys){} としたりしましたが一向に中身が取得できず四苦八苦。

対処

# JSONファイル読み込み [String]$configPath = Join-Path ( Convert-Path . ) 'config.json' $configData = Get-Content -Path $configPath -Raw -Encoding UTF8 | ConvertFrom-JSON # ループ foreach( $key in $configData.common.config.psobject.properties.name ) { Write-Host $key ' = ' $configData.common.config.$key }

最終的に、 $Object.psobject.properties.name という全然異なるアクセス方法だったことが分かりました。今回の場合はキーが階層で入り組んでいるのでさらに . (ピリオド(ドット)) の個数が増えています。

> PowerShell -ExecutionPolicy RemoteSigned .\test.ps1 user.name = testuser user.id = 12345 user.email = [email protected]

やっとキーと値の両方が取得できました……。

参考

PSCustomObject について知りたかったことのすべて - PowerShell | Microsoft Docs

(PowerShell) PSCustomObject のピリオド(ドット)入りのキー名にアクセスする

2021-01-11T22:59:05+09:00

Powershell で JSON から読み込んだオブジェクトにピリオド(ドット)入りのキー名があり、これにどうやってアクセスしようか悩みました。

現象

{ "user": { "user.name": "testuser", "user.email": "[email protected]" } }

例えばこんな config.json があるとします。

この JSONファイルを読み込み、ユーザの入力を受け付けて設定を上書きするスクリプトを書きました。

# JSONファイル読み込み [String]$configPath = Join-Path ( Convert-Path . ) 'config.json' $configData = Get-Content -Path $configPath -Raw -Encoding UTF8 | ConvertFrom-JSON # 一度出力 Write-Host $configData.user['user.name'] # 入力受付 [String]$username = Read-Host 'ユーザー名を入力してください (半角英数字と一部記号 (-, _) )。' if (-not ($username -match "^[a-zA-z0-9\-_]+$") ) { Write-Host 'ERROR: ユーザ名に使用できない文字が含まれています。' -BackgroundColor DarkRed Write-Host `r`n exit } $configData.user['user.name'] = $username # 再度出力 Write-Host $configData.user['user.name']

ここで問題となったのが user.name という . (ピリオド(ドット))入りのキー名。オブジェクトで . でキー名を連結できるのが JavaScript に似ていたので、つい JavaScript のように $configData.user['user.name'] と書いてしましました。

すると

> PowerShell -ExecutionPolicy RemoteSigned .\test.ps1 ユーザー名を入力してください (半角英数字と一部記号 (-, _) )。: aaa 型 System.Management.Automation.PSObject のオブジェクトにインデックスを付けることはできません。発生場所 PATH\TO\PROJECT\test.ps1:16 文字:1 + $configData.user['user.name'] = $username + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) []、RuntimeException + FullyQualifiedErrorId : CannotIndex

怒られました。しかも、初出の位置ではなく変数で上書きする部分で。初出の Write-Host による標準出力はブランクを出力してスルーされたようです。

以上より、

変数の値を読み込む場合(出力など): 存在しないキーとしてブランク出力してそのままスルー

変数の値を書き込む場合: エラー

となるようです。困った。

対処

PSCustomObject について知りたかったことのすべて - PowerShell | Microsoft Docs

プロパティ名に文字列を使用しても、やはり機能します。

$myObject.'Name'

なん……だと……。

ということで上記スクリプトを書き換えます。

# JSONファイル読み込み [String]$configPath = Join-Path ( Convert-Path . ) 'config.json' $configData = Get-Content -Path $configPath -Raw -Encoding UTF8 | ConvertFrom-JSON # 一度出力 Write-Host $configData.user.'user.name' # 入力受付 [String]$username = Read-Host 'ユーザー名を入力してください (半角英数字と一部記号 (-, _) )。' if (-not ($username -match "^[a-zA-z0-9\-_]+$") ) { Write-Host 'ERROR: ユーザ名に使用できない文字が含まれています。' -BackgroundColor DarkRed Write-Host `r`n exit } $configData.user.'user.name' = $username # 再度出力 Write-Host $configData.user.'user.name'

肝は $configData.user.'user.name' 。 $configData.user['user.name'] の角括弧 ([])を外してキー名の文字列をそのまま . (ピリオド(ドット)) で繋げました。

> PowerShell -ExecutionPolicy RemoteSigned .\test.ps1 testuser ユーザー名を入力してください (半角英数字と一部記号 (-, _) )。: abc abc

上手く行きました。

参考

PSCustomObject について知りたかったことのすべて - PowerShell | Microsoft Docs

.NET Interactive で C# と PowerShell を股に掛ける

2020-12-09T02:33:59+09:00

この記事は、「C# Advent Calendar 2020」 9日目の記事、かつ「PowerShell Advent Calendar 2020」 9日目の記事だ。

スミマセン。横着した。

この時期になれば .NET Interactive の Preview 4 が出てるだろうしその記事でも書こうかな～などと目論んでいたものの、残念ながら登場しなかった。

このため、 .NET Interactive .NET 5 対応版の導入と、 Variable sharing の内容でお茶を濁そうと思う。

.NET Interactive のなんたるかについては、以前の以下の記事で取り扱っているので、そちらを参照願いたい。
.NET Interactive の C# REPL を Jupyter で | Aqua Ware つぶやきブログ

.NET Interactive を .NET 5 で動かしてみる

いきなり本題とは関係ない話になるが、せっかく .NET 5 がリリースされたところなので、 .NET Interactive を .NET 5 で動かしてみよう。

12/8 現在、NuGet で公式にリリースされている .NET Interactive は、 9月にリリースされた Preview 3 に少し更新が加えられた、 1.0.155302 だ。
これは、 .NET Core 3.1 上に構築されている。

一方で 11/27 頃のビルド (dotnet/interactive@61d2315) あたりでは、既に .NET 5 対応が済まされている。

更に、何故か Visual Studio Code の .NET Interactive Notebooks 拡張では、 .NET 5 に対応した 1.0.160204 がリリースされている。

このため、現時点で .NET Interactive で .NET 5 を扱う主な方法は、以下の通り。

main ブランチの binder コンテナにアクセス

Azure DevOps の CI ビルドの NuGet feed (dotnet-tools) から、 Glogal Tool を DL

実行例:
powershell dotnet tool install -g Microsoft.dotnet-interactive --version 1.0.160204 --add-source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json

VS Code Insider を起動し、 .NET Interactive Notebooks 拡張の Preview をインストール

残念ながら、 .NET Interactive インストール済み Jupyter の docker イメージのようなものは公式では用意されておらず、コンテナを使いたかったら自分でビルドするしかない。
(そのせいで、上記 binder の起動は遅い)

vscode 拡張だと、コード補完が ignore case で効くのでとても書きやすい。
以下、 vscode の .NET Interactive Notebooks 拡張のバージョン 1.0.160204 での実行を前提とするが、他の環境でも同様に動作するはずだ。

なお、起動した Notebook やコンソールの .NET CLR のバージョンを知りたければ、 System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription を実行すれば良い。
.NET 5.x.x と表示されれば、 .NET 5 で起動していることが確認できる。

Variable sharing とは

さて、ようやく本題。

.NET Interactive が面白いのは、ひとつの Notebook 内で、 C#, PowerShell, F# の言語間の変数を共有できる点だ。
悪いなあ、 VB.NET。このツールは3人用なんだ。

この変数を共有できる機能を、 variable sharing という。

使い方はとても簡単で、 #!share --from マジックコマンドで、参照する .NET カーネルと変数名を指定するだけだ。

但し、読み込まれている型の空間は共有されない点には注意だ。
例えば、 C# で定義したクラスのインスタンスを PowerShell で読み込もうとしたり、
PowerShell でロードされているモジュールで定義された型のインスタンスを C# で読もうとすると、エラーになってしまう。
詳しくは、 interactive/variable-sharing.md · dotnet/interactive のドキュメントを参照。

但し、 PowerShell でよく使われる PSCustomObject 型については特別対応が入っているらしく、いい感じに Dictionary に変換されて C# でも扱える。
なにそれ。 PowerShell 内部でも欲しい機能なんだけど。

Variable sharing の使いどころ

例えば…
例えば……
………

うーん、よい例が思いつかない…

そもそも、 C# でできることはだいたい PowerShell でできるし、その逆もまた然りなんだよな。
加えて PowerShell では、 Add-Type で手軽に C# のコードを埋め込めるし…

強いて挙げるなら、 PowerShell は、付属のコマンドレットや追加モジュールによって、 I/O 操作やリソースの読み込みにが強い一方で、パイプを交えたデータの処理はだいぶ遅いところだろうか。
例えば、 PowerShell でファイルの読み込みなどを行いつつ、大量のデータの処理は C# で行うといったような使い方はアリかもしれない。

#!pwsh $data1 = Get-ChildItem *.json -Recurse | Get-Content -Raw | ConvertFrom-Json; $data2 = Get-Clipboard;

#!csharp #!share --from pwsh data1, data2 data1.Where(kv => kv.Key == "tools")

#!csharp data2.First()

この程度のデータ処理なら PowerShell で全く問題ないレベルだが、処理するデータの数が増えてくれば C# で実行するメリットが出てくるだろう。

PowerShell で Git の reset/stash などを使う際に履歴を指定する方法

2020-10-04T23:29:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: PowerShell で Git の reset/stash などを使う際に履歴を指定する方法 - 雑木林

TL; DR

中括弧で表記する文字列は ' で囲みましょう。

はじめに

みなさんおなじみ、履歴を戻すコマンドは、下記の通りです。

gitで履歴を戻すコマンド（実行不可）

git reset HEAD@{0}

また、スタッシュを適用するコマンドは、下記の通りです。

gitでスタッシュを適用するコマンド（実行不可）

git stash pop stash@{0}

しかし、 PowerShell で上記を実行しようとすると、次のエラーが発生し、履歴リセット／スタッシュ適用できません。

PowerShellで履歴を戻そうとした際のエラー

error: unknown switch `e'

解決策

PoserShell では、中括弧に特別な意味があるため（スクリプトブロックと呼ぶらしい）、中括弧内の文字列をコマンドとして実行してしまうからみたいです。

about_Script_Blocks - PowerShell | Microsoft Docs

' で囲み文字列化することで、実行できます。

gitで履歴を戻すコマンド（文字列化）

git reset 'HEAD@{0}'

gitでスタッシュを適用するコマンド

git stash pop 'stash@{0}'

または、中括弧エスケープ処理をすることでも可能です。
PowerShell のエスケープシーケンスは ` ですよね。

gitで履歴を戻すコマンド（エスケープ処理）

git reset HEAD@`{0`}

git reset HEAD@{1} results in error · Issue #106 · dahlbyk/posh-git

おわりに

エラー文だけでは理解できず、地味に苦労しました。
PowerShell は ~~めんどくさい~~ 奥が深いですね。

UserPrincipalName	Password
[email protected]	hogehogepassword1
[email protected]	hogehogepassword2

UserPrincipalName	FirstName	LastName	DisplayName	Password	UsageLocation	AccountSkuId
[email protected]	Taro	Abe	user1(Abe)	hogepassword1	JP	hoge:O365_BUSINESS_PREMIUM
[email protected]	Ken	Sato	user2(Sato)	hogepassword2	JP	hoge:O365_BUSINESS_PREMIUM

grpID	userPN	role
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	[email protected]	member
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	[email protected]	owner