On 02/10/2016 08:54:40 Eric Blake wrote:
That said, preserving any unusable environment variables unchanged,
rather than scrubbing them, may be slightly nicer behavior, but I'm not
sure it's worth the bloat to dash to do so.
> Exporting bash functions via the environment might be a rarely used
> feature, but it is used in practice, unfortunately (otherwise I
> wouldnʼt have noticed this).
Exporting bash functions is only usable if you plan on directly invoking
bash. Don't drag dash into the mess. Inserting a dash child in between
a bash parent and grandchild means all bets are off for whether the
grandparent can export anything to the grandchild.
Eric,
I am a long-term user of GNU bash who is depending on the "export -f"
feature of that shell (in an application that is on the free market for
decades). The bash guys turn a shell function "foo" into the environment
variable "BASH_FUNC_foo%%" and hope to be able to pick it up later on.
Dash gets into this game, because Ubuntu and Debian have chosen to make it
the default for /bin/sh some years ago. This means that typical "system"
invocations of Unix tools and libraries are now going through dash:
/bin/sh -c is often seen in practice instead of more delicate execve
invocations.
This means with /bin/sh -> dash users have no proper chance to avoid it.
Sitting right there in the center /bin/sh, dash acquires special
responsibilities to play nice with other shells.
Note that the issue has come up now due to this recent change in
Debian-testing: https://tracker.debian.org/news/744916
Thus a the following change from 2012 became exposed to testers/users of
Debian:
http://git.kernel.org/cgit/utils/dash/dash.git/commit/?id=46d3c1a614f11f0d40a7e73376359618ff07abcd
In that change 46d3c1a614f, the original motivation was to make "export
-p" work more robustly in dash, and not to cripple export -f in bash
because of POSIX violations.
Makarius
