From: Makarius <makarius@sketis.net>
To: dash@vger.kernel.org
Subject: Re: dash drops exported bash functions
Date: Thu, 11 Feb 2016 04:53:48 +0100 (CET) [thread overview]
Message-ID: <alpine.LNX.2.00.1602110431550.61314@lxbroy10.informatik.tu-muenchen.de> (raw)
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1967 bytes --]
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
next reply other threads:[~2016-02-11 4:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 3:53 Makarius [this message]
2016-02-11 12:15 ` dash drops exported bash functions Makarius
2016-02-11 13:40 ` Makarius
2016-02-11 14:19 ` Olof Johansson
2016-02-11 14:30 ` Makarius
2016-02-11 14:46 ` Stephane Chazelas
-- strict thread matches above, loose matches on Subject: below --
2016-02-10 15:18 Joachim Breitner
2016-02-10 15:54 ` Eric Blake
2016-02-10 16:31 ` Joachim Breitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.00.1602110431550.61314@lxbroy10.informatik.tu-muenchen.de \
--to=makarius@sketis.net \
--cc=dash@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).