Re: cope with spaces in an environment variable

[Lawrence Velázquez]

On Sun, Jun 18, 2023, at 2:37 PM, Masahiro Yamada wrote:
> Ans1)
>
>   #!/bin/sh
>   "${CC}" helloworld.c
>
>
> This does not work with [2].
>
>   $ export CC="ccache gcc"
>   $ ./build-helloworld.sh
>   ./build-helloworld.sh: 2: ccache gcc: not found

Right, because quoting inhibits field splitting.


> Ans2)
>
>   #!/bin/sh
>   ${CC} helloworld.c
>
> This works with [2], but not [1].
>
>   $ export CC="'/tmp/a b/gcc'"
>   $ ./build-helloworld.sh
>   ./build-helloworld.sh: 2: '/tmp/a: not found

The first answer does not work with [1] either.  This is because
the shell does not reinterpret the results of parameter expansion
(including embedded quotes) as syntax.


> Ans3)
>
>   #!/bin/sh
>   eval "${CC} helloworld.c"
>
> This works with [1], [2], and the combination of them.
>
>   $ mkdir -p '/tmp/a b'
>   $ ln -s /usr/bin/gcc '/tmp/a b/gcc'
>   $ export CC="ccache '/tmp/a b/gcc'"
>   $ ./build-helloworld.sh
>
>
> So, using 'eval' seems to work for me, but
> it is somewhat tedious to repeat 'eval' in each line
> that uses ${CC}.
>
> Is this a proper way, or is there a better way?

I don't know of a significantly better way to imitate the behavior
you see with make(1) variables -- i.e., code injection.  Of course,
eval(1) requires properly quoting variables that you *don't* want
to inject.

        eval " $CC"' -o "$out" "$in"'

This may get old fast.  If you're open to ditching make(1)-style
variables, then the FAQ page Davide linked has some alternate
approaches.


-- 
vq