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