<p>I am trying to install Operator Lifecycle Manager (OLM) — a tool to help manage the Operators running on your cluster — from the <a href="https://operatorhub.io/operator/gitlab-runner-operator" rel="nofollow noreferrer">official documentation</a>, but I keep getting the error below. What could possibly be wrong?</p>
<p>This is the result from the command:</p>
<pre class="lang-bash prettyprint-override"><code>curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.22.0/install.sh | bash -s v0.22.0
</code></pre>
<pre class="lang-bash prettyprint-override"><code>/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
</code></pre>
<p>I've tried removing the existing curl and downloaded and installed another version but the issue has still persisted. Most solutions online are for Linux users and they all lead to Windows path settings and files issues.</p>
<p>I haven't found one tackling installing a file using <code>curl</code>.</p>
<p>I'll gladly accept any help.</p>

<p><strong>Using PowerShell <em>on Windows</em></strong>, <strong>you must explicitly ensure that the stdout lines emitted by <code>curl.exe</code> are separated with Unix-format LF-only newlines, <code>\n</code>, <em>when PowerShell passes them on to <code>bash</code></em></strong>, given that <code>bash</code>, like other Unix shells, doesn't recognize Windows-format CRLF newlines, <code>\r\n</code>:</p>
<p>The <strong>simplest way to <em>avoid</em> the problem is to call via <code>cmd /c</code></strong>:</p>
<pre><code>cmd /c 'curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.22.0/install.sh | bash -s v0.22.0'
</code></pre>
<p><code>cmd.exe</code>'s pipeline (<code>|</code>) (as well as its redirection operator, <code>&gt;</code>), unlike PowerShell's (see below), acts as a <em>raw byte conduit</em>, so it simply streams whatever bytes <code>curl.exe</code> outputs to the receiving <code>bash</code> call, unaltered.</p>
<p><strong>Fixing the problem on the <em>PowerShell</em> side</strong> requires more work, and is inherently <em>slower</em>:</p>
<pre><code>(
  (
    curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.22.0/install.sh 
  ) -join &quot;`n&quot;
) + &quot;`n&quot; | bash -s v0.22.0
</code></pre>
<p><sup>Note: <code>`n</code> is a <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Special_Characters" rel="nofollow noreferrer">PowerShell escape sequence</a> that produces a literal LF character, analogous to <code>\n</code> in certain <code>bash</code> contexts.</sup></p>
<p>Note:</p>
<ul>
<li><p>It is important to note that, <strong>as of PowerShell 7.2.x, passing <em>raw bytes</em> through the <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Pipelines" rel="nofollow noreferrer">pipeline</a> is <em>not</em> supported</strong>: external-program stdout output is invariably <em>decoded into .NET strings</em> on <em>reading</em>, and <em>re-encoded</em> based on the <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Preference_Variables#outputencoding" rel="nofollow noreferrer"><code>$OutputEncoding</code> preference variable</a> when <em>writing</em> to an(other) external program.</p>
<ul>
<li>See <a href="https://stackoverflow.com/a/59118502/45375">this answer</a> for more information, and <a href="https://github.com/PowerShell/PowerShell/issues/1908" rel="nofollow noreferrer">GitHub issue #1908</a> for potential <em>future</em> support for raw byte streaming between external programs and on redirection to a file.</li>
</ul>
</li>
<li><p>That is, <strong>PowerShell invariably interprets output from external programs, such as <code>curl.exe</code>, as <em>text</em>, and sends it <em>line by line</em> through the pipeline, <em>as .NET string objects</em></strong> (the PowerShell pipeline in general conducts (.NET) <em>objects</em>).</p>
<ul>
<li>Note that these lines (strings) do <em>not</em> have a trailing newline themselves; that is, the information about what specific newline sequences originally separated the lines is <em>lost</em> at that point (PowerShell itself recognizes CRLF and LF newlines interchangeably).</li>
</ul>
</li>
<li><p>However, <strong>if the receiving command is <em>also</em> an external program</strong>, <strong>PowerShell <em>adds a trailing platform-native newline</em> to each line, which on Windows is a CRLF newline</strong> - this is what caused the problem.</p>
</li>
<li><p>By collecting the lines in an array up front, using <code>(...)</code>, they can be sent as a <em>single, LF-separated multi-line string</em>, using the <a href="https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Join" rel="nofollow noreferrer"><code>-join</code>operator</a>, as shown above.</p>
<ul>
<li><p>Note that PowerShell appends a trailing platform-native newline to this single, multi-line string too, but a stray <code>\r\n</code> at the <em>very end</em> of the input is in effect ignored by <code>bash</code>, assuming that the last true input line ends in <code>\n</code>, which is what the extra <code>+ &quot;`n&quot;</code> at the end of the expression ensures.</p>
</li>
<li><p>However, there are scenarios where this trailing CRLF newline <em>does</em> cause problems - see <a href="https://stackoverflow.com/a/48372333/45375">this answer</a> for an example and workarounds via the platform-native shell.</p>
</li>
</ul>
</li>
</ul>
