Email List: Xaustin-group-lX
[All Lists]

Re: Austin Interps 211

To: austin-group-l@xxxxxxxxxxxxx, marquis@xxxxxxxxx
Subject: Re: Austin Interps 211
From: Glenn Fowler <gsf@xxxxxxxxxxxxxxxx>
Date: Mon, 23 Jun 2008 14:07:05 -0400
Organization: AT&T Research
References: <200806171819.m5HIJAfo027636@penguin.research.att.com> <20080623171832.B49C12B779E@mx5.roble.com>
On Mon, 23 Jun 2008 10:18:32 -0700 (PDT) Roger Marquis wrote:
> David Korn wrote:
> > 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 $'...'

> A few real-world examples might help better define what this quote syntax
> will accomplish.  Same with new escape sequences.  I have not personally
> seen much call for either, though their potential for creating
> incompatibilities is clear.  Accordingly, my question would be whether
> POSIX should be considering these features in the first place?

the "call" was introduced by the proposed solution for \x... in printf(3) 
formats

the issue in this case is
(1) adding an incompatibility between printf(1) and printf(3) in the
    way \x.. is parsed, and solves the problem only for one utility
vs.
(2) adding a sh(1) feature, already implemented in { bash ksh zsh },
    that does not introduce the printf(3) incompatibility, and solved
    the problem for all utilities

in particular, sh $'...'$'...' catenation mimics C "..." "..." catenation:

        $'\xabc'$'def\n' vs "\xabc" "def\n"

-- Glenn Fowler -- AT&T Research, Florham Park NJ --

<Prev in Thread] Current Thread [Next in Thread>