tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/47597: local and $() don't play well with each other
On Fri, Mar 01, 2013 at 10:15:23PM +0700, Robert Elz wrote:
>
> | I write functions in a shell script. These functions have names that
> | do not exist as an external thing. They are functions. I extract every
> | function in a shell file, made executable. These are utilities.
>
> Yes, and you're right, this whole area of the standard is insane - but
> your example proves nothing - if your functions are in separate files,
> implemented as utilities, then it isn't the (instance of) the shell that
> runs the function that does something different, it is the calling shell,
> and it just does the same as it does for every other utility.
>
> You can easily see the difference if your function assigns to an
> externally visible variable (which in a fully portable function, is
> any variable it can assign to). If it is implemented as a utility,
> that assignment will not be visible to the calling shell. If it is
> implemented as a function, it will be.
>
> That is, all variables assigned in a (standards conforming) function persist
> after the function exits, whether they're assigned in a "variable assignment"
> on the call, or inside the body of the function.
>
> The same is true if the function does anything else that alters its
> environment (opening or closing files, (exec >&- for example), changing
> the flags (set -e), ...
Unless, of course, the shell function has one of its fd redirected (or
piped), in which case the historic behaviour is to fork - so the
assignments inside the function get lost.
(At least, I know that happens for while loops, I expect functions
to be the same.)
There are words somewhere about the 'shell execution environment' and
when a new one is created...
David
--
David Laight: david%l8s.co.uk@localhost
Home |
Main Index |
Thread Index |
Old Index