New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error producing ^\ (chr 28) with "\c\\" #875
Comments
From newton@ficus.frogspace.netIt appears to be impossible to produce a ^\ character (ASCII 28) Examples: $ perl -wle 'print join ", ", map ord, split //, "\c\"' "\c\\" whould be the correct syntax in my opinion; however, it appears Perl Info
|
From [Unknown Contact. See original ticket],,, writes:
And what would "\c\c\c\c\\" do, in your opinion? ;-) perlop/"Gory details..." Ilya |
From [Unknown Contact. See original ticket](cc'ed to Ilya Zakharevich) On Fri, 19 Nov 1999, Ilya Zakharevich wrote:
My guess is ^\ + 'c' + ^\ + 'c' + '\\', i.e. ASCII 28, 99, 28, 99, 92. And This still doesn't explain to me, though, hough to produce a string |
From [Unknown Contact. See original ticket]On Fri, Nov 19, 1999 at 11:17:03AM -0500, Philip Newton wrote:
So you want it to be parsed kleft-to-right. But you want \c\\ to be
TIMTOWTDI. chr(ord('\\')-62) (or is it 32?) is one of them. Ilya |
From @ysthIn article <19991119124913.F20768@monk.mps.ohio-state.edu>,
He stated he expected either "\c\\" or "\c\" to produce chr(28) and [D:\susv2]perl -wlne "eval I lean toward considering the second of these a bug. |
From [Unknown Contact. See original ticket]Yitzchak Scott-Thoennes writes:
Then read the docs. Ilya |
From @ysthIn article <199911210533.AAA01763@monk.mps.ohio-state.edu>,
Thank you, I already did when you gave the doc reference before. I realise that this behavior is perfectly in accord with perlop/"Gory IMO, it also contradicts the beginning of perlop/"Gory details":
A: "\c\" The question is, is the current incomprehesible behavior of string B |
From [Unknown Contact. See original ticket]Yitzchak Scott-Thoennes writes:
This is taken out of context.
Perl uses a very simple rule to find an end of a quoted construct. Hope this help, |
From @ysthCc'd to: ilya@math.ohio-state.edu In article <199911210756.CAA02439@monk.mps.ohio-state.edu>,
I disagree. This reads to me like a "mission statement" for Perl
Thanks, I thought I already said I understand the docs and behavior But application of these rules of finding the end, left-to-right One of the following should be true in all cases: Currently none of these is true. [D:\]perl -wlne "print map {length,':',map {;' ',ord} split //} eval" In the first case, the string seems to contain two characters: \c\ and \. In the second case, the string should IMO end with the 2nd ". Instead, |
From [Unknown Contact. See original ticket]On Sun, Nov 21, 1999 at 10:04:34AM -0800, Yitzchak Scott-Thoennes wrote:
On the opposite, they *give* \c\ a clear meaning: see qq[\c\c]. Ilya |
From [Unknown Contact. See original ticket]Yitzchak Scott-Thoennes <sthoenna@efn.org> writes:
Yes. -- |
From [Unknown Contact. See original ticket]On Fri, 19 Nov 1999, Ilya Zakharevich wrote:
Not quite. I want '\\' to be translated to \ in a previous pass, before
Well, and "\0x1c" and "\034" work, of course. I was just disappointed that Cheers, |
From [Unknown Contact. See original ticket]On Tue, Nov 23, 1999 at 05:00:24AM -0500, Philip Newton wrote:
Then you are advising that "\\nc" and "\cc" should be parsed the same, right? Ilya |
From @TimToadyPhilip Newton writes: It would have to be done in the same pass, by pretending that \c is a /$foo/ and which have to be passed through to the regular expression engine: /foo$/ Actually, that last one doesn't need to pass $foo--it could conceivably But anyway, we don't cavalierly add multiple passes to Perl. Multiple Larry |
From @ysthCc'd to: larry@wall.org In article <199911231731.JAA16685@kiev.wall.org>,
At last, someone with a glimmer of sense! \c *already* is a funny For instance: $foo = 'bar'; print "\c$foo"; yields 'dfoo', not an error From this, "\c\" should yield chr(28). Alternatively, \c\ should always apply the \c 'operator' to the |
From @ysthCc'd to: nick@ing-simmons.net In article <199911212139.VAA03794@bactrian.ni-s.u-net.com>,
$what='this'; And why? When you understand what I am talking about, feel free to comment. |
From [Unknown Contact. See original ticket]On Tue, 23 Nov 1999, Ilya Zakharevich wrote:
I don't get it. The first I would parse as three characters: backslash Cheers, |
From [Unknown Contact. See original ticket]On Tue, 23 Nov 1999, Larry Wall wrote:
Is this then where the current problem comes from? "\c\\" gets parsed Maybe some magic, then, which makes "\c\\" into one token, which gets Cheers, |
From [Unknown Contact. See original ticket]On Wed, Nov 24, 1999 at 03:10:58AM -0500, Philip Newton wrote:
It should have been, of course, \\cc vs \cc
Nope. You want two backslashes converted to one *before* \c Ilya |
From [Unknown Contact. See original ticket]On Wed, 24 Nov 1999, Ilya Zakharevich wrote:
OK. I see what you mean now. No, I suppose I don't want that. I suppose Cheers, |
From [Unknown Contact. See original ticket]Philip Newton (lists.p5p):
This now makes sense, and that's roughly how I had thunk it should go. It strikes me as being the solution most mentally compatible with the To save someone the bother of bringing up the degenerate case, what the -- |
From [Unknown Contact. See original ticket]On Thu, Nov 25, 1999 at 04:55:59AM -0500, Philip Newton wrote:
you are missing the *most important* point again: closing " is found first. Ilya |
From [Unknown Contact. See original ticket]Simon Cozens writes:
As Larry explains, it breaks many other expectations one has about $a = '\c\\'; does what one expects. Your change will break it. Ilya |
From [Unknown Contact. See original ticket]On Fri, 26 Nov 1999, Ilya Zakharevich wrote:
Yes, but according to perlop/Gory Details, while searching for the closing
After this, backslash+delimiter are turned into plain delimiter (while Hmmm, I think I begin to understand. No change is needed for Cheers, |
From [Unknown Contact. See original ticket]On Fri, Nov 26, 1999 at 07:26:36AM -0500, Philip Newton wrote:
This is how I would expect things work.
This will break compatibility with $x = 'whatever'; It is not win-win situation. Being such, I do not feel any urge to Ilya |
From [Unknown Contact. See original ticket]On Sat, 27 Nov 1999, Ilya Zakharevich wrote:
I do not understand. Please provide a concrete example. Cheers, |
From guido@imperia.netHi! My perl version is 5.8.8. In the following I use vi notation for control When I wanted to include CTRL-\ in a double quoted string with \c $ print "a\c\\nb"; It turns out that this yields ``a^\^Jb''. In other words: \c consumes print "...\c\"; This will not work, because the backslash escapes the trailing quote. print "...\c\\"; This compiles but produces the string ``...^\\'' instead of ``...^\'', Of course, I can use other means like octal or hexadecimal escapes. But IMHO the correct solution would be to represent CTRL-\ as "\c\\". At the Cheers, |
Migrated from rt.perl.org#1806 (status was 'resolved')
Searchable as RT1806$
The text was updated successfully, but these errors were encountered: