Re: dash drops exported bash functions
On Thu, 11 Feb 2016, Makarius wrote: After reading the official (!) sources of bash-4.3, I've found out the following: Not the bash guys are introducing this ill-formed name decoration "%%", but the Debian guys. See http://sourcesdev.debian.net/patches/bash/4.3-14/bash43-027.diff This means dash is not working against bash, but against Debian. Or rather: Debian is working against themselves and their users. Yet another update. On another mailing list, someone else pointed out that this change might be due to the "shell shock" desaster from 2014: https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 If the malformedness of environment variables that are meant to be functions is important for bash43-027.diff above, the ball might be back on the side of dash. In any case, the Debian guys need to get involved, but I am myself not a member of that society. Makarius -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dash drops exported bash functions
On Thu, 11 Feb 2016, Olof Johansson wrote:
On 2016-02-11 14:40 +0100, Makarius wrote:
In any case, the Debian guys need to get involved, but I am myself
not a member of that society.
Why? It's an upstream patch, it's not Debian specific.
https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027
Correct. It is also in bash-4.4-beta, where I should have looked first.
Adapt your software instead?
I can certainly make evasive maneuvers.
The problem is a deeper one, though: export -f in bash no longer works for
systems that have /bin/sh -> dash (i.e. Debian and Ubuntu).
Makarius
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dash drops exported bash functions
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
