Re: sourcing a sh file in zsh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 31, 11:32am, Andrey Borzenkov wrote:
}
} > I *didn't* expect an equivalence to function scopes with respect to
} > any setopts that aren't normally affected by changing the emulation.
} 
} This is doable. I did not quite like it because my primary intention
} was to run foreign code.  In which case I definitely would not like
} this code by accident change shell behaviour.  So it is sort of
} sandbox.

This is a tricky problem.  What, for example, should happen when one
does
    emulate sh -c 'set -x'
??

I'd initally have expected XTRACE to become and remain set.  However,
I can see reasons for doing it either way, so as long as whatever is
chosen is documented I'm OK with it.

We face a similar problem with the "sticky" emulation idea.  Let's
suppose for purposes of illustration that "emulate -S" activates it.

    emulate -S sh -c 'debug() { set -vx }'

(Imagine the debug function is buried in, and used by, some lengthy
piece of /bin/sh code that's being loaded.)  What happens when the
debug function is executed?  An implicit LOCAL_OPTIONS breaks the
intended behavior.

} I think we need to sort this out before usage sticks.

Absolutely.

} So let's consider what we get
} 
} emulate -L -c "command"
} 	implicitly set LOCAL_OPTIONS before executing command

Well, no.  Literally setting LOCAL_OPTIONS has side-effects within other
functions that might be defined by the command.  Everything here has to
be described in terms of "behaves as if".  I suppose we could do it this
way (rope to hang yourself and all that, no different than putting an
"emulate -L" in your .zshrc) but I'm not opposed to -L / -c as mutually
exclusive.

} emulate [-R] -c "command"
} 	implicitly do "emulate [-R] oldemulation" after executing command
} 
} Do I miss something? Is it what you intend?

That's pretty much what my original thought was, yes, but again I can
see the argument both ways.