[tcard]

`curl X | bash` provides _more_ transparency than most other usual methods of software distribution, as I can always inspect X, which is usually a simple, self-contained script.

In contrast, running code from an unaudited source (GitHub, NPM, etc.), or executing a binary from some random website, all less transparent yet just as dangerous, but for some reason raise way fewer eyebrows.

[throwaway2048]

Those methods of installing stuff suck too, and its not like you have to pick one of the three...

The main problem isn't malicious code, you can review the script after all, the main problem is the app making unwarranted assumptions about your install/distribution, then breaking things in the process.

[eyelidlessness]

You can only be sure of what you're running if you download it first, examine it, then run what you downloaded.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

[3xblah]

"You can only be sure of what you're running if you download it first, examine it, then run what you downloaded."

What if, before "run what you downloaded", first perform a dry run and observe it while it is running.

   set -x
   curl https://example.com/setup.sh | bash -n
   set +x

-x Execution trace

-n Read commands but do not execute them

https://en.wikipedia.org/wiki/Dry_run_(testing)

[3xblah]

Correction: -n and -x are obviously mutually exclusive. Have to use -v instead.

   curl https://example.com/setup.sh | bash -vn

As for trying to hide commands from an execution trace, it is not possible to hide the set +x command.

   cat > 1.sh
   echo visible
   set +v
   set +x
   echo hidden >/dev/null
   ^D

   cat 1.sh | bash -x

Output:

  + echo visible
  visible
  + set +v
  + set +x

One can syntax check setup.sh before downloading it with -vn (or perhaps shellcheck). After downloading and reading it, one can observe it while it is running with -x.

The truth is that people download and run shell scripts without reading them all the time. For example, how many people installing software packaged with configure scripts actually read the scripts. (Except in the event they do not work.)

[throwaway2048]

a script can just set +x before doing anything else, and then fake output.

[jwilk]

No, this doesn't work.

[ktpsns]

Why not?

[heinrichhartman]

As to parsing `ls`:

Bash scripting is incredibly powerful but also terribly broken with horrible edge cases. E.g. if syntax, bash quoting, -print0, parsing strings with regexps... It's near impossible to build sound applications with bash.

Parsing output of almost any program breaks at _some_ point: https://dwheeler.com/essays/fixing-unix-linux-filenames.html

You need to know what data you are dealing with when writing shell scripts. bb does not aim to fix that. Just gradually improve.

[aidenn0]

But parsing ls (with no arguments) is just stupid when there is a safe alternative that already exists and is shorter.