gortex upgrade --run fails for script method: pipeline exec'd as raw argv (curl: could not resolve host '|')

[velppa]

Summary

gortex upgrade --run fails for the script install method because it executes the shell pipeline curl -fsSL https://get.gortex.dev | sh as a raw argv vector instead of through a shell. The | and sh tokens are handed to curl as additional hostnames, so curl tries to resolve them as hosts and exits 6.

Version

gortex v0.58.3+447588b   (also present in the v0.60.0 codebase — verified by inspecting the printed command)
os/arch: darwin/arm64

Repro

$ gortex upgrade
Upgrading gortex 0.58.3 → v0.60.0 (install method: script)
Run:
  curl -fsSL https://get.gortex.dev | sh

$ gortex upgrade --run
...
curl: (6) Could not resolve host: |
curl: (6) Could not resolve host: sh
Error: upgrade command failed: exit status 6

Diagnosis

The printed command is a shell pipeline (curl ... | sh), but --run appears to exec the argv list ["curl","-fsSL","https://get.gortex.dev","|","sh"] directly (e.g. exec.Command("curl", args...)), so | and sh become curl positional args → treated as hostnames. No shell ever interprets the pipe.

Expected

--run should run pipeline-containing commands through a shell, e.g.:

exec.Command("sh", "-c", cmdString)

for the script method (and any method whose command contains shell metacharacters). Non-pipeline methods (brew/scoop/go install) are unaffected because they're plain argv.

Workaround

Run the printed command manually, or install the tarball by hand (download release asset + checksums.txt, verify sha256, extract to $GORTEX_INSTALL_DIR). Both preserve the documented verification.

[hiSandog]

The command model should distinguish an argv-style executable from a shell pipeline instead of passing both through the same execution path. A regression case with quoting, redirects, and set -o pipefail would define whether script methods intentionally use a shell and how intermediate pipeline failures are reported.