ARGH! You dropped the list address! This was on bug-bash, right??
On Fri, Jun 09, 2017 at 03:14:10AM +0700, PePa wrote:
> On 09/06/2560 02:14, Greg Wooledge wrote:
> > Well, it leaves IFS changed, because you didn't revert or unset it,
> > or run the entire thing in a function with local IFS. Also, I'd use
> > "${MAPFILE[*]}" to reinforce that you are joining an array into a string,
> > rather than expanding the array as a list.
>
> Thanks for pointing all this out. I settled on:
> mapfile <"$file"; IFS= foo=${MAPFILE[*]} true
>
> Again, much faster than a subshell. Are there order guarantees in the
> case of "a=x b=y command"??
>
> Peter
You have a massive error here. Your variables exist only for the
duration of that "true" command.
imadev:~$ unset x y
imadev:~$ x=1 y=3 true
imadev:~$ declare -p x y
bash: declare: x: not found
bash: declare: y: not found
In the case of "x=1 y=2", yes, there is a guarantee of processing order.
You may safely write things like:
tmp=${x##*[} tmp=${tmp%%]*} tmp=${tmp//x/y}
And they will be done from left to right. But in your example, the
question is moot, because your variables don't survive at all.
