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

[Bruce Korb <bruce.korb%gmail.com@localhost>]

On 03/02/13 08:48, Robert Elz wrote:
>   | or else rig it so that $(command -p -v sh) yields one that is.
> 
> It doesn't have a -p option, or a posix mode, either.

"it" being the shell, or the command "command"?
POSIX absolutely, unambiguously requires that $(command -p -v sh)
yield a posix compliant shell program.

> If you want to write portable scripts, do
> 
>       var=foo; export var; mufunc

Except for running programs that I know to be programs and not
functions, I, personally, don't use var=whatever before the command.
However, I do deal with a lot of scripts that are putatively
portable.  For such purposes, it is prudent to posix-ify the
platform as much as possible.

> The standard needs to be revised to say that when you do
> 
>       var=foo myfunc
> 
> the value of var after myfunc completes is undefined - which is true today.

I know you know about the Austin group.  Please lobby away.

> ps: if you happen to be someone who knows how to get to the opengroup shell
> standardization people, please ask them what

  austin-group-l%opengroup.org@localhost

David Korn and Chet Ramey will happily reply.

>       var=foo unset var; echo ${var}
> 
> is supposed to do.   The standard says that the echo should print "foo",
> as (given unset is a special built-in), its value is supposed to persist
> after the special built-in completes.   As best I can tell. no shell
> implements it that way - the unset wins, and the echo prints nothing (just 
> \n).
> 
> You could also ask how they reconcile the text in 2.9.5 & 2.14 (which is
> what gives rise to this dumb interpretation of variable-assignments with
> functions) with the text in 4.20, which says ...
> 
>       The system may implement certain utilities as shell functions
>       (see the Shell and Utilities volume of IEEE Std 1003.1-2001,
>       Section 2.9.5, Function Definition Command) or built-in utilities,
>       but only an application that is aware of the command search order
>       described in the Shell and Utilities volume of IEEE Std 1003.1-2001,
>       Section 2.9.1.1, Command Search and Execution or of performance
>       characteristics can discern differences between the behavior of
>       such a function or built-in utility and that of an executable file.
> 
> which is not true, as if we have a utility of unknown implementation and
> we want to test if it is a function or not (in a standards conforming shell)
> then all we need to do is write
> 
>       res="is not a function"
>       res="is a function" unknown
>       echo unknown $res
> 
> which looks to me as if the standard contains contradictory language, which
> cannot be good, can it?   If one part needs to be fixed, fix 2.9.5 !