help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-bash] Awkward behavior of empty arrays


From: Chet Ramey
Subject: Re: [Help-bash] Awkward behavior of empty arrays
Date: Thu, 31 Aug 2017 14:19:30 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 8/31/17 12:16 PM, Andy Chu wrote:
Consider this:
> 
> $ set -- foo '*.sh' bar
> 
> There are only 3 possibilities from the four constructs (AFAICT $* is
> identical to $@):

Unquoted, yes. Quoted, no.

> These 3 possibilities can always be achieved as follows:
> 
> $ argv "$@"
> ['foo', '*.sh', 'bar']
> 
> $ joined="$@"  # explicit join
> 
> $ argv "$joined"
> ['foo *.sh bar']
> 
> $ argv $joined
> ['foo', 'bad.sh', 'local.sh', 'setup.sh', 'bar']
> 
> So I have used nothing but "$@" to generate all 3 possibilities.  Similarly
> for "address@hidden".

This only works if the first character of $IFS is ' '. There is nothing
in the expansion of $@, quoted or unquoted, that separates the arguments
using the first character of $IFS and leaves the result unsplit ("$*").


>     Because the operands in [[ commands don't undergo word splitting.
> 
> 
> Yes, it depends how you think about it from the implementation POV.

Not really. That's how [[ is defined to behave.

> 
> So it's not just lack of splitting, but ADDING joining (i.e. coerce an
> array to string).

Word splitting (in a context where word splitting takes place) is the only
way to get multiple arguments out of an expansion.

  But if bash stores arrays as FLAT strings internally,

It doesn't, but that doesn't matter.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]