develooper Front page | perl.perl5.porters | Postings from November 1999

Re: [ID 19991118.014] Error producing ^\ (chr 28) with "\c\\"

Thread Previous | Thread Next
November 21, 1999 11:56
Re: [ID 19991118.014] Error producing ^\ (chr 28) with "\c\\"
Message ID:
Cc'd to:

In article <>,
Ilya Zakharevich <> wrote:
>Yitzchak Scott-Thoennes writes:
>> I realise that this behavior is perfectly in accord with perlop/"Gory
>> details"/"Finding the end".  That doesn't mean it's not a bug.  It
>> just means that if it is a code bug it is also a doc bug.
>> IMO, it also contradicts the beginning of perlop/"Gory details":
>> >       When presented with something which may have several
>> >       different interpretations, Perl uses the principle DWIM
>> >       (expanded to Do What I Mean - not what I wrote) to pick up
>> >       the most probable interpretation of the source.
>This is taken out of context.

I disagree.  This reads to me like a "mission statement" for Perl
parsing.  If one of the many detailed parsing rules that follow
violate this statement, then that is an indication that a modification
may be necessary.

>> A: "\c\"
>> B: "\c\"more string here"
>> The question is, is the current incomprehesible behavior of string B
>> more important to maintain than following DWIM for "string" A?
>Perl uses a very simple rule to find an end of a quoted construct.
>All one needs to do is to learn it.
>Hope this help,

Thanks, I thought I already said I understand the docs and behavior
for finding the end of a quoted construct are in agreement.

But application of these rules of finding the end, left-to-right
parse, etc. leaves the \c\ construct without a clear meaning.

One of the following should be true in all cases:
1. \c\ produces a fatal exception
2. the second \ is a escape character and the following character is 
   the 'argument' to \c
3. the \ is the 'argument' to \c and the following character is unaffected
4. the behavior is undefined and a warning is given

Currently none of these is true.
The behavior is pretty close to number 3 except for a couple of odd cases:

[D:\]perl -wlne "print map {length,':',map {;' ',ord} split //} eval"
2: 28 92
1: 98

In the first case, the string seems to contain two characters: \c\ and \.
The anomaly is that the trailing backslash doesn't escape the ".

In the second case, the string should IMO end with the 2nd ".  Instead,
the 2nd \ of \c\ escapes it, contrary to \c\ behavior elsewhere.  Thus
the string becomes \c" -> chr((ord('"')-64) & 127) -> b.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About