RE: PATCH: 3.1.5: eval with exported vars

["Andrej Borsenkow" <borsenkow.msk@xxxxxx>]

>
> "Andrej Borsenkow" wrote:
> > But as I understand, your patch blindly exports variable for
> every builtin?
>
> No, just eval, which is a peculiar case because you really don't know
> what it's going to do.

Sorry. But I don't think this is needed. Currently it behaves exactly as it
should.

bor@itsrm2:~smbsrc/source%> FOO=x eval sh -c 'echo $FOO'

bor@itsrm2:~smbsrc/source%> FOO=x eval 'sh -c echo $FOO'

Both are correct as you explained. The string after -c is just "echo" It is
funny, but so is it.

bor@itsrm2:~smbsrc/source%> FOO=x eval sh -c "echo $FOO"

Correct. $FOO is expanded when the whole is first read.

bor@itsrm2:~smbsrc/source%> FOO=x eval 'sh -c "echo $FOO"'
x

Correct. eval gets 'sh -c "$FOO"', expands $FOO to x, so it amounts to sh -c
'echo x'.

bor@itsrm2:~smbsrc/source%> FOO=x eval 'sh -c "echo \$FOO"'

Correct. It expands to sh -c 'echo $FOO' and FOO is _not_ exported (and
should not).

bor@itsrm2:~smbsrc/source%> FOO=x eval 'FOO=bar sh -c "echo \$FOO"'
bar

If you really want to export something to command excuted in eval.

Why is it wrong. It is clean and consistent.

 The workaround I gave (assignment after the
> eval) is really the best way of doing it.  You can certainly argue
> it's not right to have eval as a special case, but I'd say exporting
> it rather than just setting it is the safest here.
>

Why? See above - you always can export it if needed.

>
> This is supposed to depend on the setting of POSIXBUILTINS.

'course you are right.

>
> Possibly the patch I sent should have a !isset(POSIXBUILTINS) wrapper?
>

Possibly, we don't need the patch at all?

/andrej