[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