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