<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>To start off, I need to be clear about a few things:</p>
<ol>
<li>Based on the tags to the question, I see we are in PowerShell rather than a linux/unix or even Windows cmd shell</li>
<li>In spite of this, we are using Unix <code>curl</code> (probably <code>curl.exe</code>), and not the PowerShell alias for <code>Invoke-WebRequest</code>. We know this because of the <code>-sL</code> argument. If Powershell was using the alias, we'd see a completely different error.</li>
</ol>
<p>Next, I need to talk briefly about line endings. Instead of just a single LF (<code>\n</code>) character as seen in Unix/linux and expected by bash, Windows by default uses the two-character LF/CR pair (<code>\n\r</code>) for line endings.</p>
<hr />
<p>With all that background out of the way, I can now explain what's causing the problem. It's this single pipe character:</p>
<pre><code>| 
</code></pre>
<p>This a PowerShell pipe, not a Unix pipe, so the operation puts the output of the <code>curl</code> program in the PowerShell pipeline in order to send it to the <code>bash</code> interpreter. Each line is an individual item on the pipeline, and as such no longer includes any original line breaks. PowerShell pipeline will &quot;correct&quot; this before calling bash using the default line ending for the system, which in this case is the LF/CR pair used by Windows. Now when bash tries to interpret the input, it sees an extra <code>\r</code> character after every line and doesn't know what to do with it.</p>
<p>The trick is most of what we might do in Powershell to strip out those extra characters is still gonna get sent through another pipe after we're done. I guess we <em>could</em> tell curl to write the file to disk without ever using a pipe, and then tell bash to run the saved file, but that's awkward, extra work, and much slower.</p>
<hr />
<p>But we can do a little better. PowerShell by default treats each line returned by curl as a separate item on the pipeline. We can &quot;trick&quot; it to instead putting one big item on the pipeline using the <code>-join</code> operation. That will give us one big string that can go on the pipeline as a single element. It will still end up with an extra <code>\r</code> character, but by the time bash sees it the script will have done it's work.</p>
<p>Code to make this work is found in the other answer, and they deserve all the credit for the solution. The purpose of my post is to do a little better job explaining what's going on: why we have a problem, and why the solution works, since I had to read through that answer a couple times to really get it.</p>
