$ a="x{1,2}" ksh93 -c 'echo $a'
x1 x2

$ zsh -c 'exec {1}>&2; echo $1'
12
$ ksh -c 'exec {@@@}>&2; echo $1'
ksh: @@@: invalid variable name

$ ksh +o braceexpand -c 'echo $(echo "{a,b}")'
a b
$ a='{a,b}' ksh +o braceexpand -c 'echo x$a'
xa xb

$ a={a,b} ksh93 -fc 'echo $a'
{a,b}
$ a={a,b} mksh -fc 'echo $a'
{a,b}
$ a={a,b} mksh -fc 'echo {a,b}'
{a,b}
$ a={a,b} ksh93 -fc 'echo {a,b}'
a b

var='{,}*'; ls -ld $var is like ls -ld * *
var='\{\,\}*'           is like ls -ld '\\'* '\\'*
var='[{][,][}]*'        is like ls -ld [][]* [][]*

{  ,  }

Note: a future version of this standard may extend the conditions under which these characters are special. Therefore applications should quote them whenever they are intended to represent themselves. This does not apply to <hyphen-minus> ('-') since it is in the portable filename character set.

... expand to a single field. It is only field splitting or pathname expansion that can create multiple fields from a single word. The single exception to this rule is the expansion of the special parameter '@' within double-quotes, as described in [xref to 2.5.2].

... shall expand to a single field, except as described below. The shell shall create multiple fields or no fields from a single word only as a result of field splitting, pathname expansion, or the following cases:

1. Parameter expansion of the special parameters '@' and '*', as described in [xref to 2.5.2], can create multiple fields or no fields from a single word.


2. When the expansion occurs in a context where field splitting will be performed, a word that contains all of the following somewhere within it, before any expansions are applied, in the order specified:
   
   
   • an unquoted <left-curly-bracket> ('{') that is not immediately preceded by an unquoted <dollar-sign> ('$'),
   
   
   • one or more unquoted <comma> (',') characters or a sequence that consists of two adjacent <period> ('.') characters surrounded by other characters (which can also be <period> characters), and
   
   
   • an unquoted <right-curly-bracket> ('}')
   
   may be subject to an additional implementation-defined form of expansion that can create multiple fields from a single word. This expansion, if supported, shall be applied before all the other word expansions are applied. The other expansions shall then be applied to each field that results from this expansion.

The shell may support an additional format used for redirection:

{location}redir-op word

where location is non-empty and indicates a location where an integer value can be stored, such as the name of a shell variable. If this format is supported its behavior is implementation-defined.

2. [...] shall be returned.

3. Otherwise, the token identifier TOKEN results.

2. [...] shall result.

3. If the string contains at least three characters, begins with a <left-curly-bracket> ('{') and ends with a <right-curly-bracket> ('}'), and the delimiter character is one of '<' or '>', the token identifier IO_LOCATION may result; if the result is not IO_LOCATION, the token identifier TOKEN shall result.

4. Otherwise, the token identifier TOKEN shall result.

%token IO_LOCATION

io_redirect      :           io_file
                 | IO_NUMBER io_file
                 |           io_here
                 | IO_NUMBER io_here
                 ;

io_redirect      :             io_file
                 | IO_NUMBER   io_file
                 | IO_LOCATION io_file /* Optionally supported */
                 |             io_here
                 | IO_NUMBER   io_here
                 | IO_LOCATION io_here /* Optionally supported */
                 ;

There is no additional rationale provided for this section.

Although this section contains a note indicating that a future version of this standard may extend the conditions under which some characters are special, there are no plans to do so. The note is there to encourage application writers to future-proof their shell code. In some cases existing widespread use of the characters unquoted would preclude them being given a special meaning in those use cases. For example, commas are in widespread use in filenames (notably by RCS and CVS) and it is common to pass the token "{}" as an argument to find and xargs unquoted.

Some shells implement brace expansion which expands, for example, <tt>file{A,B,C}.c</tt> into the fields <tt>fileA.c</tt>, <tt>fileB.c</tt> and <tt>fileC.c</tt> or <tt>file{1..3}.c</tt> into the fields <tt>file1.c</tt>, <tt>file2.c</tt> and <tt>file3.c</tt>. This form of expansion is allowed but not required by this standard, but if supported must be performed before all of the standard word expansions. A variant which some shells implement whereby brace expansion is performed following field splitting was considered by the standard developers and rejected because it causes surprising behavior if the results of parameter expansion and command substitution happen to produce a valid brace expansion. For example, if the shell variable <tt>patt</tt> contains an arbitrary pathname glob pattern applications cannot rely on <tt>some_command -- $patt</tt> passing a list of pathnames that match the pattern to <tt>some_command</tt>. Note that quoting the braces or commas prevents this form of expansion, but quoting the periods need not prevent it.

The limitation to 9 file descriptors is overcome in some shells via a form of redirection whereby a shell variable stores the file descriptor number. For example:

exec {fdvar}> foo

opens the file <tt>foo</tt> on a file descriptor greater than 9 and stores the file descriptor number in shell variable <tt>fdvar</tt>. (This can later be closed using <tt>exec {fdvar}>&-</tt>.) This form of redirection is allowed but not required by this standard.

The optional redirection syntax:

{name}redir-op word

(see [xref to XCU 2.7]) is accommodated in the grammar rules by the optional IO_LOCATION token identifier and two correspondingly optional elements in <tt>io_redirect</tt>. Without these, the grammar would not permit this form of redirection because it would require that, for example, <tt>echo {var}> foo</tt> is parsed such that <tt>{var}</tt> is a WORD to be expanded and passed to echo. The grammar does not restrict the location given between the '{' and '}' in these forms (other than requiring it to be non-empty) since shells may parse an invalid location as part of an <tt>io_redirect</tt> and later treat the invalid location as an error.

~$ a='{a,b}c' bash -c 'echo ${a#{a,b}}'
}c}
~$ a='{a,b}c' ksh -c 'echo ${a#{a,b}}'
c
~$ a='{a,b}c' zsh -c 'echo ${a#{a,b}}'
c
~$ a='{a,b}c' mksh -c 'echo ${a#{a,b}}'
}c}
~$ a='{a,b}c' yash -c 'echo ${a#{a,b}}'
}c}
~$ a='{a,b}c' yash -o braceexpand -c 'echo ${a#{a,b}}'
}c}