我正在嘗試從官方檔案中安裝 Operator Lifecycle Manager (OLM)——一種幫助管理在集群上運行的 Operator 的工具，但我不斷收到以下錯誤訊息。什么可能是錯的？
這是命令的結果：
curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.22.0/install.sh | bash -s v0.22.0
/bin/bash: line 2: $'\r': command not found
/bin/bash: line 3: $'\r': command not found
/bin/bash: line 5: $'\r': command not found
: invalid option6: set: -
set: usage: set [-abefhkmnptuvxBCEHPT] [-o option-name] [--] [-] [arg ...]
/bin/bash: line 7: $'\r': command not found
/bin/bash: line 9: $'\r': command not found
/bin/bash: line 60: syntax error: unexpected end of file
我嘗試洗掉現有的 curl 并下載并安裝了另一個版本，但問題仍然存在。大多數在線解決方案都是針對 Linux 用戶的，它們都會導致 Windows 路徑設定和檔案問題。
我還沒有找到解決使用curl.
我很樂意接受任何幫助。
uj5u.com熱心網友回復：
在 Windows 上使用 PowerShell ，當 PowerShell 將它們傳遞給 時，您必須明確確保由 發出的 stdout 行curl.exe與 Unix 格式的 LF-only 換行符分隔\nbash，因為bash與其他 Unix shell 一樣，不能識別 Windows 格式的 CRLF換行符，\r\n：
避免該問題的最簡單方法是通過以下方式呼叫cmd /c：
cmd /c 'curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.22.0/install.sh | bash -s v0.22.0'
cmd.exe的管道 ( |) 和重定向運算子 ( >) 與 PowerShell（見下文）不同，它們充當原始位元組管道，因此它只是將任何位元組curl.exe輸出流式傳輸到接收bash呼叫，而不會改變。
修復PowerShell端的問題需要更多的作業，并且本質上更慢：
(
(
curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.22.0/install.sh
) -join "`n"
) "`n" | bash -s v0.22.0
注意：`n是一個PowerShell 轉義序列，它產生一個文字 LF 字符，類似于\n在某些bash背景關系中。
筆記：
需要注意的是，從 PowerShell 7.2.x 開始，不支持通過管道傳遞原始位元組：外部程式標準輸出輸出總是在讀取時解碼為 .NET 字串，并在寫入時根據首選項變數重新編碼到一個（其他）外部程式。
$OutputEncoding- 有關更多資訊，請參閱此答案，以及GitHub 問題 #1908以了解未來對外部程式之間的原始位元組流和重定向到檔案的潛在支持。
也就是說，PowerShell 總是將來自外部程式的輸出解釋
curl.exe為text，并通過管道將其逐行發送為 .NET 字串物件（PowerShell 管道通常執行 (.NET)物件）。- 請注意，這些行（字串）本身沒有尾隨換行符；也就是說，有關最初分隔行的特定換行符序列的資訊在該點丟失（PowerShell 本身可互換地識別 CRLF 和 LF 換行符）。
但是，如果接收命令也是一個外部程式，PowerShell會在每一行添加一個尾隨平臺原生換行符，在 Windows 上這是一個 CRLF 換行符- 這就是導致問題的原因。
通過預先收集陣列中的行，使用
(...)，它們可以作為單個的、LF 分隔的多行字串發送，使用-join運算子，如上所示。請注意，PowerShell 也將尾隨平臺原生換行符附加到這個單行多行字串，但輸入末尾的雜散
\r\n實際上會被 忽略bash，假設最后一個真正的輸入行以 結尾\n，這就是"`n"運算式末尾的extra確保。但是，在某些情況下，此尾隨 CRLF 換行符確實會導致問題 - 請參閱此答案以獲取示例和通過平臺原生 shell 的解決方法。
uj5u.com熱心網友回復：
首先，我需要清楚一些事情：
- 根據問題的標簽，我看到我們在 PowerShell 而不是 linux/unix 甚至 Windows cmd shell
- 盡管如此，我們使用的是 Unix
curl（可能是curl.exe），而不是Invoke-WebRequest. 我們知道這一點是因為-sL爭論。如果 Powershell 使用別名，我們會看到完全不同的錯誤。
接下來，我需要簡單地談談行尾。Windows 默認使用兩個字符的 LF/CR 對 ( ) 作為行尾\n，而不是 Unix/linux 中看到的和 bash 期望的單個 LF ( ) 字符。\n\r
有了所有這些背景，我現在可以解釋導致問題的原因。這是這個單管道字符：
|
這是一個 PowerShell 管道，而不是 Unix 管道，因此該操作將curl程式的輸出放在 PowerShell 管道中，以便將其發送到bash解釋器。每行都是管道上的一個單獨專案，因此不再包括任何原始換行符。PowerShell 管道將在使用系統的默認行結尾呼叫 bash 之前“更正”此問題，在本例中是 Windows 使用的 LF/CR 對。現在，當 bash 嘗試解釋輸入時，它會\r在每一行之后看到一個額外的字符，并且不知道如何處理它。
訣竅是我們在 Powershell 中洗掉這些多余字符的大部分操作在我們完成后仍然會通過另一個管道發送。我想我們可以告訴 curl 在不使用管道的情況下將檔案寫入磁盤，然后告訴 bash 運行保存的檔案，但這很尷尬，需要額外的作業，而且速度要慢得多。
但我們可以做得更好一點。默認情況下，PowerShell 將 curl 回傳的每一行視為管道上的一個單獨專案。-join我們可以“欺騙”它，而不是使用該操作將一個大專案放在管道上。這將為我們提供一個大字串，可以作為單個元素進入管道。它仍然會以一個額外的\r字符結束，但是當 bash 看到它時，腳本已經完成了它的作業。
在另一個答案中找到了使這項作業的代碼，他們應該得到解決方案的所有功勞。我的帖子的目的是更好地解釋正在發生的事情：為什么我們會遇到問題，以及為什么解決方案有效，因為我必須通讀該答案幾次才能真正得到它。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/523957.html
上一篇：傳播物件并添加標志node.js