Re: sourcing a sh file in zsh

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 16,  9:55pm, Phil Pennock wrote:
} Subject: Re: sourcing a sh file in zsh
}
} On 2009-01-16 at 21:00 -0800, Bart Schaefer wrote:
} > On Jan 16,  7:59pm, Phil Pennock wrote:
} > } On 2009-01-16 at 10:29 -0800, Bart Schaefer wrote:
} > } > with the obvious meaning of "turn on sh emulation while sourcing" and
} > } > would otherwise behave like "source".  Might need a variant that has
} > } > the path-searching semantics of "." as well.
} > } 
} > } Isn't there a problem where a function is defined which assumes one
} > } set of semantics and the reset afterwards changes the semantics?
} > 
} > The reset after what?  This hypothetical feature?  Well, since it's
} > hypothetical, I'd have to say no, there isn't a problem, because if
} > the feature ever ceases to be hypothetical it should be implemented
} > so as to avoid that problem.
} 
} Okay, and that raises the issue of reset and options from outside a
} function needing to be retained as part of the function definition.

OK, I think I get it now, and sorry for being a bit dense before.  You
are talking about a situation where:

- There is a script file of some sort, meant to be read by "source".
- That script file doesn't just do something once (like assign to a
  bunch of environment variables) and go away; instead, it defines
  shell functions that are intended to be used interactively later.
- Those shell functions make the reasonable assumption that if the
  function defintion was parsed by, e.g., a POSIX-compatible shell,
  then the shell will still be POSIX-compatible when the function is
  actually run.

Leaving aside for the moment the fact that it's entirely possible to
parse a function definition with NO_SH_WORD_SPLIT that won't then work
without SH_WORD_SPLIT, so "the setopts in effect at parse time" might
not be a valid representation of "the setopts needed at run time", I
agree that it might be useful to be able to cause a specific set of
options to become set before entry to a given function.

This gets very tricky, however, when applied to functions that are
actually designed for zsh.  An implicit preset of options implies an
implicit restore later, but a zsh function which deliberately does
NOT "setopt localoptions" is expecting any setopt it executes to
persist after the function exits.  It'll be complicated to keep track
of which options should be restored because of implicit preset, and
which ones should not be restored because of explicit change.

Regardless I don't think we'd want to do this as yet another setopt.
It's potential can of worms along the lines of ALL_EXPORT, in that
one can end up accidentally applying a specific option context to a
function definition where one didn't (or shouldn't) mean to do so.
I'd lean toward something that works like the "emulation" global,
which is still localized to function scope but which is changable
only by the "emulate" command.

Combined with allowing "emulate" create a scope and run a command
in that scope, is there anything else you'd need?

PWS, any comment on how difficult it would be to extend "emulate" in
this way?  Would it require promoting emulate to a keyword?

} So I'm thinking an Eprog WC_OPTSPACE instruction which can be inserted
} at some point arounf execfuncdef() time, which is stored with a value
} which points to the opts value to be put into effect and which, when
} encountered, adjusts the current funcstack entry to hold the current
} opts before replacing opts with the one referenced in the Eprog.

This part sounds fine to me, but I've never been the expert on Eprogs.