Powershell: powershell.exeを呼び出すための短い名前としてpwshを作成します

短いエイリアスも欲しいのですが、これが私たちが最初に出かけたときにposhうまくいかなかった理由です（私たちはそれについて詳しく話しました）。 表示された最新のパッケージあまりにもまだあることを。

他の提案も受け付けていますが、明らかな* shの提案のほとんどが採用されています。 唯一のwget / curlエイリアスの後で、あまり一般的ではない場合でも、他のパッケージとの衝突を避けたいと思います。

私はこのアイデア全体に夢中ではありませんが、 pwshどうですか？

私は、PowerShellの短縮として洗練されたものに熱心だったことはありません。 pwshの方が優れているように見えますが、インターネットですばやく検索すると、いくつかの問題が発生する可能性があります。 これを行う場合は、できるだけ短くすることをお勧めします。psだけはどうでしょうか。

OK-忘れてください-psがget-processのエイリアスであることに気づきました。 それはあまりにも混乱するでしょう

私は今、強い既視感を得ています。 😉

PowerShellの読みやすさ（エイリアスを使用しない場合）に感謝しているので、 powershell実行すると問題なく動作します。

psは、Linuxの既存のコマンドでもあります。

他のいくつかのアイデアは次のとおりです： pscmd 、 psc 、 monad 、 psh 、 pshell

これらの名前の収穫逓減は確かにありますが、実際に何かを保存するのか、それとも利用できる場合でも不要な混乱を加えるだけなのかについてです。

CoreSh 、 pcs 、 psc

あまりにも悪いモッシュが取られます。 pshが取得されます。 [pshell]は多くのヒットを返します。 興味深いことに、BingとGoogleの両方でmshを検索すると、PowerShell（Microsoft Shellと呼ばれます）で多くのヒットが発生しますが、Unixではmshが存在します（おそらくあまり使用されていません）。

😄S＃、P＃

@ PowerShell / powershell-委員会はこれについて話し合い、シンボリックリンク名を短くすることを受け入れていますが、すでに存在する人にしゃがむことはできません。 prshは問題ないようです。

待って待って！ 私はそれを手に入れました： ^sh -それとも**shか？ （jk）。

prshは理にかなっているようです-たとえば、 pwshよりも入力が簡単ですが、 pwrsh -1文字です。 より長い-「pwr」は「power」の既知の略語であることを考えると、検討する価値もあります。

別の、場合によっては_complementary_オプション：_自動変数_を提供します。その値は、現在のセッションを開始したバイナリのまったく同じパスを_常に_反映します。

bashはそのための$BASHがあります。

このアプローチの利点は、 $env:PATH /操作の変化に影響されないことです。

私たちはすでに$PSHOME持っています-間違いなく、 $PSようなものはそれほどストレッチではありません。

とはいえ、これは自動変数でグローバル名前空間を汚染しないことに関する議論に関連しています-＃4216を参照してください。

.Net Core、CoreFX、CoreCLR、PowerShellCore-「コア」をベースと見なすことができます。

pscoreは、 sh終わっていなくても、他の委員会のメンバーが拒否したとしても、私には問題ないようです。

pscoreまたはcoreps -LGTM。

monadとmsh （上記）を思い出すことができます。

私はpwrshが今のところ一番好きです。 pscoreも悪くはありませんが、6文字で少し長くなっています。 4文字以下がおそらく理想的ですが、 pwrsh必要な5文字で生活することができます。

「コア」という言葉を組み込むことについての私の懸念は、Unixプラットフォームでは有用な情報が含まれておらず、他のエディションと区別する必要がないことです。

@rkeithhill pscxはどうですか、ハ！ PowerShellコアエクスペリエンス。 しかし、それは私に別のpscsh 、PowerShellコアシェルを思い起こさせました。

私は同じ名前のいくつかに自分自身で引き裂かれています。 pwrshとpscoreの読みやすさが好きですが、5文字が制限であることに同意します。 5文字で最初の単語powerをカバーし、それ以上の場合は完全なものを入力することもできます。 monadは素晴らしいイースターエッグで読みやすいですが、PowerShellの背景を知らない人には混乱します。 4文字のprshもうまく機能します。

使用できる名前の最終リストを作成し、Edgeチームが行ったように公式の投票を行うとよいでしょう。 今後のPSコミュニティや公式イベントがある場合は、投票へのリンクを提供して、より多くの視聴者にリーチすることができます。

@ dragonwolf83 ：

pscshは危険なほどcsh近いです-避けるべき関連です。

繰り返しになりますが、特にエディションがいつか統合される可能性がある場合は、「コア」という単語を含めることにメリットはありません（そして、_Windows_では、人々は_Windows PowerShell_の短い名前なしで10年間快適に暮らしていたようです） 。

monadあいまいさについて合意しました。

私の個人的な投票は、 pwsh 、 prsh 、またはpwrshに対するものです。

PS：_Windows PowerShell_にも短い名前が必要な場合は、 w前に付けるだけで解決できますが、私のお気に入りの中で、キーボードをwprshとしてロールオフするだけです。私の投票はprsh / wprshペアの2つのエディションの短い名前のシナリオです。

「コア」という言葉を組み込むことについての私の懸念は、Unixプラットフォームでは有用な情報が含まれておらず、他のエディションと区別する必要がないことです。

:-) .Net Coreの名前を変更する必要がありますか？

@iSazonov ：

私はpsh投票します。衝突として引用したプロジェクトは、10年間リリースされておらず、いずれの場合もパッケージリポジトリに含まれていませんでした。

@ジェイクル：

psh ？ 私は知らない-あなたが私に尋ねれば、もっと「コア」が必要だ。

冗談はさておき、プロジェクトのステータスとパッケージリポジトリがないことについての優れた点。

pshも私の投票があります（Windows PowerShellの場合はwpsh ）。

（それぞれ「pshaw」および「むち打ち症」と発音します）。

pshも私の投票があります（Windows PowerShellの場合はwpsh ）。
（それぞれ「pshaw」および「むち打ち症」と発音します）。

Windowsでposhして、それらを洗練されたものと発音できないのは確かですか？ 🤡

戯言！ それはミシュポチャ全体にとってはあまりにも多くのミッシュマッシュです。 🤡

私はpshに投票します-衝突としてあなたが引用したプロジェクトは10年間リリースされておらず、どのような場合でもパッケージリポジトリに含まれていませんでした。

コピーライトの問題はありませんか？

著作権の問題はありませんか？

私は本当に_知っている_誰かが加わってくれることを願っていますが、私の_推測_はこれが2つの理由で問題にならないということです：

• pshは正式な製品名ではなく、単なる技術的な補助であるイニシャル（より大まかに言えば頭字語）のみです（ただし、一般的な使用法では、最終的には完全な製品名の一般的な省略形になる可能性があります。可能です。商標の頭字語/頭字語へ）。

• 商標の問題は多くの場合、既存の商標との_混乱_の可能性に関するものであり、ここで見たところ、少なくともソフトウェアの分野では衝突はないようです（事実上機能しなくなった既存のpsh作成者はいないと思います

誰かが実験したい/暫定的な解決策が必要な場合：

サポートされているすべてのプラットフォームで、PowerShellの内部と外部の両方でエイリアスを定義するすべてのエイリアスソリューションを次に示します。PSCoreの場合はpsh wpsh 、WindowsPowerShellの場合は

• PowerShellのエイリアスの外側を設定するにはONCE以下を実行します（のためのcmd.exe Windows上で、用bash Unix上）：

  # Note: 
  #   * On Unix, this will define alias `psh` for *interactive* Bash sessions,
  #     via initialization file ~/.bashrc (Linux) or ~/.bash_profile (macOS).
  #   * On Windows, this defines doskey.exe-based aliases `psh` and `wpsh`
  #     via registry key [HKEY_CURRENT_USER\Software\Microsoft\Command Processor],
  #     value 'AutoRun', and even though *any* cmd.exe instance will run
  #     these alias definitions, they only work in *interactive* ones.
  #     Note that both aliases open a new window.
if ($env:OS -eq 'Windows_NT') {
  $cmd = 'doskey wpsh=start powershell.exe & doskey psh=powershell.exe -nologo -command "psh"'
  $currVal =  try { Get-ItemPropertyValue 'HKCU:\Software\Microsoft\Command Processor' AutoRun } catch {}
  if (-not (Select-String -Quiet -SimpleMatch -Pattern "$cmd" -InputObject $currVal)) {
    if ($currVal) { $cmd += " & $currVal" }
    Set-ItemProperty 'HKCU:\Software\Microsoft\Command Processor' AutoRun $cmd
  }
} else {
  $cmd = 'alias psh=powershell'
  $initFile = ("$HOME/.bashrc", "$HOME/.bash_profile")[(uname) -eq 'Darwin']
  if (-not (Select-String -Quiet -LiteralPath $initFile -Pattern "^\s*$cmd\b")) {
    Add-Content -LiteralPath $initFile -Encoding utf8 "`n$cmd"
  }
}

• 以下を$PROFILEに入れて、PowerShell内で同じエイリアスを定義します-PSCoreとWindowsPSの両方で機能します。

  # ===
  # Portable alias definitions for PowerShell Core (`psh`) 
  # and, on Windows, for Windows PowerShell (`wpsh`) too.
  #
  # Place them in $PROFILE.
  #
  # * On Unix, invoking `psh` always runs the new instance in the current terminal window.
  # * On Windows, only invoking the same edition runs in the current console window.
  #   Invoking the respective other edition opens a new window; if you also
  #   pass a command, add -NoExit to keep the new window open.
  #
  # ===
  if ($env:OS -eq 'Windows_NT') { # on Windows
    if ($PSVersionTable.PSEdition -eq 'Core') { # running in a PS Core session
      # PS Core alias: Invoke the same binary that started the current session.
      Set-Alias psh "$PSHOME\powershell.exe"
      # Windows PowerShell alias
      function wpsh {
        # Assume a fixed location in SYSTEM32.
        $exe = "$env:SYSTEMROOT\System32\WindowsPowerShell\v1.0\powershell.exe"
        $psModulePathSav = $env:PSModulePath
        try {
          # Note: We must remove all *\PowerShell\* entries from $env:PSModulePath, because they are Core-specific
          #       and interfere with module loading in Windows PowerShell.
          # Note that Start-Process -UseNewEnvironment is NOT an option: see https://github.com/PowerShell/PowerShell/issues/3545
          $env:PSModulePath = (($env:PSModulePath -split ';') -notmatch '[/\\]PowerShell[/\\]') -join ';'
          # Start Windows PowerShell in a new window.
          $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
          Start-Process $exe <strong i="18">@htArgs</strong>
        } finally {
          $env:PSModulePath = $psModulePathSav
        }
      }
    } else { # running in a Windows PowerShell session
      # PS Core alias:
      Function psh {
        # Given that the PS Core *.exe is not in $env:PATH as of PowerShell Core v6.0.0-beta.5, determine its location.
        # Since multiple versions may be installed, find the highest version installed.
        # Unfortunately on PSv5.1- [semver] ([System.Management.Automation.SemanticVersion]) is not available, so we fall back to the *.exe files' last-write timestamp.
        # WISHFUL THINKING: Set-Alias psh ((Get-ChildItem -Directory $env:ProgramFiles\PowerShell | Sort-Object -Descending { [semver] $_.Name })[0].FullName + '\powershell.exe')
        $exe = ((Get-ChildItem -File $env:ProgramFiles\PowerShell\*\powershell.exe | Sort-Object -Descending LastWriteTime)[0].FullName)
        # Note: The Core-specific module directories are automatically added to $env:PSModulePath, so no other action is required.
        # Start PS Core in a new window.
        $htArgs = if ($Args.Count) { @{ Args = $Args } } else { @{} } 
        Start-Process $exe <strong i="19">@htArgs</strong>
      }
      # Windows PowerShell alias: invoke the same executable that started the current session.
      Set-Alias wpsh "$PSHOME\powershell.exe"
    }
  } else { # on Unix (Linux, macOS)
    # Simply invoke the same binary that started the current session.
    Set-Alias psh "$PSHOME/powershell"
  }

Pauaどうですか？ これは、美しいパウア貝（ニュージーランドの貝殻）への言及です。 そうでなければ、 pshも良いと思います。

あなたは（ニュージーランドの）ジーランドショアから貝殻を売っていますか？ （冗談です。確かに美しいです。）

免責事項：以下は[趣味]の言語学者にのみ関心があります。

音声的には、 pauaは、英語の非rhotic方言（たとえば、英国、ニュージーランド、オーストラリア）でのみ機能します。

そしてボストニアン。

@ PowerShell / powershell-committeeは、beta.8でこれを終了する必要があります

Posh6はどうですか

Posh6はどうですか

ファイル拡張子にバージョン番号を入れるよりも早く古くなるように感じます...;）

はい。ただし、それを起動するシェルスクリプトは、実行されているバージョンを認識します。

私はposhが好きですが、主な懸念はPoshと呼ばれるLinux用の既存のパッケージがあることだと思います。そのため、別のcurlインシデントを回避するために、次善の選択肢はpwshだと思います。

私はpwsh好きです。 10年前なら良かったのに。 msh恋しいです。

pshに投票します。
gnp / pshは5年近くコミットされていません。 それはアバンダンウェアかもしれません。

言いたくないのですが、これは強いコンセンサスを得るのが難しいかもしれないことの一つです。 ：\

この時点で、物事を終わらせ、あらゆる種類の衝突（合法よりも「誠実」）を回避するために、私はすべてpwshます。

このように聞いてみましょう。 pwsh使わない強い理由がある人はいますか？

pwshが実行可能ファイルの名前で、 powershellがシンボリックリンク/ショートカットである場合、誰かが心配するでしょうか。

ここで承認を行う前に、「現在の」バージョンとは何か、それとそのターゲットバージョンをどのように参照するかについて回答する必要があります。

@iSazonovはあなたの質問を理解できません。 それがあなたが求めているものであるならば、これはpowershell -v Nとは関係ありません。 これは単に使用できますpwshの代わりに、 powershell （我々はまだ綴る支持するだろうが、 powershell ）。

私の懸念は、powershell-> powershell-6.0.0-beta.7のようなシンボリックリンクについてです。
言語について言えば、インタラクティブセッションのエイリアスは快適な環境を提供するので好きですが、エイリアスはスクリプトでは大きな頭痛の種です。 PowerShellの短い名前についても同じことがわかります。速度タイプにはおそらく適していますが、ディレクトリツリー（シンボリックリンク）には実際に問題がある可能性があります。

別の考え。 スピードタイプを考えるべきですか？ この観点から、提案されたすべてのケースが適切であるとは限りません。
最後に考えたのは発音です。 興味深いことに、ロシア語では、PowerShellの誕生以来、「пош」（「posh」）と人名の短縮形「пошик」（「poshik」）を使用しています。 ロシア人なら誰でも「posh」や「psh」に投票すると思います。

明確にするために、 pwshは（PowerShellの用語では）エイリアスではなく、物理的に存在するcmd.exeまたはバッチファイルから呼び出すことができるものである必要があります。 2つの実行可能ファイルを使用せずに短い名前とpowershell両方をサポートする場合、実際にこれをどのように実装するかはわかりませんが（poweshell.exeは比較的小さいですが...）。

poshとpsh対pwshに関しては、 poshとpshの主な懸念事項は、それらがすでに存在していることです（それらがどれほど目立つかに関係なく）です）。 curlエイリアスは、既存のネイティブツールと競合するため、早い段階で問題が発生しました。（おそらくここでは過度に慎重になっています）ショートハンドで同様の状況を回避しようとしているため、 ' pwsh傾いています。 おそらく、 pwshと入力すると、十分な数の人がそれに慣れるでしょう:)

向こう側。 PowerShellで同じことをどのように解決しますか？ タイピングをシードするために、ユーザーエイリアスとIntelliSenseをお勧めします。
ここでの議論の1つでエイリアスについて議論したとき、現在のすべてのエイリアスは読み取り専用ではなく、ユーザーがエイリアスを削除/変更できるようにする必要があると述べました。 言い換えれば、エイリアスは排他的に標準であってはなりません。 基本的なコマンドレット名のみが標準である必要があります。 この観点から、「powershell」の「標準」エイリアスを提供するべきではありません。コミュニティやディストリビューターは、好きな名前を選択でき、その精神に対応する必要があります。また、IntelliSenseも提供できます。

@ SteveL-MSFT-「pwsh」はおそらく問題なく人々に固執すると思います。

そうは言っても、皆さんは「psh」を使用しない理由としてカール事件について言及しました。 平行線を描きすぎて自分（私たち）を隅に追いやるだけなので、問題があると思います！

「curl」は、Linuxの世界で最も使用されているツールの1つです。 「生きている」/「アクティブな」ソフトウェアに対してアバンダンウェアに拡張する必要があるのでしょうか。

カール事件が私たちにレッスンを教えてくれますが、間違ったものではありません。

@AdilHindistanのサポートでは（スレッドの長い得て、それを追跡するために難しい）sの-ポイント解析のアドバイス、私は@Jaykulをあらためて表明しましょう'：

私はpshに投票します-衝突としてあなたが引用したプロジェクトは10年間リリースされておらず、どのような場合でもパッケージリポジトリに含まれていませんでした。

言い換えれば、 pshが（主要な）パッケージリポジトリの一部ではなかったように見えるという事実（私はapt （Ubuntu、Debian）とyum （Fedora、 RedHat））-つまり、常に_ニッチな製品_--_ and_であり、10年以上活動がなかったために、すべての目的と目的で放棄されたと見なすことができ、完璧な候補になります。

（対照的に、 poshがapt経由でまだ利用可能なパッケージであるという事実は、そのメンテナンスステータスに関係なく、私の意見では失格となります。）

pshは実行可能なオプションであり、検討する必要があるという点に同意します。

ショートネームをシンボリックリンク/スタブとして_実装_する方法については、実際の実行可能ファイルの名前がpowershell[.exe]ままであると仮定します。

短い名前が、たとえばpshと仮定しましょう（説明されている名前の1つをランダムに選択するためだけです）。

Unixプラットフォーム

インストーラーは_さらに_次と同等のことを行う必要があります。

# Linux
/usr/bin$ sudo ln -s powershell psh

# macOS
/usr/local/bin$ sudo ln -s powershell psh

言い換えると、既存のpowershellシンボリックリンクを単に指すpshという名前の追加のシンボリックリンクを作成します。

macOSでは、これにより次のようなシンボリックリンクチェーンが生成されます。

/usr/local/bin/psh@ -> /usr/local/bin/powershell@ -> /usr/local/microsoft/powershell/6.0.0-beta.7/powershell

したがって、PS Core自体を含むすべての呼び出しシェルは、 powershell短い代替手段としてpshを使用できます。

ウィンドウズ

Windowsでは、状況はさらに複雑になります。

• 少なくともbeta.7の時点では、PS _Core_の_outside_から、PATHにあるのは_Windows_PowerShellだけです。
• ターゲットを絞った呼び出しには、WindowsPowerShellとPowershellCoreの明確な省略形が必要です。PSCoreの場合はpsh wpsh 、Windows PSの場合はaptおよびyumリポジトリ内）。

Windows PS

_Windows_ PSは、シンボリックリンクを次のように定義できます- $env:SystemRoot\System32\PowerShell\v1.0 （64ビット）と$env:SystemRoot\SysWOW64\PowerShell\v1.0 （32ビット）にそれぞれ1つずつ。

Set-Location $PSHOME
cmd /c mklink wpsh.exe powershell.exe

$PSHOMEが$PATH 、PSCoreやWindowsPS自体を含むすべてのシェルは、Windows PSをwpshとして呼び出すことができます。

PSコア

短縮ファイル自体は、デフォルトでPATHにあるディレクトリに配置できます。これにより、PS Coreの$PSHOME自体がPATHに含まれていなくても呼び出しが可能になります。

64ビットと32ビットの考慮事項は適用されないため（PSコアは64ビットのみ）、 $env:SystemRoot （通常はC:\Windows ）を選択できます。

残念ながら、PowerShell Coreは、別の名前のシンボリックリンクを介して呼び出された場合に実行を拒否するため、_シンボリックリンク_の使用は少なくとも現在はオプションではありません。

_elevated_ PSセッションから：

Set-Location $env:SystemRoot   # typically, C:\Windows
cmd /c mklink psh.exe "C:\Program Files\PowerShell\6.0.0-beta.7\powershell.exe"

psh.exe呼び出しは、次のように失敗します。

The managed DLL bound to this executable: 'powershell.dll', did not match own name 'psh.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

誰かがこれを回避する方法を知っているなら、私たちに知らせてください。

（不思議なことに、シンボリックリンクを_拡張子なしで_- psh.exe代わりにpshを定義すると、呼び出しは原則として成功しますが、パラメーターは渡されません。）

回避策は、スタブバッチファイルを使用することます）。

Set-Location $env:SystemRoot   # typically, C:\Windows
'@"%ProgramW6432%\PowerShell\6.0.0-beta.7\powershell.exe" %*' | Set-Content -Encoding ASCII psh.cmd

WindowsPowerShellやPSCore自体を含むすべての呼び出しシェルは、PS Coreを呼び出すための省略形としてpshを使用できます。

@ mklement0 Linux / macOSでシンボリックリンクを使用し、Windowsでバッチファイルを使用するという点で同じことを考えていました（Windows PowerShellではpowershellままなので何もしません

最も明白なことは、 powershellがプライマリで、 pshがリンクであるということですが、 pshがの名前になるように、おそらくそれを裏返す必要があると考えていました。 exeとpowershellがリンクです。 その理由は、Windows以外の新しい対象者がいて、Windows PowerShellと区別するために、PowerShell Coreを参照するためにpshを使用し、 powershellが提供されているように思われるためです。 app-compat（おそらく、移行する一部の人の筋肉の記憶）。 しかし、私は誰もがこのアイデアで売られているわけではないことを知っています。

psh非常に人気があることがわかったら、 powershellとpshを入れ替えることができます。

エイリアスを追加するには、 https：//stackoverflow.com/questions/2016722/one-dll-multiple-projectsが役立つ場合があり

pshがexeになり、PowerShellがリンクに追いやられるという考えは好きではありません。 あなたは、オーディエンスのサイズが不明で（少なくともそもそも）潜在的に小さいWindows以外での潜在的な使いやすさのために、10年間のオーディエンスの忠誠心を捨てています。

PowerShell v6をよく見ると、Windows以外のユーザーにPowerShellを採用するように説得するために、既存のWindowsユーザーが無視されているように見えます。 このプロセスはどこで終了しますか？

@RichardSiddaway PowerShellチームがWindowsユーザーをまったく無視しているという印象はありません。私は、主にWindowsPhoneを使用するWindowsユーザーです。 私は、Linuxの概念からではなく、cmdからpowershellに移行するという私自身の課題からこれを要求した人でした。

実際のところ、Windows PowerShellは成熟した製品ですが、クロスプラットフォームを念頭に置いて構築されていません。 これを機能させるには、最初はクロスプラットフォームに向けて初期投資を高くする必要があります。これにより、両方の世界にメリットがもたらされます。 今後数回のリリースで事態はさらに悪化するでしょう。

エイリアスとパラメータエイリアスを除いて、Windowsユーザーに悪影響を与えるものはあまりありません。 懸念される特定の問題がある場合は、それらの問題でそれを提起してください。 議論はプラットフォームにとって良いことであり、PowerShellに関する特別なことが移行中に失われないようにする必要があります。

@ SteveL-MSFTは、 pshまたはpwsh .exeにする理由をもう少し教えていただけますか？ それから得られる利益があれば、私はそれを支持する傾向があるかもしれません。

バッチファイルに痛い。 とにかく、Windowsでシンボリックリンクを機能させるには？ 私はcmdを介して別のレイヤーよりもむしろそれを持っています。

@ dragonwolf83時間が経つにつれて、人々は10文字ではなく3文字または4文字を入力することを好むと思います。したがって、 powershell入力は常にサポートしますが、長期的な観点からは、短いバージョンに最適化する必要があります。

WindowsPowerShellについてのコメントは的を射ています。

@ dragonwolf83 ：

バッチファイルに痛い。 Windowsでシンボリックリンクを機能させる方法はありますか？

私はあなたを聞く。 残念ながら、私の助けを求める声は今のところほとんど注目されていません。

powershell.exeは78kですが、psh.exeとして別の78kを使用するのは非常に悪いことです。

2つの重複する実行可能ファイルがあることは簡単な解決策かもしれませんが、ユーザーが2つの間に違いがあるかどうかを考え始めると想像できるので混乱を招く可能性もあります。PowerShellを初めて使用し、2つの異なる例（SOなど）を見た場合PowerShellを呼び出す/開く方法を示すと、違いがあると想定するため、すぐにどの例を選択する必要があるのか​​疑問に思い始めます...

IMOこれはばかげています。 cmd.exeはWindows10 1703でほとんど隠されているため、従来のシェルからpowershell.exeを起動することはめったにありません。

これの大ファンではありません-問題になるとpowershellを入力する頻度はどれくらいですか？ （また、バイクシェッドの問題全体;））Windows10およびServer2016で、「スタートメニューを右クリックするかWin + Xを押したときに、コマンドプロンプトをWindows PowerShellに置き換える」を設定すると、Win + x、i、またはLinuxの場合と同じくらい短くなります。 、お好みの名前で既存のシェルにエイリアスを追加します。

そうは言っても、どうでしょうか。

• ps1 -Windowsのファイル拡張子の後、短く、入力しやすく、覚えやすい
• psps -短くて入力可能ですが、「典型的なM $膨満感」のスラングにさらされています
• ips -Invoke-PowerShellの場合と同様に、RedHatまたはUbuntuリポジトリのパッケージではないようで、 yum provides "*/ips"はクイックチェックで衝突するバイナリがないことを示しています

このように聞いてみましょう。pwshを使わない強い理由がある人はいますか？

それは醜く発音できず、「powershell」自体よりも多くの音節を言い、入力するのは特に簡単ではなく、インターネットを話すpwnd / pwntから派生しているように見えます。

WindowsのデフォルトシェルとしてPowerShellがまもなく使用されるようになると、ファイル名（長さ）は重要ではなくなります。

PowerShellCoreは移植可能なプロジェクトです。Unixについても考える必要があります。

@ PowerShell / powershell-委員会はこれについて議論し、私たちが着陸した場所は、 powershell追加のショートカット/エイリアスなしでpwshと呼ばれるPSCore6バイナリを持つことです。 利点は、WindowsPowerShellまたはPowerShellCoreのどちらを使用しているかにかかわらず、Windows上であいまいさなしに明示的にすることです。 Windows以外では、入力が短く、他のシェルの命名との一貫性が高くなります。 お客様のフィードバックに基づいて、将来的にはいつでもpowershellリンク/ショートカット/エイリアスを追加できます。

私の投票はpsh.exeです。

@jandrusk PRは昨日すでにマージされているので、pwsh.exeになります。 ジェフリーはすでにこれについてここでツイートしてい

新しいPassWord / Per-Week / PoliceWoman SHellを長生きさせましょう！

私の投票はそれを放っておくことだったでしょう。

では、pwshをどのように発音しますか？

pwsh
p.wush
p.woosh
puh.wush

うまくいけば、それらよりも良いもの

私が使用してきた@jonathanmedd pwishのようにwishとp 。

_pwsh_が再帰的頭字語（_GNU_に類似）であることを考えると、なぜpwSHなのですか？ -「お願いします」と口を閉ざしたかわいいうさぎのように、「pweesh」をお勧めします。

冗談はさておき：

• 個人的にはpwshに落ち着くのは残念だと思いますが、すぐに慣れて、二度と考えないだろうと思います。

• 発音について：フルネームが十分に短いことを考えると、個人的にはその必要性はわかりません。PowerShellの世界に住んでいる人なら誰でも、マッピングは明白です。 （Unixの世界の例： zshは、単一の音節としてではなく、明らかにzee shellまたはzed shellと発音されます）。

P-Dub Shell ？

P Double U ShellまたはP Double U S Hは言うのが辛いです。 PowerShellよりも多くの音節がありますが、おそらくPowerShellとpwshを区別したいと思うでしょう。 bashがBourne-Again Shellと区別されるのと同じように。

PowerShellとpwshを区別したいと思うかもしれません

公式の完全な名称の面では、それが_WINDOWS PowerShell_対_PowerShell Core_だ-それ自体で_PowerShell_は、どの版を参照することができます。
コンテキストから明らかでない場合は、適切な修飾子を追加することで曖昧さが解消されます。おそらく、それほど頻繁に必要になることはありません（たとえば、純粋なUnixコンテキストの場合）。

長期的には、PowerShell Coreが「すべての」プラットフォームで実行されるエディションであることを考えると、_PowerShell_が_PowerShell Core_（「デフォルト」のPowerShell）の一般的な非公式の省略形になり、修飾子が-_Windows_-になっても驚かないでしょう。 Windows版を参照するためにのみ使用されます。

余談として：

bashがBourne-AgainShellと区別されるのと同じように。

bash _is_ _Bourne-AgainSHell_-その前身である_BourneSHell _（ sh 、
POSIXが言語を標準化する前）。

@ mklement0 pwshバイナリとPowerShell言語/シェルを区別することについて話しています。 PowerShellのさまざまな実装/プラットフォームを区別しません。 bashがバイナリとBourn-Again SHellを区別するために使用されるのと同じように。 はい、互換性がありますが、2つを区別する必要がある場合は、 pwshを発音する明確な方法が必要です。

プッシュ：笑顔：

かもね：

p shellまたはp w shell

@markekraus ：

ああ、なるほど、明確にしてくれてありがとう。

バイナリの_正確な_名前を伝えたい場合は、名前を_スペルアウト_する以外の発音は役に立ちません（これはposhようなものでのみ機能します）。

したがって、_PowerShellバイナリ/実行可能ファイル_を参照することは、すでに知っているすべての人にとってはうまくいくはずであり、他の人にとってはとにかくそれを詳しく説明する必要があります。

バイナリの正確な名前を伝えたい場合は、名前を綴る以外の発音は役に立ちません。

私たちはそれに同意しないことに同意する必要があります😃。

たとえば、「bash」や「posh」の場合と同様に、それが機能することへのあなたの_desire_は理解していますが、上記の苦労が証明しているように、「pwsh」では機能しません。 '今立ち往生しています。

「pwsh」では機能しません

まあ、その態度ではありません！ 😉私はそれをpwishと呼んでいますが、おそらくそうし続けるでしょう。 しかし、私は他の人が何か他のものを思い付くかどうかを確認するための対話を作成しているだけです。 pushは、一部の言語でのw発音を考慮すると適切です。 pwsh完全に償還できないわけではない、IMO。 多分誰もがp w s h落ち着くでしょう。 しかし、「ここで終わりました」と言って、決定された問題を検討するのは時期尚早です、IMO。

:)

あなたが正しい。

すでに知っている人（その短い名前をpwshにマップする方法をすでに知っている人）のために_慣例によって_確立された短い名前ではなく、PowerShellにまだ精通していない人に_正確なスペル_を伝えるという側面に焦点を合わせすぎたと思い

MSPoshはどうですか。 PowerShell.exeよりも短く、標準に準拠していますが、 PowerShell Heroの楽しい名前も兼ねていますか？

@ 1RedOnePowerShellのヒーロー/アバターは常に私の❤️ではPoSHちゃんになります

PWSHチームは名前の変更を急いでいたようです。 :-)

pscmd.exeに投票します

Windowsでcmdと入力すると、実際に表示されるはずです。 そしてそれは実際にcmdを置き換えています...

これが筋肉の記憶の問題である場合は、その問題を修正しましょう。

かっこいい新しい名前を見つけるのが楽しいだけなら、pscore.exeにする必要があります。それがそれだからです。

ちょうど私の2セント。

pwsh 、wwrldのfwremwstWbject-Wrientedシェル。 私はこのパターンを継続する2つの新しいコマンドレットを前方に探しています：

Get-Cwntent servers.txt | FwrEach-Wbject { 
    Invwke-Cwmmand -CwmputerName $_ -Scriptblwck { .. }
}

;）

-

Refの発音、「 powsh 」は「pouch」や「couch」のように柔らかな「s」で言いました。 （ショーンコネリーの印象派が「ポーチ」と言っていると考えてください）。

The managed DLL bound to this executable: 'pwsh.dll', did not match own name 'powershell.dll'.
A fatal error was encountered. This executable was not bound to load a managed DLL.

このエラーメッセージはこの問題に関連していると思います。 これを修正するにはどうすればよいですか？

BashはBourneAgain SHellであるため、実際の名前の問題に関しては、pwshに投票します。

PWSHに投票します。 そして、私はそれをプッシュと発音します。
私はコミュニティでposhを使用しているのをたくさん見たので、それが私の2番目の選択肢になりますが、MSはそれをposhと呼ぶのをやめようとしているのではないかと思います。

pwrに投票します！

@DaleMitchellどうやってそのエラーが発生したのですか？ 自分でビルドした場合、build.psm1をリロードしましたか？

私はposhを使用しているコミュニティでたくさん見ましたが

たとえば、 https：//github.com/dahlbyk/posh-git 。

pwshはposhと発音されます。 @SaschaNaz POSHは、残念ながらすでにシェルとして存在しています

それがどのように発音されるかについての@PowerShell / powershell-committeeの投票を見逃しましたか？ :)

Microsoft Next Generation Command Line Interface Shell Experience 2017と発音できるのではないか、あるいは単にpowershellと発音できるのではないかと思いました。

Microsoft Next Generation Command Line Interface Shell Experience 2017 Service Pack2がリリースされるまで使用しないでください...

残念ながら、POSHはすでにシェルとして存在しています

ええ、ユーザーが高級感を求めてsudo apt install poshを試した後、まったく異なるシェルを取得すると、非常に混乱します。

ところで、 poh-shまたはpah-sh ？ 確かに後者？

パッケージ名は引き続きPowerShellであり、変更はありません。

sudo apt install powershell

簡単な（意見のある）最新の討論記事：

• _バイナリのファイル名_について：決定が下され、公表されました： pwshです。

• _pronunciation_について：

  • バイナリの正確なスペルを_uninitiated_に伝えることができるものはありません-それをスペルアウトする以外に選択肢はありません。

  • _initiated_にとって、必要なのは「PowerShell」だけです。通常、コンテキストから、バイナリの_product_または_file名のどちらを参照しているかが明らかになります（ @markekrausの懸念）。 後者の場合、印心者はそれを頭の中で自動的にpwshに変換します。
    必要に応じて、「コア」と「ウィンドウ」を追加して明確にします。

  • 言うまでもなく、決定的な非公式の1音節のモニカへの熱烈な探求は続きます...
    いずれにせよ、 pwshにメンタルマッピングする行為が必要なので、「Posh」などの非公式に確立されたものも継続して使用される可能性があります。

クロスプラットフォームのスクリプトサポートにMKSToolkitを使用していた昔は、 ksh.exeを使用していましたが、常にKornShellと呼んでいました。 したがって、バイナリはpwsh 、PowerShellと呼びます。

バイナリ名がpwrshあったが、その船が出航していれば、この「バイナリ名をどのように発音するか」の問題全体を回避できたと思います。

「昔」（15年前は数えますか？）に戻ると、私のチームはバイナリを「kish」と呼び、「KornShell」はシェルの一般的な議論のためのものでした。

例：

「ooserbinkishと入力し、Enterキーを押します。これでKornShellにいます」

15年前はカウントされますか？

それは私が推測する人にいくらか相対的です。 KornShellでの私の経験は24年前に始まりました。 15年前、私の娘は幼児でしたが、それはそれほど昔のことではないようです。 Yikes-時は飛ぶ。

私のチームはバイナリを「キッシュ」と呼びました

そのように発音されたのを聞いたことがないとは言えません。 :-)

そのように発音されたのを聞いたことがないとは言えません。 :-)

うん。 そのチームの外では、それは常に「ksh」または「KornShell」でした。 しかし、それは一種のポイントです。人々が「pwsh」（「PowerShell」がない）という文字をどのように発音するかについて話し合い、コンセンサスがあるかどうかを確認します。 それは完全に真剣な議論ではなく、発音できない単語であるため、公式の発音になることはありません（チームを軽視することはありません- push ）。 しかし、人気のある候補者が勝ち、プレゼンテーションでそれを聞き始めることにはメリットがあります。

Microsoftで働く前は、Unixの人で、常にksh KornShellとcshCShellと呼んでいました。 当時、単語として発音しようとした人は誰も覚えていません：P

誰かがこのような重大な変更が行われた理由を簡潔に説明できますか？ 私は（明らかに！）ループから外れていて、 @ powerschillとチャットしてい重要であることを

私の復習は、貢献プロセスについて今読んだばかりです。 最初はRFCが必要だと思いましたが、これがどのように適用されないかはわかります。 次に、変更を解除するためのポリシーを確認しています（https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md）。 この変更がどのバケットに分類されたかなどについて、全員がコメントできますか？

明確に解決されたものをかき立てようとするのではなく、仕様や問題を読みに行かない興味のある他の人と効果的にコミュニケーションできるようにしたいと思っています。 ありがとう！

@ halr9000 https://github.com/PowerShell/PowerShell/issues/4214#issuecomment -335989245

私の2c。 これは大きな重大な変更です。 実稼働シナリオを終了する際の既存のバッチファイルが多すぎると、PowerShellスクリプトを開始するためにすでにpowershell.exeが使用されています。 同じ実行可能ファイルを起動するための追加の短いコマンドを提供することに反対していませんが、「powershell」を削除すると大きな混乱が発生します。 両方（エイリアスなど）を使用する方法を提供してください

@RudolfHenning以前のバージョンのpowershell.exeが間違って呼び出されることになります。バージョン。

PowerShell Core 6.0がリリースされた後も、公式およびコミュニティのモジュールとスクリプトの多くはCoreで使用できないフルCLRオブジェクトにアクセスする必要があるため、多くのWindows中心のタスクにWindows PowerShell（5.1以下）を使用する必要があります。

また、5.1と6.0の間には非常に多くの重大な変更があるため、以前のバージョンから6.0にスクリプトを移植する場合は、調整が必要になる可能性があります。 とにかくコードに触れる必要があるので、バッチはpowershell.exeからpwsh.exe切り替えることができます。 PowerShell Coreを移植していない場合、何も壊れることはなく、スクリプトはWindows PowerShellを使用してpowershell.exe実行され続けます。

説明ありがとう。
私はWindowsと一部のLinuxOSの両方を使用しているため、スクリプトの互換性が懸念される場合があります。はい、Linux上のPowerShellライブラリは厳密にベータ版です。 Linuxマシン用のスクリプトの作成には、かなりの時間と労力を費やしてきました。
とにかく、良い仕事を続けてください！

TeamCityのPowershellランナーは、実行可能ファイルがpowershellと呼ばれることを前提としています。 Linuxには互換性の問題を引き起こすPowershell5がないため、Linuxパッケージは引き続きpowershellシンボリックリンクを作成する必要があります。 これは不必要な破損でした。

なに、4月に到着したの？ 次に、PowerShellコマンドレットから母音を削除しますか？ これは冗談に違いない。

「powershell-commandxxxx」を使用する古いスクリプト（docker）は、新しいベータ9リリースでは機能しなくなりました。

暴風雨を待っている

「最も重要な」場所またはエントリポイントを大幅に変更する理由はたくさんありますが、コマンド名を6バイト短くして読みにくくすることは、その1つではありません。
過去に、コード内でより良い/より長い名前を使用することを決定する頻度。これは、読み取りが書き込みよりも簡単である可能性があるためです。

私の2セントをカスト
よろしく
ヴェルナー

私は怒りと失敗を理解しようとしています。

人々は新しい名前が物事を壊していると不平を言っていますが、PowerShellCoreはまだベータ版です。 IMO、誰かが本番コードでベータ技術を使用している場合、彼らは災害を招いています（私はここで丁寧な言葉を使用しています）。 アルファリリースとベータリリースの性質は、重大な変更で満たされることです。 これがベータ版ではないという幻想はありません。 ベータ版はバージョン名6.0.0-beta.9組み込まれています。

この名前の変更は、WindowsPowerShellには影響しません。 現在Windowsで行っていることを壊してはいけません。 Linuxで何かをしている場合は、ベータ版をベータ版であると非難するのではなく、ベータ版を使用しているという事実を理解する必要があります。 ベータリリース間の重大な変更を処理できない場合は、安定版リリースがRTMになるまで他のものを使用することを検討してください。

人々はその名前が気に入らないようです。 あなたはいつもあなたが望むものを手に入れることができるとは限りません。 PowerShell.exeは長くて入力が面倒なので、個人的には嫌いです。 pwshは、私が台無しにする文字が少なくとも少なくなっています。 ディスカッションスレッドを見ると、複数のオプションがpwshよりもはるかに悪い（IMO）で議論されていることがわかります。

新しいバイナリ名の主な動機の1つがWindows関連である場合、人々はこれをクールなLinuxの子供たちと溶け込もうとする厄介な試みと誤解しています。 はい、linux-yの名前が選ばれましたが、どうでしょう？ PowerShellは* nix市民にもなりました。 人々がその事実に慣れる時が来たと思います。 Coreの目標の1つはクロスプラットフォームの移植性です。したがって、そうです、決定はWindows以上のものを念頭に置いて行うことができます。

それは私の2セントの価値です。

Coreの目標の1つは、クロスプラットフォームの移植性です

クロスプラットフォームの移植性の一部は、同じコマンドが同じことを行う場合、両方のプラットフォームで機能する必要があるということです。 この変更の前は、使用しているOSに関係なく、 powershellを実行して、正しいものを取得できました。 今、私はもうそれをすることができません。

使いやすいソフトウェアを作るということは、何百万もの小さなことをきちんと世話することを意味します。 奇妙で直感的でない名前を使用すると、それに反します。

使用しているOSに関係なく、 powershell実行して、正しいものを取得できました。 今、私はもうそれをすることができません。

正確ではない。 Windowsでpowershellを実行してWindows PowerShellを取得してから、Linuxでpowersehllを実行してPowerShellCoreを取得できます。 これで、WindowsまたはLinuxでpwshを実行して、PowerShellCoreを入手できます。 だから今、私たちはあなたが望む状態にあります。 以前と同じように、一貫性のない状態でした。

奇妙で直感的でない名前を使用すると、それに反します。

それは普遍的に好まれていないことは明らかですが...あなたはどのような代替案を提案しますか？ 私は誰もが名前について不満を持っているのを見ますが、この名前の変更が対処する根本的な問題に代わるものはありません。 私が言ったように「あなたはいつもあなたが望むものを手に入れることができるとは限らない」

どんな名前を選んだとしても、人々は不幸になるでしょう。

@markekraus

• これはベータ版であることがわかっています。重大な変更は問題ありません。
• 私は* nixでより良いPSを作るのが大好きです。なぜなら、それは私の（PS）知識をWindowsから* nixに移すのに役立つからです。

私のフィードバックは、使いやすさと、いくつかの名前の変更を強制する暴風雨の懸念と、終わりのない議論についてでした。

Windowsでpowershellを実行してWindowsPowerShellを取得してから、Linuxでpowersehllを実行してPowerShellCoreを取得できます。 これで、WindowsまたはLinuxでpwshを実行して、PowerShellCoreを入手できます。 だから今、私たちはあなたが望む状態にあります。 以前と同じように、一貫性のない状態でした。

WindowsとCoreを分離することは、名前を変更してから「短い名前を作成する」というより良い理由です。

それについてもっと明確なコミュニケーションをとることをお勧めします（問題のタイトル、リリースノートなど）
私はこの号の最初の2〜3ページを読みましたが、議論は長さについてのみでした。

その他のフィードバック：
過去数週間、Dockerと* nixのPS-Coreで多くのコーディングを行いました
私はそれが好きですが、いくらかの磨きが必要です。
アイデア/提案：
名前がPowershellからpwshに変更された場合は、バージョンを6.0から1.0に変更してみませんか（「.Net5.0」から「dotnetcore1.0」への変換と同じ説明です。
基本的に、COREはバージョン1.0、バージョン6、特に* nixに似ています。

よろしく
ヴェルナー

@WernerMairl 6.0.0＃5165の代わりに1.0を使用することについてのオープンディスカッションがあります。 そのスレッドにアクセスして、読んでコメントしてください。

また、これを使用していて、磨く必要があると思われるものに遭遇したので、未解決の問題をチェックして、遭遇した問題に対処しているかどうかを確認してください。 未解決の問題がある場合は、投票またはコメントします。そうでない場合は、新しい問題を開いて修正できるようにしてください。 私たちコミュニティメンバーの何人かは、優先度の低い問題の修正に積極的に取り組んでおり、Microsoft Teamは、優先度の高い、より難しい問題に取り組む素晴らしい仕事をしています。 また、自分で寄稿者になるのに遅すぎることはありません！

問題の説明と変更の伝達については、この変更の伝達とその必要性について改善の余地があることに同意します。 このリポジトリでのさまざまな人の役割は少し混乱する可能性がありますが、私はPowerShellチームの一員ではなく、（本質的に）フォーラムのモデレート権限を持つコミュニティの貢献者にすぎません。 PowerShellチームについて話すことはできませんが、彼らはこの事実を自分たちで理解していると思います。

彼らの弁護において、これはコミュニケーションするのがちょっと難しいです。 苦情の大部分は、WindowsPowerShellとPowerShellCoreの類似点と相違点を理解していないことに起因しているようです。 この変更を効果的に伝えるには、 7月14日のブログ記事で説明されている内容を再ハッシュする必要があり

正確ではない。 Windowsでpowershellを実行してWindowsPowerShellを取得してから、Linuxでpowersehllを実行してPowerShellCoreを取得できます。 これで、WindowsまたはLinuxでpwshを実行して、PowerShellCoreを入手できます。 だから今、私たちはあなたが望む状態にあります。 以前と同じように、一貫性のない状態でした。

私はあなたが何を意味するのか理解していますが、これは私が望んでいることではないと反論します。 私のステートメントには、暗黙の隠された仮定があります。共通の機能を使用している限り、PowerShellとPowerShellCoreは完全に同等であると期待しています。 これまでのところ、これは私のすべてのユースケースで問題なく進んでいます。

@sandersaaresあなたの経験は幸運の1つだと思います。 それは確かに私の経験と一致しません。 また、その仮定は危険だと思います。 これはメジャーバージョンであり、基盤となるプラットフォームがまったく異なる、重大な変更が大量に文書化されています。 これは、ほぼ100％の下位互換性を備えた以前のメジャーバージョンのPowerShellとは異なります。

実行可能ファイル名の変更は主に入力を節約するためであるという誤った想定をしている人もいます。 PRに使用されたこのオリジナル号は、短い名前を求めるタイトルから始まったので、人々がこの印象をどのように受けたかがわかります。

委員会が決定に関して行うすべてのコメントを全員が読むことを期待するべきではないため、コミュニケーションを改善できることに同意します。 特に、決定の要約が簡単に失われるこのような物議を醸すもの

また、特にWindows PowerShellに関して、PowerShell Core6とは何かについて根本的な誤解があるようです。 Windows PowerShell 5.1は、Windows上のPowerShellのインボックスバージョンです。 私のチームも必要に応じてサポートを続けています。 お客様が必要な限りWindowsPowerShellに依存し続けることを完全に期待しており、少なくとも今後10年間は​​そうなる可能性があります。 WMF5.1のダウンロードがついにWMF4.0のダウンロードを上回ったのはつい最近のことだと思います。

PowerShell Core 6は、クロスプラットフォームであるだけでなく、オープンソースでもあるPowerShellの次の進化形です。 @markekrausが指摘したように、これはメジャーバージョンの変更であり、WindowsPowerShellでは考えられないような重大な変更をより柔軟に受け入れることができます。 また、PowerShell Core 6は、（Windows PowerShellだけでなく他のバージョンのPSC​​ore6でも）並行して動作するように明示的に設計されていることにも注意してください。 powershellと入力すると、Windowsで何が得られるかがあいまいになることはありません。 ここで、6.0と1.0の議論は、公開されるずっと前にすでに行われており、再開される可能性は低いことに注意してください。

@ SteveL-MSFTの名前変更に関するブログ投稿がいいでしょう。 Windowsでの問題の明確な例を使用して、名前が変更される主な要因について説明します。 また、poshとpshがカットを行わなかった理由を説明するのもよいでしょう。

たぶん、解凍+インストール中にpwshのエイリアスとして「powershell」を設定します。 これは、私がこの問題を追跡するまで、私が数日間取り組んでいたビルドを壊しただけです。

編集：Linuxの場合

@markekrausには、

https://get-powershellblog.blogspot.sg/2017/10/why-pwsh-was-chosen-for-powershell-core.html

今日、私はここでSOでpwshの最初の使用法を見ましたが、その人がこのスレッドについて知っているとは思えません...

pwshの発音について公式の裁定を得ることができますか？ PNG仕様では、セクション1に発音が含まれています。PowerShell用の発音も提供される場合があります。 別のSCSIの「ぎこちない」/「セクシーな」状況は望ましくありません。

私には「プーシュ」のように見えます。

@apjanke一般的に受け入れられているpwsh発音はposh

私のために働きます。 正式な確認ありがとうございます！

代替発音について： ^[1]

• _Pish Posh！_

• _Poppyposh！_

• _以前はPowerShellとして知られていたシェル_（グルジア語では_TSFKAP_）

• _あえてその名前を話さないシェル（その実行可能ファイルの名前は発音できないため）_（ウェールズ語の話者が好む）。

^{[1] [パロディー。}