When you include the value of a variable (parameter) in a command line, the
replacement usually happens too late for the resulting value to participate
in other sorts of expansion.

 For example, if you do `echo *`, you'll get a list of the files in the
directory. But if you put the `*` into a variable and echo it:

    $ asterisk='*'
    $ echo $asterisk
    *

Likewise, if you have a variable with a space in the value, it's not
normally subject to word splitting - if you pass it to a command, that
command will get a single argument containing a space, not multiple
arguments:

    $ words='one two'
    $ printf '%s\n' $words
    one two

(It's worth mentioning that in both of the above cases the behavior of zsh
is different from the behavior of bash or ksh, in which the parameter value
_is_ subject to further expansion.)

You can selectively enable further processing with the `~` and `=`
modifiers.  The `~` means that the result of the variable substitution will
be subject to wildcard expansion:

    $ echo $~asterisk
    Applications Desktop Documents Downloads Library bin etc git lib src
tmp

While the `=` means it will be subject to word-splitting:

    $ printf '%s\n' $=words
    one
    two





On Thu, Jan 4, 2024 at 9:04 PM Ray Andrews <rayandrews@eastlink.ca> wrote:

>
> On 2024-01-04 17:41, Lawrence Velázquez wrote:
>
> Another important part occurs earlier in "Parameter Expansion" and
>
> can admittedly be hard to find:
>
> Yes.  Seems almost inevitable that with such terse syntax normal search
>
> culture is going to be frustrating.  One must master the shell's jargon.
>
> I wonder if a syntax index could be contemplated, it would look rather
> strange:
>
> $(
>
> $((
>
> $~
>
> ${~
>
> if[
>
> if[[
>
> ... every last construction.
>
> This is why you can use $~foo instead of ${~foo} sometimes.
>
> I've noticed that but I don't even try to understand it.  I am in awe of
> the
>
> geniuses who wrote the parser.  The list of ifs, ands, buts and maybes is
>
> not for a mere mortal to understand.  That's what accretion gets you --
> couldn't
>
> be otherwise.
>
> That just refers to the result of the parameter expansion being
>
> subsequently used as something other than a literal value, if the
> context calls for it.
>
> God knows.  It's a steep hill to climb if you're not familiar with it.
> Anyway I'm
>
> at least alert to the issue.
>
> Tx.
>
>
>

-- 
Mark J. Reed <markjreed@gmail.com>