Re: bin/47597: local and $() don't play well with each other

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 1 Mar 2013 13:58:28 +0100
    From:        tlaronde%polynum.com@localhost
    Message-ID:  <20130301125828.GA2685%polynum.com@localhost>

  | 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), ...

It is understandable why things got to be as they are - to do what almost
everyone agrees is the right way requires some kind of variable save and
restore ability (essentially local variables) which did not exist at all
in local shells, and are not standarised now (it seems) because while
most modern shells have such a mechanism, there's no agreement on what the
scoping rules should be (the different shells do this quite differently).

Note that none of this is an argument for actually keeping things they way
they're currently defined - it is not important that it is possible to
write a function that does things a utility cannot do - that is beyond
doubt, and one of the major reasons (if not the major reason) for functions
to exist at all - the question is whether it is possible to write a
function that behaves identically to a utility, and currently, it is not.
It should be.


Alan Barrett <apb%cequrux.com@localhost> said:
  | If the standard is not willing to declare existing implementations  to be
  | broken then it has to allow the existing stupid way, but it  doesn't have to
  | mandate the stupid way. 

Agreed, that's almost certainly what will happen, one day, I hope...

That still isn't very useful for script authors, but it at least removes
the temptation for shell authors to implement it the way the standard
says, just because it is the way the standard says (like bash's "set -o posix"
mode for all of this).

kre