Business Partnership
Hello, I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached proposal. Thanks in anticipation of your urgent response, LAURENT EYADEMA proposal.docx Description: Binary data
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
Business Partnership
Hello, I am Mr. LAURENT EYADEMA from Republic of Togo.please read the attached proposal. Thanks in anticipation of your urgent response, LAURENT EYADEMA proposal.docx Description: Binary data
Re: dash drops exported bash functions
Dear Eric, Am Mittwoch, den 10.02.2016, 08:54 -0700 schrieb Eric Blake: > On 02/10/2016 08:18 AM, Joachim Breitner wrote: > > Dear dash developers, > > > > a change in 0.5.8, very likely this one > > http://git.kernel.org/cgit/utils/dash/dash.git/commit/?id=46d3c1a614f11f0d40a7e73376359618ff07abcd > > broke the exporting of bash shell functions via the environment. > > Not a bug. POSIX says that on shell startup, the behavior of any > inherited environment variables that do not start with a proper shell > name is undefined; and allows shells to scrub such items out of the > environment on startup. Just because bash does not scrub them (but > instead treats them as shell function imports) does not mean dash has to > behave the same. > > 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. I’m not versed in reading POSIX,, so I won’t argue with that (although I could not find a reference), but let me point out 8.1 "8.1 Environment Variable Definition" of "The Open Group Base Specifications Issue 7" says “Other characters may be permitted by an implementation; applications shall tolerate the presence of such names.” But it is not a big deal now, as the application suffering from this issue will likely have to work-around this (or fix this, depending on the POV) anyways. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part
Re: dash drops exported bash functions
On 02/10/2016 08:18 AM, Joachim Breitner wrote: > Dear dash developers, > > a change in 0.5.8, very likely this one > http://git.kernel.org/cgit/utils/dash/dash.git/commit/?id=46d3c1a614f11f0d40a7e73376359618ff07abcd > broke the exporting of bash shell functions via the environment. Not a bug. POSIX says that on shell startup, the behavior of any inherited environment variables that do not start with a proper shell name is undefined; and allows shells to scrub such items out of the environment on startup. Just because bash does not scrub them (but instead treats them as shell function imports) does not mean dash has to behave the same. 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 Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
dash drops exported bash functions
Dear dash developers, a change in 0.5.8, very likely this one http://git.kernel.org/cgit/utils/dash/dash.git/commit/?id=46d3c1a614f11f0d40a7e73376359618ff07abcd broke the exporting of bash shell functions via the environment. The attached script shows the breakage, as it outputs $ ./exporttest.sh exportest called () Setting up environment Calling myself exportest called (1) function foo successfully called Calling myself directly exportest called (2) function foo successfully called Calling myself via dash exportest called (3) /tmp/exporttest.sh: Zeile 33: foo: Kommando nicht gefunden. Done 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). Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org exporttest.sh Description: application/shellscript signature.asc Description: This is a digitally signed message part
