2019-06-25 08:51:38 +0100, Harald van Dijk: [...] > > IFS='|' > > text='foo|bar' > > for i in $text; do... > > All of these are fine, since it is about shell special characters during > pattern matching. All the special characters in your examples are removed > before pattern matching starts.
Well, then make it: text='foo|bar' echo $text or: IFS= text='foo bar' echo $text or text='Blah blah; blah blah.' echo $text or echo $BASH_VERSION (BASH_VERSION containing something like 4.4.19(1)-release) A position that states that leaving parameter expansions unquoted if they contain "shell special characters" (unless found in $IFS) leads to unspecified results is not tenable (and probably contradicts other parts of the standard and examples in the spec). > > "special character" is also not defined (or in the "Definitions" > > chapter refers to something different). * and ? are also > > refered to as special characters later on in the spec. > > True, it should be defined, but the rationale makes it clear that > parentheses are considered to be shell special characters in the context of > pattern matching. See xrat/V4_xcu_chap02.html: > > > To find a filename that contained shell special characters or pattern > > characters, both quoting and escaping are required, such as: > > > > pax -r ... "*a\(\?" > > > > to extract a filename ending with "a(?". > > There is nothing that makes an exception for unquoted characters coming from > expansions, and there should not be. [...] As the examples above show, there clearly should. So now POSIX needs to clearly specify which are those "special characters" that need quoted and escaped and in which circumstance. That text was probably only to accomodate ast-open/ksh, and it again overlooked the case of globs in word expansions. We should be able to limit the damage to ( and \ when not inside bracket expressions (and in the case of pathname generation, clarify that the presence of \ and ( alone is not enough to trigger pathname expansion). -- Stephane
