(0000590)
Don Cragun (manager)
2010-10-25 06:17
edited on: 2010-12-09 16:12
|
The following is a complete replacement for the Desired Action to
be taken to resolve this issue. It is based on other notes in this
bug report, numerous e-mail messages on the austin-group-l
alias, and discussions held during Austin Group conference calls:
In XCU section 2.2 (Quoting) change:
"The various quoting mechanisms are the escape character,
single-quotes, and double-quotes."
on P2298, L72359 to:
"The various quoting mechanisms are the escape character,
single-quotes, double-quotes, and dollar-single-quotes."
Add the following new paragraph to XCU section 2.2.3 (Double-Quotes)
after P2298, L72385 (indented to the same level as the paragraph
on L72382-72385):
"The <dollar-sign> shall not retain its special meaning
introducing the dollar-single-quotes form of quoting (see
[xref to 2.2.4])."
In XCU 2.2.3 (Double-Quotes) change:
"A single-quoted or double-quoted string that begins, but
does not end, within the "‘...‘" sequence"
on P2299, L72392-72393 to:
"A quoted (single-quoted, double-quoted, or dollar-single-quoted)
string that begins, but does not end, within the "‘...‘"
sequence"
At the end of XCU section 2.2 after P2299, L72401 add a new subsection,
with this text:
2.2.4 Dollar-Single-Quotes
A sequence of characters starting with a <dollar-sign>
immediately followed by a single-quote ($') shall preserve
the literal value of all characters up to an unescaped
terminating single-quote ('), with the exception of certain
backslash escape sequences, as follows:
\" yields a <quotation-mark> (double-quote) character.
\' yields an <apostrophe> (single-quote) character.
\\ yields a <backslash> character.
\a yields an <alert> character.
\b yields a <backspace> character.
\e yields an <ESC> character.
\f yields a <form-feed>> character.
\n yields a <newline> character.
\r yields a <carriage-return> character.
\t yields a <tab> character.
\v yields a <vertical-tab> character.
\cX yields the control character listed in the Value
column of Table 4.21 on page 3203 (xref to
XCU Table 4.21) in the Operands section of
the stty utility when X is one of the
characters listed in the ^c column of the
same table, except that \c\\ yields the
<FS> control character since the <backslash>
character must be escaped.
\uXXXX yields the character specified by ISO/IEC 10646
whose four-digit short universal character
name is XXXX (and whose eight-digit short
universal character name is 0000XXXX).
\UXXXXXXXX yields the character specified by ISO/IEC
10646 whose eight-digit short universal
character name is XXXXXXXX.
\xXX yields the byte whose value is the hexadecimal
value XX (one or two hex digits)
\XXX yields the byte whose value is the octal value XXX
(one to three octal digits)
If a \xXX or \XXX escape sequence yields a byte whose value
is 0, that byte and any following regular characters and
escape sequences up to the terminating unescaped single-quote
shall be evaluated and discarded.
If a universal character name specified by \uXXXX or
\UXXXXXXXX is less than 00A0 other than 0024 ($), 0040 (@),
or 0060('), the results are undefined. If a universal
character name specified by \uXXXX or \UXXXXXXXX is in the
range D800 through DFFF inclusive, the results are undefined.
If more than two hexadecimal digits immediately follow \x or
if the octal value specified by \XXX will not fit in a byte, the
results are unspecified.
If a backslash is followed by any sequence not listed above
or if \e, \cX, \uXXXX, or \UXXXXXXXX yields a character
that is not present in the current locale, the result is
implementation-defined.
If a backslash escape sequence represents a single-quote
character (for example \u0060, \U00000060, or \'), that
sequence shall not terminate the dollar-single-quote
sequence.
In XCU section 2.3 (Token Recognition) point 4, change:
"If the current character is <backslash>, single-quote, or
double-quote and it is not quoted, it shall affect quoting
for subsequent characters up to the end of the quoted text.
The rules for quoting are as described in Section 2.2 (on
page 2298). During token recognition no substitutions shall
be actually performed, and the result token shall contain
exactly the characters that appear in the input (except for
<newline> joining), unmodified, including any embedded or
enclosing quotes or substitution operators, between the
<quotationmark> and the end of the quoted text. The token
shall not be delimited by the end of the quoted field."
on P2299-2300, L72425-72432 to:
"If the current character is an unquoted <backslash>,
single-quote, or double-quote or is the first character of
an unquoted <dollar-sign> single-quote sequence, it shall
affect quoting for subsequent characters up to the end of
the quoted text. The rules for quoting are as described
in Section 2.2 (on page 2298). During token recognition no
substitutions shall be actually performed, and the result
token shall contain exactly the characters that appear in
the input (except for <newline> joining), unmodified,
including any embedded or enclosing quotes or substitution
operators, between the start and the end of the quoted text.
The token shall not be delimited by the end of the quoted
field."
In XCU section 2.6, add:
* a <single-quote>
to the end of the list created by the changes identified in Mantis
BugID 49. (BugID 49 modifies text on P2305, L72669-72671 in XCU7.)
In XCU 2.6.3 (Command Substitution) change:
"A single-quoted or double-quoted string that begins, but
does not end, within the "‘...‘" sequence produces undefined
results."
on P2309, L72827-72829 to:
"A quoted string that begins, but does not end, within the
"‘...‘" sequence produces undefined results."
In XCU section 2.6.7 (Quote Removal), change:
"The quote characters (<backslash>, single-quote, and
double-quote) that were present in the original word shall
be removed unless they have themselves been quoted."
on P2311, L72904-72905 to:
"The quote character sequence <dollar-sign> single-quote
and the characters (<backslash>, single-quote, and
double-quote) that were present in the original word shall
be removed unless they have themselves been quoted."
In the Note in XCU section 2.10.2 (Shell Grammar Rules) rule 1, change:
"Because at this point <quotation-mark> characters are
retained in the token, quoted strings cannot be recognized
as reserved words."
on P2325, L73436-73437 to:
"Because at this point quoting characters (<backslash>,
single-quote, <quotation-mark>, and the <dollar-sign>
single-quote sequence) are retained in the token, quoted
strings cannot be recognized as reserved words."
Add a new section in XRAT following P3649, L124068:
<italic>C.2.2.4 Dollar-Single-Quotes</italic>
The $'...' quoting construct has been implemented
in several recent shells. It is similar to
character string literals ("...") in the C Standard
with the following exceptions:
1. The \x escape sequence in C can be followed by an
arbitrary number of hexadecimal digits. The
ksh93 implementation of $'...' also consumes
an arbitrary number of hexadecimal digits; bash
consumes at most two hexadecimal digits in this
case. This standard leaves the result unspecified
if more than two hexadecimal digits follow \x.
(Note that a hexadecimal escape followed by a
literal hexadecimal character can always be
represented as $'\xXX'X)
2. The \c escape sequence is not included in the C
standard. There was also some disagreement in
shells that historically supported \c escape
sequences in $'...'. These include:
A. whether \cA through \cZ produced the byte values
1 through 26, respectively or supported the
codeset independent control character as
specified by the stty utility. This standard
requires codeset independence.
B. whether \c[, \c\\, \c], \c^, \c_, and \? could
be used to yield the <ESC>, <FS>, <GS>,
<RS>, <US>, and <DEL> control characters,
respectively. This standard requires support
for all of the control characters except
NULL (matching what is done in the stty
utility).
C. whether \c\\ or \c\ was used to represent <FS>.
This standard requires \c\\ to make backslash
escape processing consistent.
The implementors of the most common shells that
implement $'\cX' agreed to convert to the
behavior specified in this standard.
Some shells also allow \c<arbitrary_control_character>
to act as an inverse function to \cX (i.e., \cm
and \cM yield <CR> and \c<CR> yields m or M.
This standard leaves this behavior
implementation-defined.
3. The \e escape sequence is not included in the C
Standard, but was provided by all historical
shells that supported $'...'. Some also supported
\E as a synonym. One member of the group
objected to adding \e because the <ESC> control
character is not required to be in the portable
character set. The \e sequence is included
because many historical users of $'...' expect
it to be there. The \E sequence is not included
in this standard because <backslash> escape
sequences that start with <backslash> followed
by an uppercase letter (except \U) are reserved
by the C Standard for implementation use.
4. The \XXX octal escape sequence and the \xXX
hexadecimal escape sequence can be used to
insert a null byte into a C Standard character
string literal and into a $'...' quoted word
in this standard. In C, any characters specified
after that null byte (including escape sequences)
continue to be processed and added to the
expansion of the character string literal. In
$'...' in the shell, however, this standard
requires the null byte and all remaining
characters up to the terminating unescaped
single-quote be evaluated and discarded. (This
was historic practice in bash, but not in ksh93.)
This allows an escape sequence producing a null
byte to terminate the dollar-single-quoted
expansion, but not terminate the token in which
it appears if there are characters remaining
in the token. For example:
printf a$'b\0c\''d
is required by this standard to produce:
abd
while historic versions of ksh93 produced:
ab
5. The double-quote (") character can be used
literally, while the single-quote (') character must
be represented as an escape sequence. In C,
single-quote can be used literally, while
double-quote requires an escape sequence.
In C, if a character specified by \uXXXX or \UXXXXXXXX
in "..." does not exist in the execution character
set, the results are implementation-defined.
Similarly, this standard makes the results
implementation-defined if \e, \cX, \uXXXX, or
\UXXXXXXXX specifies a character that is not present
in the current locale.
Note that the escape sequences recognized by $'...',
file format notation (see Table 5-1 on page 121),
XSI-conforming implementations of the echo utility
(see the echo utility's operands section on page
2615), and the printf utility's format operand (see
the printf utility's extended description section
on page 3050) are not the same. Some escape sequences
are not recognized by all of the above, the \c
escape sequence in echo is not at all like the \c
escape sequence in $'...', octal escape sequences
in some of the above accept one to four octal digits
and require a leading zero while others accept one
to three octal digits and do not require a leading
zero.
|
n1534.htm [^] (1,668 bytes) 2010-11-05 14:54
