Variable assignment with function invocation persists contrary to manual

[Dirk Fieldhouse <fieldhouse@xxxxxxx>]

In running the tests provided with the package pkg-config, I found the
following behaviour of DASH which contradicts its manual page and
presumably the behaviour of the /bin/sh used by the pkg-config devs
(probably they were aiming for POSIX but using bash). It does agree with
Busybox sh, but I think that is derived from DASH.

$ expecting() {
>echo "Expecting ${EXP:-0}"
>}
$ expecting
Expecting 0
$ EXP=1 expecting
Expecting 1
$ expecting
Expecting 1
$

Unfortunately the program doesn't respect a --version option - shouldn't
it do so? So I couldn't copy the result of that.

I built dash-0.5.9.1 and confirmed that this still happens.

In src/dash.1, we read wrt executing shell functions:

"...
The variables which are explicitly placed in the environment of
the command (by placing assignments to them before the function name)
are made local to the function and are set to the values given.
Then the command given in the function definition is executed.
The positional parameters are restored to their original values
when the command completes.

This all occurs within the current shell.
..."

Clearly from the above test case, a variable assigned on the line before
the function name when invoking a shell function is not "made local to
the function" but instead pollutes the environment of the calling shell.

In Ubuntu Xenial with dash-0.5.8-2.1ubuntu2, I get the same behaviour,
while with bash (obviously not a general guide to what should happen):

$ bash --version
GNU bash, version 4.3.48(1)-release (i686-pc-linux-gnu)
...
$ bash
$ expecting
Expecting 0
$ EXP=1 expecting
Expecting 1
$ expecting
Expecting 0
$

In POSIX.1-2017 ("simultaneously IEEE Std 1003.1™-2017 and The Open
Group Technical Standard Base Specifications, Issue 7")
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09>,
we read under '2.9.1 Simple Commands'

"Variable assignments shall be performed as follows:
...
-    If the command name is a standard utility implemented as a function
(see XBD Utility), the effect of variable assignments shall be as if the
utility was not implemented as a function.
...
-    If the command name is a function that is not a standard utility
implemented as a function, variable assignments shall affect the current
execution environment during the execution of the function. It is
unspecified:

     *   Whether or not the variable assignments persist after the
completion of the function

     *   Whether or not the variables gain the export attribute during
the execution of the function

     *   Whether or not export attributes gained as a result of the
variable assignments persist after the completion of the function (if
variable assignments persist after the completion of the function)"

For me it seems highly desirable to make shell function invocation work
as much as possible like external command invocation and therefore I
vote for (call this "command-like" behaviour)

-   the variable assignments not persisting after the completion of the
function, and

-   the variables gaining the export attribute during the execution of
the function.

To achieve that with dash-0.5.9.1 (and presumably earlier), I have to write

(export VAR=value; function params)

instead of simply

VAR=value function params

as I would with

VAR=value program params

As quoted above, POSIX requires the command-like behaviour anyway when
the function is "a standard utility implemented as a function" (see
<http://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html> for
the list). So if a separately packaged POSIX shell, such as DASH, sees a
function called, say, basename, it would apparently have to invoke it in
the command-like fashion in case it was the environment's standard basename.

But whatever POSIX-compliant behaviour is implemented in dash, the
manual page should match.

-- 
London SW6
UK
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html