アカウント名:
パスワード:
VisualStudio2013とLinuxGCCの両方でコンパイル可能なソースコードを書くにはと組み合わせを試した結果OKだったのがこれでした
WindowsとLinuxの両方で動くPowerShellスクリプトの場合はWindows上のPowerShell ISEで編集するためにはUTF-8 BOMありじゃないと駄目だけどBOMありにすると 「#!/usr/bin/pwsh」の#!の前にBOMが来てしまうのでLinuxで実行できない、という問題があったなぁ
WindowsとLinuxの両方で動かすならバージョン6.0以降で確定なわけでそんなスクリプトをISEで作るのが悪いVSCodeでやれ
VS Code と PowerShell でのファイルのエンコードの概要 [microsoft.com]
PowerShell 6 以降では、既定のエンコードはすべてのプラットフォームで BOM なしの UTF-8 です。
VS Code の既定のエンコードは BOM なしの UTF-8 です。
>WindowsとLinuxの両方で動かすならバージョン6.0以降で確定なわけで
どうしてWindowsのPowerShellとLinuxのPowerShellが同一のバージョンだと思ったの？Windows PowerShell 4.0や5.0でつくったけど、PowerShell Coreでも動く、という方向性で試してただけですよ
関係ないけど、VS CODEはプログラミング時に関係ないところで改行して、1画面に収めようとしたり、プロポーショナルフォントがデフォルトになっていたりするので、エディタとしては使えないので大嫌いです。というか、エディタなんだからWORDに合わせて半角スペースの位置で改行しないようにしてほしいんだが。MSの中の人は本当にこれで良いと思ったのか、ちょっと聞いてみたい。
Macが問題なんですよね。AppleはBOM付きUTF-8を駆逐したいようで、XcodeがBOM付きUTF-8ファイルを勝手にBOM無しに書き換えてしまう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
BOM付きUTF8で改行コードはLF(UNIX) (スコア:1)
VisualStudio2013とLinuxGCCの両方でコンパイル可能なソースコードを書くにはと組み合わせを試した結果OKだったのがこれでした
Re: (スコア:0)
WindowsとLinuxの両方で動くPowerShellスクリプトの場合は
Windows上のPowerShell ISEで編集するためにはUTF-8 BOMありじゃないと駄目だけど
BOMありにすると 「#!/usr/bin/pwsh」の#!の前にBOMが来てしまうのでLinuxで実行できない、という問題があったなぁ
Re: (スコア:0)
WindowsとLinuxの両方で動かすならバージョン6.0以降で確定なわけで
そんなスクリプトをISEで作るのが悪い
VSCodeでやれ
VS Code と PowerShell でのファイルのエンコードの概要 [microsoft.com]
PowerShell 6 以降では、既定のエンコードはすべてのプラットフォームで BOM なしの UTF-8 です。
VS Code の既定のエンコードは BOM なしの UTF-8 です。
Re: (スコア:0)
>WindowsとLinuxの両方で動かすならバージョン6.0以降で確定なわけで
どうしてWindowsのPowerShellとLinuxのPowerShellが同一のバージョンだと思ったの？
Windows PowerShell 4.0や5.0でつくったけど、PowerShell Coreでも動く、という方向性で試してただけですよ
Re: (スコア:0)
関係ないけど、VS CODEはプログラミング時に関係ないところで改行して、
1画面に収めようとしたり、プロポーショナルフォントがデフォルトになっていたりするので、
エディタとしては使えないので大嫌いです。
というか、エディタなんだからWORDに合わせて半角スペースの位置で改行しないようにしてほしいんだが。
MSの中の人は本当にこれで良いと思ったのか、ちょっと聞いてみたい。
Re: (スコア:0)
Macが問題なんですよね。AppleはBOM付きUTF-8を駆逐したいようで、XcodeがBOM付きUTF-8ファイルを勝手にBOM無しに書き換えてしまう。