output of `export -p' seems misleading

2012-11-09 Thread wuya 
Hi all,
   1. why `export -p' output something in the format `declare -x foo="bar"'
   2. this format gives user an implication that by executing these `declare' 
commands, all those variables got exported, but this is only partly true as it 
fails in functions.
   3. As in bash 4.2, -g option is added. why not change output format of 
`export -p' to `declare -g foo="bar"'?

thanks!

Re: output of `export -p' seems misleading

2012-11-09 Thread Chet Ramey 
On 11/9/12 4:09 AM, wuya wrote:
> Hi all,
>1. why `export -p' output something in the format `declare -x foo="bar"'

Because the declare form is bash's `native' notation.  If you're in Posix
mode, the output is in the form of `export' commands.

>2. this format gives user an implication that by executing these `declare' 
> commands, all those variables got exported, but this is only partly true as 
> it fails in functions.

That's not quite true.  The documentation implies, though maybe not as
clearly as possible, that each name argument to declare/export/readonly is
treated as a variable name by default.  The -f option is what you need to
refer to functions.

>3. As in bash 4.2, -g option is added. why not change output format of 
> `export -p' to `declare -g foo="bar"'?

Because they are not at all the same thing.  -x refers to the environment.
-g changes bash's internal variable scoping.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: output of `export -p' seems misleading

2012-11-09 Thread Greg Wooledge 
On Fri, Nov 09, 2012 at 11:07:28AM -0500, Chet Ramey wrote:
> On 11/9/12 4:09 AM, wuya wrote:
> >2. this format gives user an implication that by executing these 
> > `declare' commands, all those variables got exported, but this is only 
> > partly true as it fails in functions.
> 
> That's not quite true.  The documentation implies, though maybe not as
> clearly as possible, that each name argument to declare/export/readonly is
> treated as a variable name by default.  The -f option is what you need to
> refer to functions.

I believe wuya wants to be able to use the output of "export -p"
while INSIDE a function in order to restore some previously saved set
of environment variables, but the side effect of "declare" -> "local"
is getting in the way (i.e. (s)he wants the variables to survive after
returning from the function).

However, since you said that the behavior changes when in POSIX mode, wuya
can use that as a workaround:

restore_environment() {
  set -o posix
  eval "$saved_output_of_export_dash_p"
  set +o posix
}

Re: output of `export -p' seems misleading

2012-11-09 Thread Greg Wooledge 
On Fri, Nov 09, 2012 at 11:18:24AM -0500, Greg Wooledge wrote:
> restore_environment() {
>   set -o posix
>   eval "$saved_output_of_export_dash_p"
>   set +o posix
> }

Err, what I meant was:

save_environment() {
  set -o posix
  saved_env=$(export -p)
  set +o posix
}

restore_environment() {
  eval "$saved_env"
}