Piping a download straight into a shell runs whatever the server returns at that moment, with no chance to read it first. It is not always unsafe, but it removes your review step. Safer docs download the script, show how to verify it, then run it.
What the one-liner actually does
A command of the form curl -fsSL https://example.com/install.sh | sh fetches a script and hands it to a shell as it arrives. Three things follow from that design.
First, you execute code you have not seen. Second, the script can differ between requests, so what you tested yesterday is not necessarily what runs today. Third, a connection that drops partway can leave a half-delivered script, and some shells will happily run the part that arrived.
The risk sits with whoever controls the download location. If that host or its release process is compromised, every reader who pastes the line is compromised too, and the install happens with the reader's own permissions.
When it is a fair trade
Be honest about the context. A reader installing a tool on a throwaway virtual machine accepts the risk differently from one pasting it on a work laptop with cloud credentials. Many vendors use the one-liner because it is the shortest path to a working tool. If you publish one, treat it as a convenience and offer a second path.
Safer pattern for docs
- Download the script to a file instead of piping it.
- Tell the reader to open and read it. Keep installers short enough to review.
- Publish a checksum for the script on a separate page, and show how to compare it.
- Run the file explicitly once the reader is satisfied.
- Offer a package manager route or a signed release archive for people who want one.
- Serve everything over HTTPS only, and pin the script to a versioned URL so content does not change under readers.
curl -fsSLo install.sh https://downloads.example.com/v1.2.3/install.sh
sha256sum install.sh
less install.sh
sh install.sh
Comparing install routes
| Route | Reader can inspect first | Content stable between runs | Effort for the reader |
|---|---|---|---|
| Pipe to shell | No | No | Lowest |
| Download, read, run | Yes | Yes if versioned | Low |
| Verified checksum then run | Yes | Yes | Medium |
| Package manager or signed archive | Depends on the manager | Yes | Medium |
What docs authors can add
Write one sentence explaining what the script changes on the machine: which directories it writes, whether it edits shell profiles, whether it needs administrator rights. Readers deciding whether to trust it need those facts. Keep the installer free of surprise actions such as telemetry the docs never mention.
Tell readers how to uninstall, too. A tool that is easy to remove is easier to try, and trying it in a disposable environment is a sound habit to encourage.
Where it connects to supply chain risk
An install script is a link in your supply chain just like a library is. Treat its hosting, its release process and its change history with the same care you give code. For the reader's side, see the hidden risk of copy pasted code snippets.
Safeguard's CLI is available through curl and PowerShell installers, and its download page at https://safeguard.sh/download lists each surface. Whatever you install, the habit above applies: download first, read, then run. Dependency scanning and SBOM generation can then inventory what lands in your projects, and the free scan is at https://gold.safeguard.sh/scan.
Quick check
Is curl pipe sh the same as downloading an installer from a website?
Not quite. A downloaded file can be inspected and checksummed before it runs. A pipe executes the content as it arrives.
Does HTTPS make the one-liner safe?
HTTPS protects the data in transit and confirms the host. It does not tell you whether the script itself is trustworthy.
Last reviewed: 19 October 2026.
