On Wed, 25 Sep 2013 17:05:31 +0200 Irek Szczesniak wrote:
> On Thu, Sep 19, 2013 at 3:46 PM, Cedric Blancher
> <[email protected]> wrote:
> > On 19 September 2013 10:49, Wendy Lin <[email protected]> wrote:
> >> I have a request about LC_OPTIONS=unicode. I believe the name
> >> 'unicode' is too generic
> >
> > +1
> >
> >> and should better describe what it does.
> >> The first patch from Roland Mainz I saw used set -o convunicode, for
> >> "convert to unicode". I think this, or 'convunicodeliterals', would be
> >> a more fitting and descriptive name.
> >
> > "convunicodeliterals" is too long. Either "unicodeliterals" or
> > "convunicode" would do it nicely :)
> I'd prefer unicodeliterals, but would accept convunicode, too. Just
> unicode is too generic. But I am also concerned about Olga's comment
> about print -C to print compound variables using such literals. How do
> we do that without tinkering with LC_OPTIONS each time? Add -U/+U as
> requested by Olga?
there are a few other ksh places where this may have an effect
typeset -p and maybe a few other places where ksh offers a -p option
to produce output that can be re-comsumed by the shell
there's probably a connection with -x tracing too
"unicodeliterals" is a fine solution and I'll put that in right now
but I think it would be good to step back just a bit and list all
of the places where "unicodeliterals" should take affect, at first
*without proposing a solution*
for ksh we already have
print -C
typeset -p
set -x
any others, in or out of ksh?
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
