cc: austin-group-l@opengroup.org
Subject: Re: Austin Interps 211
--------
I have a number of concerns with this solution. I am concerned
that this is leading back to the System V vs. BSD echo problem
where the processing of escape sequences was left to echo rather
than to the shell. Aren't other utilities going to need
unicode characters as arguments?
The proposed solution has the potential for breaking existing
scripts.
It isn't clear whether these escape sequences would be used by the %b
format specifier for just for the printf format itself.
In my opinion, a better solution would be to adopt a mechanism
that was introduced by ksh93 is used by several other existing shells
such bash and zsh and is compatible with the current POSIX standard
so that no strictly conforming application could break.
The idea is to add literal string constants of the form
$'...'
where ... exactly follows the rules for C99 string constants "...",
except that the character ' must be preceded by a \ and
that " is not required to be preceded by a \.
bash, zsh, and ksh already mimic C string literal catenation
printf $'\x41'$'AA\n'
which, for the ascii codeset, prints
AAA
In my opinion it would be better to adopt $'...' rather than
to introduce C escape sequence incompatibilities in the shell spec.
A side effect of deferring to $'...' is that its definition and
implementation is entirely in the shell, eliminating the need for
any other utility to interpret operands containing C escape sequences.
Imagine how much trouble $'...' would have avoided re echo(1) alone.
Again, proposing a more general shell extension would be much better
than imposing a (C standard) incompatible limitation
David Korn
dgk@research.att.com
|