tr''' does not work properly #15853
This is a bug report for perl from firstname.lastname@example.org,
Using a single quote as a delimiter in tr or y does not work properly.
The parsing for these commands is split between toke.c and op.c, with
It so happens that the intermediate form is unchanged from the input for
but ranges don't work
tr'a-z'A-Z' # translates only the three chars 'a', '-', 'z'
I haven't investigated \t, etc.
My guess is that it has been broken from the beginning, and it's amazing
One possibility to fix this is to simply prohibit single-quotish
Otherwise, the portion of scan_const that deals with this would have to
should not be evaluated as double-quotish, for example.
Since I don't have much knowledge of the parser's overall operation,
This perlbug was built using Perl 5.25.9 - Thu Jan 19 08:46:21 MST 2017
Site configuration information for perl 5.25.7:
Configured by khw at Fri Nov 18 08:29:04 MST 2016.
Summary of my perl5 (revision 5 version 25 subversion 7) configuration:
@INC for perl 5.25.7:
Environment for perl 5.25.7:
On Mon, 30 Jan 2017 18:24:38 -0800, khw wrote:
We'd need to modify S_tokeq() to handle ranges in single-quotish tr'''.
Possibly it could check for broken unicode to avoid #130675.
I don't think tr''' should support escapes beyond \'
On Mon, 30 Jan 2017 20:04:28 -0800, tonyc wrote:
I don't know why the handling of tr/// is split between op.c and toke.c. I'm now thinking that most of it should be moved to op.c, with the toke.c part merely expanding the single- or double-quotish things. Then there would be no need to have an intermediate form, and I believe the code would be cleaner.
On Mon, 06 Feb 2017 17:05:19 -0800, khw wrote:
I have figured out why it is split between op.c and tr.c. If op.c didn't get it before it was fully parsed, it wouldn't be able to distinguish between things like an interior hyphen was input as a literal, and hence should be treated as a metacharacter; or if it was the expansion of something like \x2D, in which case it isn't a metacharacter. We have the same problem, and have (mostly) solved it, for regex patterns that are compiled separately, but it's work, and has presented a bunch of bugs over the years