Path: utzoo!yunexus!telly!philmtl!uunet!ginosko!rex!ukma!cwjcc!kiwi!chet
From: chet@kiwi.CWRU.EDU (Chet Ramey)
Newsgroups: gnu.bash.bug
Subject: Re: exportable functions
Message-ID: <551@cwjcc.CWRU.Edu>
Date: 8 Sep 89 16:05:37 GMT
Article-I.D.: cwjcc.551
References: <8909080854.AA12325@rice-chex>
Sender: news@cwjcc.CWRU.Edu
Reply-To: chet@kiwi.INS.CWRU.Edu (Chet Ramey)
Distribution: gnu
Organization: CWRU Andrew R. Jennings Computing Center
Lines: 38

In article <8909080854.AA12325@rice-chex> tmb@AI.MIT.EDU (Thomas M. Breuel) writes:

(Don't you love how the AI lab named all of their machines after breakfast
cereals? :-)

>It would be nice if Bash supported exportable functions like V9 "sh".
>Strings of the form "name=value" in the environment are considered
>environment variables, and strings of the form "name(){value}" are
>considered environment functions.

Funny, Doug Gwyn and I were having a discussion about this just last
weekend on comp.unix.questions.

The problem with the v9 syntax for exportable functions is that it requires
a C library `getenv()' that ignores the definitions and shells that
understand them (for example, this would choke a "regular" System V /bin/sh
started under bash -- either you would have some very strangely-named shell
variables, or the shell would just get all confused).

Bash does have exportable functions; the syntax is "name=() {value}", which
I think is a nice compromise:

kiwi$ echo $BASH_VERSION
1.03.59
kiwi$ type foo
foo is a function
foo () { echo this is foo }
kiwi$ export foo
kiwi$ bash
kiwi$ foo
this is foo
kiwi$

Chet Ramey
Chet Ramey			"We are preparing to think about contemplating 
Network Services Group, CWRU	 preliminary work on plans to develop a
chet@cwjcc.INS.CWRU.Edu		 schedule for producing the 10th Edition of 
				 the Unix Programmers Manual." -- Andrew Hume