dash.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* export statements and command substitution
@ 2016-07-24 13:46 Nico Huber
  2016-07-24 14:05 ` Harald van Dijk
  0 siblings, 1 reply; 2+ messages in thread
From: Nico Huber @ 2016-07-24 13:46 UTC (permalink / raw)
  To: dash

Hi dash folks,

we stumbled over a little curiosity in dash's behavior when you combine
a variable assignment within an export statement with command sub-
stitution.

The following works fine in bash:
  $ export foo=$(echo foo bar)
  $ echo $foo
  foo bar
dash, however, applies field splitting and thus takes `bar` as a second
variable name:
  $ export foo=$(echo foo bar)
  $ echo $foo
  foo
which can easily be fixed by adding double quotes:
  $ export foo="$(echo foo bar)"
  $ echo $foo
  foo bar

I know bash shouldn't be the reference so I had a look at [1]. It
states:
 "If a command substitution occurs inside double-quotes, field
  splitting and pathname expansion shall not be performed on the
  results of the substitution."
Which one could read as field splitting should take place if you don't
supply double quotes. But in present shells variable assignments seem
to be an exception.

And even dash doesn't apply field splitting on a simple assignment:
  $ foo=$(echo foo bar)
  $ echo $foo
  foo bar

That's at least inconsistent and, IMO, the export statement should have
the same semantics (i.e. not requiring double quotes) as things can get
quite nasty if you think of evaluations like:
  $ export foo=$(echo bar bar=foo)
  $ echo $foo
  bar
  $ echo $bar
  foo

Best regards,
Nico

[1]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: export statements and command substitution
  2016-07-24 13:46 export statements and command substitution Nico Huber
@ 2016-07-24 14:05 ` Harald van Dijk
  0 siblings, 0 replies; 2+ messages in thread
From: Harald van Dijk @ 2016-07-24 14:05 UTC (permalink / raw)
  To: Nico Huber, dash

On 24/07/16 15:46, Nico Huber wrote:
> Hi dash folks,
>
> we stumbled over a little curiosity in dash's behavior when you combine
> a variable assignment within an export statement with command sub-
> stitution.
>
> The following works fine in bash:
>   $ export foo=$(echo foo bar)
>   $ echo $foo
>   foo bar
> dash, however, applies field splitting and thus takes `bar` as a second
> variable name:
>   $ export foo=$(echo foo bar)
>   $ echo $foo
>   foo
> which can easily be fixed by adding double quotes:
>   $ export foo="$(echo foo bar)"
>   $ echo $foo
>   foo bar
>
> I know bash shouldn't be the reference so I had a look at [1]. It
> states:
>  "If a command substitution occurs inside double-quotes, field
>   splitting and pathname expansion shall not be performed on the
>   results of the substitution."
> Which one could read as field splitting should take place if you don't
> supply double quotes. But in present shells variable assignments seem
> to be an exception.
>
> And even dash doesn't apply field splitting on a simple assignment:
>   $ foo=$(echo foo bar)
>   $ echo $foo
>   foo bar

Yes, that's as specified in 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01>. 
First, commands are scanned to see what words are shell variable 
assignments. Then, those words that are not shell variable assignments 
are fully expanded. Finally, redirections are applied and shell variable 
assignments get a limited expansion that omits field splitting.

Note that the a=b in export a=b is not a shell variable assignment, as 
far as the parser is currently concerned, both in the dash 
implementation and in the language specification, it is just a word 
that's used as an argument for the export command. What the export 
command then does with it is another story.

> That's at least inconsistent and, IMO, the export statement should have
> the same semantics (i.e. not requiring double quotes) as things can get
> quite nasty if you think of evaluations like:
>   $ export foo=$(echo bar bar=foo)
>   $ echo $foo
>   bar
>   $ echo $bar
>   foo

The next version of POSIX will require this behaviour, see 
<http://austingroupbugs.net/view.php?id=351>, but the current version 
doesn't even allow it.

> Best regards,
> Nico
> [1]
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-07-24 14:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-24 13:46 export statements and command substitution Nico Huber
2016-07-24 14:05 ` Harald van Dijk

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).