Open Stack

On 12/02/2014 04:25 AM, Ben Nemec wrote:
> 1) A specific reason SHELLOPTS can't be used.

IMO leave this alone as it changes global behaviour at a low-level and
that is a vector for unintended side-effects.  Some thoughts:

- We don't want tracing output of various well-known scripts that
   might run from /bin.

- SHELLOPTS is read-only, so you have to "set -x; export SHELLOPTS"
   which means to turn it on for children you have to start tracing
   yourself.  It's unintuitive and a bit weird.

- Following from that, "DIB_DEBUG_TRACE=n disk-image-create" is the
   same as "disk-image-create -x" which is consistent.  This can be
   useful for CI wrappers

- pretty sure SHELLOPTS doesn't survive sudo, which might add another
   layer of complication for users

- A known env variable can be usefully overloaded to signal to scripts
   not in bash rather than parsing SHELLOPTS

> I'm all for improving in this area, but before we make an intrusive
> change with an ongoing cost that won't work with anything not
> explicitly enabled for it, I want to make sure it's the right thing
> to do.  As yet I'm not convinced.

For "ongoing cost" -- I've rebased this about 15 times and there just
isn't that much change in practice.  In reality everyone copy-pastes
another script to get started, so at least they'll copy-paste
something consistent.  That and dib-lint barfs if they don't.

This makes "disk-image-create -x" do something actually useful by
standardising the inconsistent existing defacto headers in all files.
How is this *worse* than the status quo?

-i