Easy to accidentally use shellisms in fix and check targets

[technicalpickles]

I got this failure for a setup:

ERROR: "bundle check" was called with arguments ["&&", "bundle", "install"]
Usage: "bundle check [OPTIONS]"
ERROR Check `bundle-update` failed. The fix ran and Failed.

Turns out it was because I was using &&:

apiVersion: scope.github.com/v1alpha
kind: ScopeDoctorSetup
metadata:
  name: bundle-update
spec:
  # order: 100 # default value
  cache:
    paths:
      - Gemfile*
      - .ruby-version
  setup:
    exec:
      - bundle check && bundle install
  description: Check for updates to bundled dependencies

I wonder if it's useful to always run things in a shell? Or if it could be identifed with a better error message?

[ethankhall]

I think your suggestion to run things in a shell is probably correct. We could make a shell script in tmp, with whatever text they provide and use sh as the interpreter. In that case we'll also get the ability to use env-vars.

Thoughts?

[rubberduck203]

#184 added the ability to resolve ~/ to the $HOME directory, but the library we're using also allows you to expand environment variables, if we choose to enable that.

The original example cited could also easily be worked around by using multiple commands.
(updated to current yaml schema)

 fix:
    commands:
      - bundle check
      - bundle install

That would really only leave subshell expansion as being problematic.

 fix:
    commands:
      - echo $(whoami)

Which can also be worked around by wrapping the command in bash -c

 fix:
    commands:
      - bash -c 'echo $(whoami)'

This comment is for documentation purposes of current state and workarounds, not an opinion on whether or not all commands should be wrapped in a shell exec.