私はprintfコマンドを使用しています強く打つUbuntuのWSLから。
この文書化された構文を使用しようとしています。
\ xHH 16進値HHのバイト（1〜2桁）
これはprintf "\x0A"（キャリッジリターン）と他のいくつかの値に適用されます。
printf "\xFF"しかし、うまくいかないか、printf "\xFE"いくつかの処理でUtf-16ファイルの内容（BOMを除く）をパイプする前に、BOM Utf-16プレフィックスを挿入するために使用したいと思います。
この値（過去0xF8を含む）に対してエラーが発生します。
-bash: printf: 書き込みエラー: 入出力エラー
ベストアンサー1
これを元々コピーしてくれた@Steeldriverに感謝します。私はそれを自分で行うことができませんでしたが（少なくとも最初は）あなたとSteeldriverの両方を確認し、そのおかげでもう少し深く掘り下げることができました。
これは、報告書に報告された行動の発現と見なされます。このGithubの問題。この問題は特定のWSLの問題ではなく、以前のWindowsコンソールホストで問題である可能性があるため終了しました。
コンソールホストは、少なくとも20年以上前の「古い」Windowsターミナルインターフェイスです。この問題が報告されたかどうかはわかりませんが、とにかく解決される可能性はほとんどありません。
Windowsコンソールホストは、最新のターミナル機能を備えたMicrosoftによって開発された（比較的）新しいオープンソースターミナルであるWindowsターミナルに置き換えられています。現在、Windows 11ではデフォルトの端末として実行されます。 Windows 10でも実行されます（デフォルトの端末ではありません）。
Windows端末では問題が発生しないことを確認しました。
WSL2がリリースされる前にGithubの問題が発生したため、Steeldriverがなぜ1つのシステムでしか見えず、最初は見られなかったのかを推測することができました。興味深いことに（少なくとも私にとっては）この質問ただWSL2ではなくWSL1で発生します。これは、それをトリガーするWSL1のシステムコール変換インターフェースとは一部互換性がない可能性があることを意味します。 WSL2のLinuxカーネルにはこの問題はありません。
したがって、解決するには、次のいずれかを実行します。
- Windows端末（またはWindowsのコンソールではなくホスト端末）を使用する
- またはWSL2インスタンスを使用してください。
使い続けることができるので、前者を好む。両方WSL1とWSL2はどちらもアップグレードされたWindowsターミナル機能を利用します。