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
PathTools-3.27 triggers a bug in Perl #9343
Comments
From @janduboisThe update to PathTools-3.27 triggers a bug in the localization of $1: #!perl print File::Spec::Win32->catfile("c:/foo", "bar"), "\n"; With PathTools-3.27: With older version of PathTools: The problem seems to be that $1 isn't properly localized. A simple sub _canon_cat(@) But it would be nicer if the problem can be solved in a more general I encountered this problem when I was testing Pod::Simple with if( ref($chunk->[-1]) and Cheers, |
From @rgs2008/5/23 via RT Jan Dubois <perlbug-followup@perl.org>:
Does that happen also with older perls ? |
The RT System itself - Status changed from 'new' to 'open' |
From @janduboisOn Sat, 24 May 2008, Rafael Garcia-Suarez wrote:
Yes, it happens with 5.6.1 and 5.8.0 too. All you have to do to reproduce it is copy the lib/File/Spec/Win32.pm Cheers, |
From @jkeenanOn Sat May 24 07:52:30 2008, jdb wrote:
Path-Tools is a CPAN distribution. In the Perl 5 core distribution, Be that as it may, I can't seem to reproduce this on Perl 5.18.0 on ##### print File::Spec->catfile("c:/foo", "bar"), "\n"; Is this ticket closable? Thank you very much. |
From @cpansproutOn Sat Aug 03 17:05:29 2013, jkeenan wrote:
dist/Cwd *is* PathTools. blead is upstream. The CPAN distribution name Bugs relating to PathTools modules in general can go in this tracker. Yes, it’s a mess. (And I don’t know why the CPAN Makefile.PL cannot be in core.)
I don’t know the answer to that. -- Father Chrysostomos |
From @cpansproutOn Sat Aug 03 17:29:47 2013, sprout wrote:
Sorry, that was meant to be an informative note, but it turned into a rant. -- Father Chrysostomos |
From victor@vsespb.ru
tested on linux, perl 5.10.1 bug persists with PathTools 3.27 3.26 seems bug is fixed, there is changelog entry: https://metacpan.org/source/SMUELLER/PathTools-3.29/Changes#L24 related tickets: http://perlmonks.org/?node_id=671025 |
From @chornyThis ticket can be viewed as two tickets: "2" =~ m/(.*)/; sub test1 { Can it be considered a bug? 2013/8/4 James E Keenan via RT <perlbug-followup@perl.org>:
-- |
From @maukeOn 04.08.2013 15:12, Alexandr Ciornii wrote:
I don't see it as a bug. 1) "2" =~ m/(.*)/ sets $1 to "2". -- |
From @jkeenanOn Sun Aug 04 06:14:16 2013, chorny wrote:
No, I don't think so. With this line:
... you have made a new assignment to global variable $1. Hence, you ##### I'll take this ticket for the purpose of closing it within 7 days unless Thank you very much. |
From victor@vsespb.ruLet's try replace "$1" with $x in your example and explanation (and ######## $x = 2; sub test1 { 1) $x=2 sets $x to "2". ######### However it's not true. This example with "$x" prints 1/2 Anyway, even if we find it's not a bug, it's unique situation and can be On Sun Aug 04 06:52:21 2013, plokinom@gmail.com wrote:
|
From victor@vsespb.ruSo, it looks like a bug to me. 1) two explanation above, with aliasing and localized global vars does 2) Sometimes subroutines just cannot copy arguments ( my ($a, $b) = @_ ) And if it uses regexps, there is no way to prevent such issues, except On Sun Aug 04 11:13:19 2013, vsespb wrote:
|
From @iabynOn Sun, Aug 04, 2013 at 04:28:32PM -0700, Victor Efimov via RT wrote:
Except that $1 etc are *not* localised. The thing that is localised is the -- |
From victor@vsespb.ruOn Mon Aug 05 03:51:38 2013, davem wrote:
Isn't it unclearly documented? (both cases declared as "dynamically-scoped") http://perldoc.perl.org/perlvar.html http://perldoc.perl.org/perlsub.html Also, isn't this a misfeature? Seems we're going drop things like empty regexps |
From @iabynOn Mon, Aug 05, 2013 at 08:42:48AM -0700, Victor Efimov via RT wrote:
Quite possibly
That's because they're both dynamically (as opposed to lexically) scoped.
I don't see why.
If we were to set every capture var ($1,$2,...) on every match, rather than -- |
From victor@vsespb.ruOn Tue Aug 06 04:24:55 2013, davem wrote:
a) is there a valid case when user indeed wants 'aa' =~ m/(.)/ to modify "2" =~ m/(.*)/; sub test1 { b) I think using regexps with capture groups, before using $_[], or @_, |
From @iabynOn Tue, Aug 06, 2013 at 04:42:20AM -0700, Victor Efimov via RT wrote:
Probably not, but in the same way that the user probably doesn't want sub f { $_ = 1 } to modify $_[0], but it will if called as f($_); In what ever way that $1 et al are implemented, there will be strange edge
I think any code that passes raw global 'magic' vars as args to subs (e.g. foo( -- |
From victor@vsespb.ruOn Tue Aug 06 06:32:12 2013, davem wrote:
if $_ is localized, then code sub f { local $_ = 1; print $_[0] } prints 22, so $_[0] is not modified. is subroutine intention is to modify global $_, it should be documented, subroutine that does not localize $_ and does not document this,
Ok, get it. So caller responsible for this. Then it's probably thing to |
From @jkeenanOn Sun Aug 04 06:56:58 2013, jkeenan wrote:
Since there has been extensive back-and-forth in this RT since Sunday, I Nonetheless, I still don't believe there is a bug in Perl here. Thank you very much. |
From victor@vsespb.ru1) How about notice in perlvar: before this paragraph: "Due to an unfortunate accident of Perl's implementation, use English (I am not submitting patch, because almost sure exact wording can be 2) Would it be useful if I try to improve tests for this (probably On Tue Aug 06 06:44:56 2013, vsespb wrote:
|
From @epaIMHO, this is a longstanding misfeature in Perl. It is easy to write our $options = 'debug'; And it is also easy to write my $x = '123'; No warning is given in either case. So, depending on which way you look at It would be far better if $1 were truly localized, so that the regexp match It would even be better, or at least easier to understand, if $1 were global. But at present $1 exists in a strange halfway house where it is neither truly our $o; Even though foo() is setting the value of $o, this doesn't break the -- |
From @iabynOn Fri, Aug 09, 2013 at 10:26:37AM +0000, Ed Avis wrote:
In this respect, sub f { open my $fh, $0 or die;
Well yes, but for a successful match, this would involve: * for $1: Which collectively would impose a significant performance penalty for each Potentially these vars could remain magic, but when localised, a new var with -- |
From @epaDave Mitchell <davem <at> iabyn.com> writes:
You are right to note that $. and other punctuation variables have the I suggested that $1 should be 'localized properly' but you noted that this A simpler answer, I suggest, is that when variables like -- |
From victor@vsespb.ruIt looks to me that example with sub f { open my $fh, $0 or die; __END__ 2013/8/20 Ed Avis <eda@waniasset.com>
|
I suggest closing this ticket. I get that it is 2 issues and the first related to the title has been addressed. What I suggest is that if localizing $1 is important then that sounds like a new issue that should be discussed in its own issue. |
Yes. Anyone who believes that localizing $1 is important should open a new issue. Closing this one. Thank you very much. |
Migrated from rt.perl.org#54728 (status was 'open')
Searchable as RT54728$
The text was updated successfully, but these errors were encountered: