On 31 of January 2009 23:40:43 Bart Schaefer wrote: > } 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. > Yes, mea culpa. I did mean "as if LOCAL_OPTIONS were set". IOW restore options to the values they had before emulate command. > } 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. Unfortunately this one probably would be the most confusing implementation. This effectively results in options values after emulate that corresponds neither to options values before, nor to options set by commands inside of emulate -c. If user has changed any of the option that is touched by emulate (and emulate -R would touch every option) before executing emulate -c, return from emulate -c would wipe out all changes. We could try to interpret this as "set of options that were in effect before emulate -c as adjusted by options explicitly changed by command". This is doable, but this immediately poses another question - what to do with emulation mode set inside emulate -c? Extreme example: emulate sh -c "emulate -R csh" if we retain options set by "emulate -R csh" on exit from top level emulate, we effectively have options for csh emulation, but emulation itself is reset to whatever was in effect before (just in case - emulation is *not* limited to options unfortunately). So I still tend to leave things as is (making documentation more clear) and if we ever need different behaviour, better add explicit option for it.
Attachment:
signature.asc
Description: This is a digitally signed message part.