PowerShell -Part 5

**デフォルトの名無しさん** · 2021/03/18(木) 00:29:52.04

前スレ
PowerShell -Part 4
https://mevius.5ch.net/test/read.cgi/tech/1577862511/

次スレは>>980が立ててね！！

**デフォルトの名無しさん** · 2021/11/25(木) 09:20:52.19

>>808 ありがとうございました
ls -r |? lastwritetime -lt "2015/10/10" -OutVariable list
知らなかった…調べてみるとすべてのコマンドレットに備わってるんですね

**デフォルトの名無しさん** · 2021/11/25(木) 09:38:35.33

>>809
-OutVariableは -ov が省略形.
あと tee -Va list でもできちゃう.

**デフォルトの名無しさん** · 2021/11/26(金) 10:20:48.79

>>807
gl -stack

**デフォルトの名無しさん** · 2021/11/26(金) 11:04:55.34

遅レスだけど>>583にも関連ありそうなのでアンカー付けとく、slじゃなくてpush/pop-locationだけど

CDPATH的なモノはsl -で参照できることから存在してるとおもうけど、もっと柔軟に数の引数取りたい、とかなら簡単なシェル関数書けば良いかと
function cd($bwd=1){iex "cd -;" * $bwd}
さらに
{iex "sl ..;" * $up},
{iex "sl +;" * $fwd}…等
(cdのremove-alias、引数を読んでディスパッチ等はよしなに)

まあ気が散るからlocationスタックに慣れた方がいいとは思う

**デフォルトの名無しさん** · 2021/11/29(月) 19:58:38.42

$hoge = Invoke-Command -ComputerName 192.168.0.1 -Credential $cred -ScriptBlock {C:\script\cpu.bat}

こんな感じでリモートPCのCPUの情報を取得したんだけど、
リモート側では返り値の型が Hashtable で連想配列なんだけど、実行する側のPCだと Object[] になって配列になるんだけど
これって仕様なの？
連想配列のまま$hogeで受け取る方法とかない？

**デフォルトの名無しさん** · 2021/11/29(月) 20:04:41.43

無い

**デフォルトの名無しさん** · 2021/11/29(月) 20:07:54.41

無いのかｗ
PowerShell初めて触ってるんだけど、こいつ癖が強いなぁｗ

**デフォルトの名無しさん** · 2021/12/04(土) 15:49:34.45

パイプのあくの強さに辟易してからが本番

**デフォルトの名無しさん** · 2021/12/04(土) 15:57:56.73

パイプの魅力に取り憑かれたらもう後には戻れない

**デフォルトの名無しさん** · 2021/12/04(土) 20:29:02.53

>>816
パイプってそんなにアク強かったっけ？
むしろ配列の方がトラップ満載な気がするが

**デフォルトの名無しさん** · 2021/12/04(土) 20:33:23.88

パイプラインが気に入らなかったら使わなきゃ良いんだけど
配列は気に入らなくても使わざるを得ないんだよな

**デフォルトの名無しさん** · 2021/12/04(土) 20:59:45.48

初代プレステみたいな拡張子以外ないの？
もうちょっとかっちょいい拡張子使いたい

**デフォルトの名無しさん** · 2021/12/04(土) 21:10:22.01

pwshも起動遅いよな
NGenも上手く行かんし。起動の遅さには目をつぶって使ってる感じ？

**デフォルトの名無しさん** · 2021/12/04(土) 22:01:12.10

毎回pwsh起動時に最新バージョンのpwshかWebサイトに確認しにいってる予感

**デフォルトの名無しさん** · 2021/12/05(日) 16:39:28.02

24時間ごとに最初のセッションでバージョンチェックが走るので、テレメトリーを無効にすればちょっとだけ起動が速くなるかも

https://github.com/PowerShell/PowerShell/issues/16234

POWERSHELL_UPDATECHECKは通知の制御だけで、バージョンチェック(を含む通信)はテレメトリー自体を止めないとダメみたい

**デフォルトの名無しさん** · 2021/12/05(日) 21:30:10.95

PowerShellを使っている人はWindows Terminalも使っていること多いでしょ
どっちも素のコマンドプロンプトに比べて起動に時間がかかる

**デフォルトの名無しさん** · 2021/12/05(日) 22:44:22.34

WSL2 で、Linux も使っている人は、Windows Terminal が便利。
ctrl + c でコピーできる

Linux の端末では、右クリックメニューからコピーしないといけない

**デフォルトの名無しさん** · 2021/12/05(日) 23:06:07.82

無変換キーで@が入力されるの治ってほしい…

**デフォルトの名無しさん** · 2021/12/05(日) 23:08:46.06

>>826
なにそれ

**デフォルトの名無しさん** · 2021/12/05(日) 23:17:25.58

Windows Terminal上でPowershellを使ってるとき、IME OFFに割り当てた無変換キーを空打ちすると@が入力されちゃう

**デフォルトの名無しさん** · 2021/12/05(日) 23:46:17.42

>>828
再現せんなあ

**デフォルトの名無しさん** · 2021/12/06(月) 00:19:03.74

これか
https://twitter.com/nejigami/status/1381587748260249601
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2021/12/06(月) 16:19:41.17

psreadlineでバインドし直せばいいんでないの？

**デフォルトの名無しさん** · 2021/12/06(月) 16:45:47.86

>>828
Ahkで無変換をime off機能に割り当てて対策してる。

**デフォルトの名無しさん** · 2021/12/06(月) 16:54:29.37

psreadlineに渡る前にwtに吸われてるのなら無力だったな
めんご

**デフォルトの名無しさん** · 2021/12/08(水) 18:02:05.74

>>832
AutoHotkeyで解決した、ありがとう

**デフォルトの名無しさん** · 2021/12/11(土) 17:33:02.92

今回リモートPCの使用状況をlog化して通知するシステムに利用したんだけど、
みんなは何にPowerShell使ってんの？やっぱり反復処理とか？イマイチ使いみちが思いつかないｗ

**デフォルトの名無しさん** · 2021/12/11(土) 18:31:42.90

分かってる人には当たり前のことなのかもしれないけど、 Set-PSReadLineOption -EditMode Emacs で
Emacs風味キーバインドにしたらCtrl+DでPowerShellが終了するね

**デフォルトの名無しさん** · 2021/12/11(土) 19:33:39.75

Ctrl+Dでの終了はzshでも有効にしてるので、違和感なく使ってました

**デフォルトの名無しさん** · 2021/12/11(土) 19:42:02.74

日常的に使ってるのは、VPN接続とリモート接続のログイン自動化スクリプトですね

**デフォルトの名無しさん** · 2021/12/11(土) 21:55:48.50

>>834
そんな大層なことしなくても
gci -pa HKLM:/system -rec -inc keyboard* -ea ignore
とかでキーマップが引っかかったと思うから、$profileにブチこんどけばいいんじゃないの、シェル閉じた時のリストア処理も書けるし

**デフォルトの名無しさん** · 2021/12/11(土) 21:58:38.54

ターミナル(wt.exe)の問題なら.jsonにキーマップ書けたはずで、それが一番礼儀正しいが

**デフォルトの名無しさん** · 2021/12/11(土) 22:11:14.55

レジストリはすぐどこ触ったか分からんくなるから$profileか、pwshの外ならuser\**\startupにコマンド書いて設定した方がいい
少なくとも何を触ったかは記録に残る
できれば初期値についてのコメントも

シェル/環境変数みたいにシャドウイングできるといいんだけど

**デフォルトの名無しさん** · 2021/12/12(日) 00:04:01.85

wsl --help の出力結果をパイプやファイルにリダイレクトすると、PowerShellとWSLが不?戴天の仇らしいことがよくわかる

**デフォルトの名無しさん** · 2021/12/12(日) 21:13:44.01

Windows PowerShell Inventor Jeffrey Snover Interview
https://evrone.com/jeffrey-snover-interview

**デフォルトの名無しさん** · 2021/12/13(月) 13:52:11.42

>>842
とりあえず|out-file -enc 色々噛ませてみては

**デフォルトの名無しさん** · 2021/12/14(火) 06:17:10.79

なんで不?戴天になってしまったのかと思ったら環境依存文字使ってたからか

不倶戴天 (環境依存文字なし)
不俱戴天 (環境依存文字あり)

**デフォルトの名無しさん** · 2021/12/14(火) 15:19:22.77

お前らlinuxマシンにpwsh入れてる？

**デフォルトの名無しさん** · 2021/12/14(火) 15:49:09.33

入れるわけないだろ
こんなもんWindows以外では絶対使わん

**デフォルトの名無しさん** · 2021/12/14(火) 15:54:44.60

たぶん、PowerShell が、UTF-8 だからじゃないの？

コマンドプロンプトで、
wsl --help > a.txt
とすると、UTF-16LE になり、VSCode・サクラエディタでも見れる

でも、Windows Terminal(WT)では、PowerShell・コマンドプロンプト・WSL のLinux の3つが使えるけど、
そのコマンドプロンプトでやったら、文字化けして見れない

WT は、UTF-8 だから文字化けするのかも

だから、アプリによる

**デフォルトの名無しさん** · 2021/12/14(火) 16:00:11.41

>>848
違うぞ
PowerShellの惨めな現実を受け入れろ

**デフォルトの名無しさん** · 2021/12/14(火) 19:12:38.50

パワーー

**デフォルトの名無しさん** · 2021/12/14(火) 20:06:47.20

はい

**デフォルトの名無しさん** · 2021/12/15(水) 12:02:30.22

まあでもWindows上で使ってるぶんには安定してるな。
当たり前だけどｗ

**デフォルトの名無しさん** · 2021/12/15(水) 20:55:34.12

v7.2.1
https://github.com/PowerShell/PowerShell/releases/tag/v7.2.1

**デフォルトの名無しさん** · 2021/12/16(木) 03:32:22.22

PowerShell上で非ANSIコードページ文字列をパイプやリダイレクトするには以下のようにcmd /C を使うしかない
cmd /C 'wsl --help > aaa.txt'
「ねぇどんな気持ち？」のクマAAをPowerShell愛好家に贈りたい

**848** · 2021/12/16(木) 12:30:02.79

コマンドプロンプトを使わずに、PowerShell で、
wsl --help を文字化けせずに、ファイルへ保存する方法はないのか？

>>848
修正

>でも、Windows Terminal(WT)では、PowerShell・コマンドプロンプト・WSL のLinux の3つが使えるけど、
>そのコマンドプロンプトでやったら、文字化けして見れない。
>WT は、UTF-8 だから文字化けするのかも

Windows Terminal(WT)のコマンドプロンプトで、
もう一度やってみたら、正常に表示された！

ちなみにコマンドプロンプトも、WTのコマンドプロンプトも、両方とも、CP932 でした

chcp
#=> 932

**デフォルトの名無しさん** · 2021/12/16(木) 14:46:23.47

Correct output in CMD, but incorrect output to a file in PowerShell #16012
https://github.com/PowerShell/PowerShell/issues/16012

**デフォルトの名無しさん** · 2021/12/16(木) 15:06:10.72

PowerShellの定番質問に知ったかぶりしてOutputEncodingを変えろと回答する人って自分で試さないんだろうか？
それとも質問を理解できるだけの国語力がないのか？

**デフォルトの名無しさん** · 2021/12/16(木) 15:11:12.80

負けた気がするけどロケールはもう諦めてen_us、圧力掛けるのはおまいらに任せた

あえて真っ白linuxでは使わんけどwslは快適になるな
$profile |add-member -noteprop
で属性付けて
. $profile.common; .$profile.platform
とそーすしてる

**デフォルトの名無しさん** · 2021/12/16(木) 15:23:47.31

そんなことより
左辺コレクションの-eqのフィルタの罠に見事に引っ掛かったわ

**デフォルトの名無しさん** · 2021/12/16(木) 15:41:05.53

-eq(ual elements are...)と読み慣わしてる

**848** · 2021/12/16(木) 16:19:44.83

OutputEncoding を変えるぐらいでは、出来ないだろ。
PowerShell(PS)は、迷走しまくっている

UTF-16LE とか、あるのか？

PS 6 では、BOM 無しUTF-8 も出来るらしいけど

**848** · 2021/12/16(木) 16:24:12.96

Windows は、CP932, BOM 有りUTF-8/BOM 無しUTF-8, UTF-16LE が入り乱れて、
外部と日本語でやり取りできないw

一方、Linux は、UTF-8 で統一されているから、全く問題ない。
Ubuntu は、UTF-32 らしいけど、外部には関係ない

**デフォルトの名無しさん** · 2021/12/16(木) 16:37:31.00

>>861
Input Encodingがシステムコードページ一択(日本語版Windowsだと932)になってることが原因だよ
UTF16-LEの文字列をSJISとみなしてOutputEncodingに変換するから文字化けしているのが真相

このPowerShellのおバカ仕様のせいでMINGWのUTF-8対応済みアプリの恩恵をまったく活かせない

**848** · 2021/12/16(木) 18:10:47.68

>UTF16-LEの文字列を、SJISとみなして

すごい。文字化けの謎を解明してくれたのか！

**848** · 2021/12/16(木) 18:13:34.65

と言うことは、逆変換すればどうかな？

SJIS → UTF16-LE

**848** · 2021/12/16(木) 18:19:40.99

それか、あらかじめデータを、SJIS へ変換しておいてから渡すとか

Ruby では、色々な携帯の機種依存の日本語を変換するのに、
最長6パスとか掛かるものもあるらしい

**デフォルトの名無しさん** · 2021/12/16(木) 18:50:41.75

[console]::OutputEncoding = [System.Text.Encoding]::Unicode

v5環境だけどこれでファイル出力の文字化けは解消できた
ただ改行コード\nが全部\r\nになる

**デフォルトの名無しさん** · 2021/12/16(木) 18:55:45.31

v7だと多分問題はない、よろしくやってくれてるんだと思う
mingwは使ってないから知らんが少なくとも標準パッケマネのwingetで入るやつ(gnuwinポート)でエンコで困った事はない

**デフォルトの名無しさん** · 2021/12/16(木) 19:06:43.69

>>867-868
デタラメを書くな
君らは問題を理解できてない

**デフォルトの名無しさん** · 2021/12/16(木) 19:15:07.46

とりあえず環境を(ターミナルも)書いてくれないとアドバイスのしようがない
>>856の対処は試した？

**デフォルトの名無しさん** · 2021/12/16(木) 19:24:43.19

>>870
以下コマンドをそれぞれコマンドプロンプトとPowerShellで実行して、aaa.txtに何が書き込まれているか確認してくれ
wsl --help > aaa.txt

あと「>>856の対処」とは何を指すのか具体的に示して

**デフォルトの名無しさん** · 2021/12/16(木) 19:27:32.35

マイクロソフトが関与するオープンソース・コミュニティーは問題が解決してないのに解決したことにしてしまうずさんな所が多い
バグ票を閉じることを優先する隠蔽体質あると思う

**デフォルトの名無しさん** · 2021/12/16(木) 19:34:07.64

共産圏の人間が仕切ってるのかと思うような閉じられ方する、まさにノルマ

**デフォルトの名無しさん** · 2021/12/16(木) 20:11:17.38

そうだね

**デフォルトの名無しさん** · 2021/12/16(木) 20:20:13.49

マイクロソフト文化圏。

**デフォルトの名無しさん** · 2021/12/16(木) 21:09:01.98

>>871
> is not a raw-bytes conduit to a file in PowerShell, unlike in cmd.exe.

Instead, PowerShell always decodes output from external programs (into .NET strings) before further processing (but not when printing directly to the display), based on the character encoding stored in [Console]::OutputEncoding.

Therefore, before your external-program call, you must (at least temporarily) set [Console]::OutputEncoding to match the actual character encoding used in your external program's output; e.g., [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

**デフォルトの名無しさん** · 2021/12/16(木) 21:15:42.41

従来型のパイプラインを選べない時点で設計思想がおかしいんですよ
$(xxx) みたいな特殊表現によるパイプが提供されてしかるべき
というかPowerShellのパイプラインを特殊表現に閉じ込めるべき

**デフォルトの名無しさん** · 2021/12/16(木) 21:56:24.21

OutputEncodingとコードページがごっちゃになってるのもよくない
OutputEncodingをUTF8に指定したら、cmd /? で英語ヘルプが返されるようになってしまう
この挙動は、コマンドプロンプト上のchcp コマンドでコードページを変えたときのcmd /?の挙動と同じ

**デフォルトの名無しさん** · 2021/12/16(木) 22:23:10.88

>>877
そもそも従来型のパイプラインは生バイト晒してたように聞こえるんだが、テキストモード(ascii)IOを忘れてないか

fopen等システムコールに行儀良く"b"フラグ渡してれば問題はないが、そうでない時にcmdはtypeや |を処理する際にコンソールのファント設定見に行く等奇怪な挙動をしてた
でもたまに制御文字をtypeして死んだり…

テキストモードを排除できれば可能かも

**デフォルトの名無しさん** · 2021/12/16(木) 22:31:55.77

gnuとかのプログラムは今でもioモード切り替えフラグ付いてたりするね

生バイトが欲しければProcessInfoとかからstdin/stdout引っこ抜いてIO.BinaryWriterに渡すとか

**デフォルトの名無しさん** · 2021/12/16(木) 22:47:57.71

文字列中に紛れたeof文字相当のバイトを見ても読み込みを続ける挙動は多分windows的には正しくないよな
そんな文字無くしてしまえ、と思うけど

**デフォルトの名無しさん** · 2021/12/17(金) 06:27:47.69

wsl　--helpのみっともない改行はUTF-16のL"\r\n"をテキストモードで出力するwslの変態行為がそもそもの原因だし

https://docs.microsoft.com/en-us/cpp/c-runtime-library/unicode-stream-i-o-in-text-and-binary-modes?view=msvc-170

**デフォルトの名無しさん** · 2021/12/17(金) 06:36:45.15

PowerShell固有のパイプラインに、|, >, >> を使うのをやめて
例えば $|, $>, $>> のような特殊表現に閉じ込めてほしいんだが
今さら無理か

**デフォルトの名無しさん** · 2021/12/17(金) 07:27:36.04

昔、MINGWのcatコマンドが0x0aを勝手に0x0d,0x0aへテキストモード変換する迷惑行為で人知れず苦しんだ人は多かったと思う

**デフォルトの名無しさん** · 2021/12/17(金) 08:47:10.04

c標準ライブラリの"t"フラグはホスト側でよしなに変換してくれという表明だけど、たぶん行論理セパレータ\n↔\r\n変換してくれるやつくらいに考えてる人が多いんじゃねえかな

**デフォルトの名無しさん** · 2021/12/17(金) 09:02:49.38

"t"はc規格には無いか、無指定の"w"フラグ等がテキストモードにデフォルトするというだけで
cっぽいopen関数備えてる言語(pythonとか)だと"b"との区別を意識させる為に"wt"とか受け付けるけど

**デフォルトの名無しさん** · 2021/12/17(金) 09:38:27.97

マイクロソフト謹製アプリが率先してやらかしてるってところが肝

**デフォルトの名無しさん** · 2021/12/17(金) 10:04:59.46

それと直接関係あるかは再現しないのでちょっと不明
>>871はconhostをsjisに設定してない？

**デフォルトの名無しさん** · 2021/12/17(金) 10:07:35.81

v7.2/wt(preview)
[console]のioデフォルトはutf8(=旧nobom)になってた

**デフォルトの名無しさん** · 2021/12/17(金) 10:09:02.77

>>888
CP932は日本語OSの規定の設定だよ
再現しないとか何言ってるのかわからない
作られたファイルaaa.txtの文字コードの確認さえできないんなら回答しなくていいよ

**デフォルトの名無しさん** · 2021/12/17(金) 10:14:30.90

>>890
原因分かってんのなら変えなよ…
win10パッケージ版(us_en)に日本語パック追加で入れるとデフォルトはこうなると思う

**デフォルトの名無しさん** · 2021/12/17(金) 10:27:09.40

あとwin11非対応マシンでms配布のロールバック用iso(非ローカライズ版)イメージで再インストール→日本語パック選択した人も該当するはず
oem版はsjisが多いと思う

**デフォルトの名無しさん** · 2021/12/17(金) 10:32:50.05

>>891
Windows Terminalでも起きるんだからconhost.exeは関係ないぞ

**デフォルトの名無しさん** · 2021/12/17(金) 10:42:00.46

>>893
conhostも[console]もシステムのcpから拾ってくる
wtに関してはsetting.jsonからも設定できる
様々なエンコーディング切り替えられないソフトが混在してて、グローバルに切り替えるのがためらわれるならば
ps/cmd>ms-settings:~(スタート>歯車のやつ)からアプリ毎にエンコーディング設定するのがおすすめ

**デフォルトの名無しさん** · 2021/12/17(金) 10:56:53.95

エンコーディング機能にAutoDetectがあれば良いだけなんだがな
簡単なことを難しくしてしまうのは無能の証なんだよ
PowerShellみててつくづくそう思う

**デフォルトの名無しさん** · 2021/12/17(金) 11:26:52.18

オートディテクトはギルティ、頭抱える事になるぞ
素性の良いデータで大体動けばいいような自動化なら、古き良きnkfでも噛ませ
ポータブルにしたいならPSGalleryに純pwsh実装のモジュールが転がってる、クオリティは知らん

i/oエンコーディングをシェルレベルで扱えるのはバベルの塔なwindows環境では重宝する

**デフォルトの名無しさん** · 2021/12/17(金) 11:27:13.62

PowerShellのパイプラインそれ自体がすでに低速なのに文字コードの自動判定すらないとか無能すぎでしょ

**デフォルトの名無しさん** · 2021/12/17(金) 11:29:06.56

>>896
古き良きnkfを噛ませられないからもめてるですよ
パイプでnkfに入力された時点で汚染されてるから
時すでにお寿司なのがPowerShell

**デフォルトの名無しさん** · 2021/12/17(金) 12:26:32.74

リダイレクトの挙動が不自然に感じるのは、ホストの概念で躓いてるのでは
ホストはコンソールとも限らないし、coreバンドルのコンソールホスト以外にもiseやらaspやら色々あるわけで
なんで設定が分かれてるのか考えるべき

**デフォルトの名無しさん** · 2021/12/17(金) 12:35:31.53

>>899
別にいろんなホストがあってもいいんだよ
昔ながらの標準入出力と棲み分けして提供すべきだったってこと
だけど、十把一絡げにしたせいで昔ながらのパイプ処理まで低速になってしまった

**デフォルトの名無しさん** · 2021/12/17(金) 12:48:55.55

>>900
>>856からrelatedで飛べる
https://github.com/PowerShell/PowerShell/issues/1908
で提案されてるような構文はあったら確かに便利かと思う

もちろんcoreの設計とは相容れないから、追加モジュールかwindows pwsh(新)でリリースすることになると思うけど
イイね押しとこう

**デフォルトの名無しさん** · 2021/12/17(金) 13:16:49.94

むしろPowerShelll固有の構文を新しい構文に移行させてほしいくらいだわ
パイプラインにテキスト縛りがある時点でPowerShellは欠陥品なんだよ

**デフォルトの名無しさん** · 2021/12/29(水) 20:28:55.03

PowerShellは以下コマンドをFunction化できない。
[console]::OutputEncoding = [System.Text.Encoding]::GetEncoding(932); $OutputEncoding = [Text.Encoding]::GetEncoding(932);

Function内でしかスコープが有効でないことが原因。$global:OutputEncodingを変えてもダメ。
なのでchcpコマンド相当のことをやろうとしたら手入力するしかない

なんというか、PowerShellは他のシェル言語でできいることができない残念なシェル言語。
オワコン化待ったなし

**デフォルトの名無しさん** · 2021/12/29(水) 20:49:49.82

([console])::OutputEncodingをFunction外にも適用できないことにはchcp相当の機能は実現できない
Powershellからchcpを呼ぶとcmdシェルを介してコマンドプロンプトの初期値が表示されるだけであり、グローバル設定とは無関係

([console])::OutputEncodingが効いたかどうかは、cmd /? で戻されるヘルプ文字列が日本語かどうかで判断できる

**デフォルトの名無しさん** · 2021/12/29(水) 20:57:34.10

UNIXシェルは糞of糞
やっぱりPowerShellだよな

シェルスクリプトは文字通りの逐次実行
sleepy-yoshi.hatenablog.com/entry/20090917/p1

**デフォルトの名無しさん** · 2021/12/29(水) 23:03:59.28

>>903-904
ドットソースで実行してもだめなの？
function f1 {～}
. f1

**デフォルトの名無しさん** · 2021/12/29(水) 23:16:02.98

>>906
説明不足だった
やりたいことはコマンド入力じゃなくてSet-PSReadLineKeyHandler -Keyを使ったキーバインドなんだけど
ドット. で反映してくてもScriptBlockやFunctionのスコープに閉じ込められてしまうから解決にならない

**デフォルトの名無しさん** · 2021/12/29(水) 23:39:26.16

ま、そういうエンコーディング切り替え機能をどれだけ充実させても既存のbashやCMDのようなプロセス間通信はできないのでやるだけ無駄ってのはわかってる