bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: propagating environment variable via internal command


From: Tomas Janousek
Subject: Re: propagating environment variable via internal command
Date: Wed, 20 Jun 2018 21:11:56 +0200
User-agent: NeoMutt/20180512

Hi Chet and Tomáš,

On Wed, Jun 20, 2018 at 10:42:07AM -0400, Chet Ramey wrote:
> On 6/20/18 9:25 AM, Tomáš Čech wrote:
> >  $ /bin/sh
> >  sh-4.4$ VARIABLE=value set -o noglob
> >  sh-4.4$ env | grep VARIABLE
> >  VARIABLE=value
> >  sh-4.4$
> 
> Posix requires this behavior, which dates back to the Bourne shell, for
> assignment statements that precede special builtins:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14
> 
> It used to require the same behavior for assignment statements preceding
> shell function calls, but that was removed in the most recent update.

Thanks for the quick reply!

I followed the link in item 2 and there is:

  If the command name is a special built-in utility, variable assignments
  shall affect the current execution environment. Unless the set -a option is
  on (see set), it is unspecified:

    Whether or not the variables gain the export attribute during the
    execution of the special built-in utility

    Whether or not export attributes gained as a result of the variable
    assignments persist after the completion of the special built-in utility

It seems that dash implements this without the export, which means this
"surprising" example we came up with behaves "correctly", but there's still
this one, possibly more subtle:

  $ {da,}sh -c 'VAR=val set -o noglob; echo $VAR'
  val

So even though this does look a bit like behaviour defined by historic
implementations, I guess the conclusion is that we should just read up on
POSIX shells. :-)

Thank you Chet.

-- 
Tomáš Janoušek, DEV/SETI/CEP @ GoodData, +420 608 876 277



reply via email to

[Prev in Thread] Current Thread [Next in Thread]