$ '\ r'：コマンドが見つかりません - CentosOSのcPanelを介したクラウドサービス用のファイルエンコード

Question 1

最初の数行だけ読みました（長すぎます）。ただし、\rこれはMS-Windowsコンピュータで編集していることを示します。 MS-Windowsは互換性のない方法で行末（）を実行します\r\n。他のシステムには（\n）があります。

解決策：

MS-Windowsを使用しないでください
正しい行末を使用するように構成できるエディターを使用してください。
dos2unixインポート時にファイルを挿入します。

Answer

最初の数行だけ読みました（長すぎます）。ただし、\rこれはMS-Windowsコンピュータで編集していることを示します。 MS-Windowsは互換性のない方法で行末（）を実行します\r\n。他のシステムには（\n）があります。

解決策：

MS-Windowsを使用しないでください
正しい行末を使用するように構成できるエディターを使用してください。
dos2unixインポート時にファイルを挿入します。

Question 2

行末の問題は、文字セットに直接関連していません。たとえば、Windowsで使用される「コードページ1252」には、UTF-8と同じキャリッジリターン（CR）および改行（LF）文字があります。_{（そしてEBCDICが言及されているので、両方とも別の改行文字があるようです。実際に使用する奇妙なシステムはまったく異なる問題です。）}

したがって、エディタに改行/改行のみを含むUnixスタイルの行末を生成させるには、別の設定を見つける必要があります。しかし、FTPを介してシステムにファイルを転送すると言われましたが、可能であれば、この方法で正しく作成されたファイルを転送するのに邪魔になることはありません。

これで、どのスクリプトが「予期しないファイルの終わり」エラーが発生したかを示していませんが、これは通常、シェルに閉じる引用符が必要な場合、または複合コマンドを完了するために特定のキーワードが必要な場合に発生します。シェルがその逆を見ると、これはキーワードとして認識されませthenん。fiifdodonethen\r

しかし、CRをコメントアウトする方法はまだ機能しています。 CR+LF 行末があっても、Bash は次の内容をよく読むことができます。

if true; then #
    echo moi  #
fi            #

しかし、ハッシュバンラインはもっと問題です。特に、Linuxはインタプリタ名の後ろのすべてを単一の引数としてスタックするので、CRを無視する方法を考えることはできません。ただし、シェルでエラーが発生した場合は、おそらくシェル（少なくとも一部のシェル）でスクリプトを実行しています。

Answer