File::Glob ':glob' causes infinite loop #11542
Comments
From jpl@research.att.comCreated by jpl@research.att.comFor background, please visit http://www.perlmonks.org/?node_id=917494 A user there could not use the standard glob, because a directory contained use File::Glob ':glob'; his while (glob "$folder/*.txt") looped forever. I initially argued this was not a bug, because bsd_glob At the very least, the incompatible behavior of ':glob' in scalar context $last_entry = glob($pattern); to get just the last matching entry would start getting the first matching #!/usr/bin/perl -w use strict; my $dir = shift || "/etc"; Run it, uncomment the use File::Glob ':glob', and rerun it Perl Info |
From @epaOr instead might it make sense to fix the core glob() so that it doesn't |
|
The RT System itself - Status changed from 'new' to 'open' |
From jpl@research.att.comUnfortunately, that's a "feature", not a "bug". Spaces delimit separate On 08/03/11 10:09, Ed Avis via RT wrote:
|
From @davidnicolperhaps null-delim option could be introduced, in keeping with the find ... -print0 | xargs --null ... style of dealing with spaces? On Wed, Aug 3, 2011 at 9:21 AM, John P. Linderman (jpl)
|
From @epaJohn P. Linderman (jpl <jpl <at> research.att.com> writes:
There must be lots of programs that rely on that. But are they not outnumbered $wildcard = shift @ARGV; OK, so that code is broken and has always been broken. But it's not uncommon, <http://www.google.com/codesearch#search/&q=glob\%28\$%20lang:^perl$&type=cs> It's all rather unfortunate, since the '*.c *.h' behaviour can easily be had by -- |
From jpl@research.att.comLooks like a reasonable possibility. I don't know if the anonymous monk in http://www.perlmonks.org/?node_id=917494 was a jerk or a genius when he said /making bsd_glob DWIM in scalar context is trivial (just copy/paste from I poked around in op.c (to no avail). But someone who knew what they On 08/03/11 11:35, David Nicol wrote:
|
From @TuxOn Wed, 3 Aug 2011 15:39:57 +0000 (UTC), Ed Avis <eda@waniasset.com>
Which is documented not to be reliable. <*.h *.c > => glob ("*.h *.c");
Which is even safer, but also requires more typing and causes noise
-- |
From jpl@research.att.comOn 08/03/11 11:35, David Nicol wrote:
Well. Here's a proof of concept run with a modified 5.14.1: PERL5LIB=/home/jpl/src/perl-5.14.1/lib ./perl -de 0 Loading DB routines from perl5db.pl version 1.33 Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 0 DB<2> print(scalar(glob('/tmp/dir with spaces/*')), "\n") for (1 DB<3> print($_, "\n") while (glob('/tmp/dir with spaces/*')) Obviously, "obglay" (pig latin for glob, and a near anagram of make test ran successfully. But please have somebody knowledgable gaze at the |
From jpl@research.att.com*** Makefile.PL.orig Wed Aug 3 13:15:58 2011 |
From sidhekin@allverden.noOn Wed, Aug 3, 2011 at 7:47 PM, John P. Linderman (jpl) <
By which you mean "space is not a delimiter". How about telling what the Eirik |
From jpl@research.att.comOn 08/03/11 13:59, The Sidhekin wrote:
http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality I'm quite satisfied to have come up with what appears to be a workable |
From jpl@research.att.comOn 08/03/11 14:07, John P. Linderman (jpl) wrote:
|
From jpl@research.att.comEd Avis <eda@waniasset.com> noted:
There must be lots of programs that rely on that. But are they not outnumbered $wildcard = shift @ARGV; OK, so that code is broken and has always been broken. But it's not uncommon, <http://www.google.com/codesearch#search/&q=glob\%28\$%20lang:^perl$&type=cs> It's all rather unfortunate, since the '*.c *.h' behaviour can easily be had by One reason this bug has gone (relatively) unnoticed for so long is that use File::Glob (':glob'); but not when it is missing use File::Glob (':globally'); That seems totally backwards; it seems like the extra argument is |
From @epaI guess that although glob("$dirname/*") breaks for directory names Perhaps there is a case for making glob taint-check its argument under my $dirname = shift @ARGV; But who does that? What tutorial would teach it as a safe habit? my $dirname = shift @ARGV; That seems dirty, and won't work under Windows, where glob() takes So we have to conclude that glob() for a user-supplied string is never It's analogous to the situation with two-argument open. The only @g = safe_glob literal($dirname), dir_sep(), wildcard('*'); That would be unlikely to catch on because "$dirname/*" is so much -- |
From @davidnicolOn Wed, Aug 3, 2011 at 1:07 PM, John P. Linderman (jpl)
Nah, still engineering the roof and walls. How about a new LNV (Line Noise Variable) (with a slot in the hints my @SourceFilesWithSpaceAtNameEndList = do { local $Glob::delim = perldoc File::Glob says Since v5.6.0, Perl's CORE::glob() is implemented in terms of How about, when CORE::glob gets more than one argument, it doesn't split them? my @SourceFilesWithSpaceAtNameEndList = glob("* .h","* .c"); Is that a self-shedding bicycle or what? |
From @leonerdOn Thu, Aug 04, 2011 at 02:08:50PM +0000, Ed Avis wrote:
I am in mind of DBI's placeholders. We can't use ? obviously, so @g = safe_glob "%p/*", $dirname; Where %p gets expanded sprintf-style, by quoting any metacharacters in -- leonerd@leonerd.org.uk |
From sidhekin@allverden.noOn Thu, Aug 4, 2011 at 5:13 PM, Paul LeoNerd Evans
If you want a literal path and matching on the basename, why glob? To me, readdir and good old-fashioned pattern matching seem an obvious @g = do { opendir my $h, $dirname; map{ /^\./ ? () : "$dirname/$_" } Eirik |
From @epaPaul LeoNerd Evans <leonerd <at> leonerd.org.uk> writes:
I was about to suggest the same thing. There could be three %e a single path element, that is, cannot contain '/' The same scheme could be used in a File::Spec type interface for my $directory = shift @ARGV; That would be a safer alternative to string interpolation, which can I think that two-arg open() and glob() are the only two places in perl -- |
From jpl@research.att.comOn 08/04/11 11:01, David Nicol wrote:
It's becoming clear to me that the Glob.pm documentation needs /# NOTE: The glob() export is only here for compatibility with 5.6.0. I still haven't figured out what it causes, but if I step through a call See you in a week and a half -- jpl |
From @davidnicolOn Thu, Aug 4, 2011 at 1:28 PM, John P. Linderman (jpl)
I retract my earlier proposal in favor of this one. The 11:01 proposal my @EvenMore = glob(['even more.*']); -- |
From jpl@research.att.comOn 08/04/11 19:12, David Nicol wrote:
One of the things I really enjoy about the porters is that they are more |
From @cpansproutOn Thu Aug 04 03:16:05 2011, jpl@research.att.com wrote:
<http://www.google.com/codesearch#search/&q=glob\%28\$%20lang:^perl$&type=cs>
File::Glob::glob explicitly ignores its second argument: sub glob { What you are seeing above is a B::Deparse bug, fixed in 5.14.0.
|
From @cpansproutOn Thu Aug 04 07:09:35 2011, eda@waniasset.com wrote:
The worst breakage is that a glob pattern with spaces gets backslash @files = <\\\\\\\\* .*>; Fortunately, I’ve fixed that, so you only need four backslashes now. How I wish <> had been implemented originally like a regexp literal!
Slash also works. From ext/File-Glob/bsd_glob.c: #define BG_SEP '/' |
From @cpansproutOn Thu Aug 04 08:02:11 2011, davidnicol@gmail.com wrote:
Then glob(@list_of_patterns) does the unexpected when there is only one. |
From @epaFather Chrysostomos via RT <perlbug-followup <at> perl.org> writes:
That's great news! <g> I do wonder why this particular bug is considered a bug to be fixed,
Yup, but since backslash works too, the business of backslash-escaping glob -- |
From jpl@research.att.comOn 10/26/11 01:57, Father Chrysostomos via RT wrote:
There are (at least:-) ) two problems here. One is that the synopsis says SYNOPSIS But tag ":glob" includes tag 'glob', which can lead to infinite looping while (<*.c>) { ... } That makes tag 'glob' very dangerous, so it should not be invoked by $lastfile = <*.c>; to return the last matching file name (which it does), so we cannot The other problem is getting glob to recognize blanks in file names, use File::Glob ':glob'; in the first place, since, by default, blanks separate distinct while (my $file = glob(['*.c', '*.h', 'em bedded*.txt'])); # works I lack the smarts to fix this, and having glob() work but <> not work is |
From @cpansproutOn Wed Oct 26 03:00:32 2011, eda@waniasset.com wrote:
Because it wasn’t self-consistent. These two patterns produced the same <\\\\\\\\* .*> <{\\\\,.}*>
A *lot* of existing code.
|
From @cpansproutOn Wed Oct 26 05:20:00 2011, jpl@research.att.com wrote:
I think that is acceptable, as <> is a quote-like operator. See my I’ve already started working through the pile of bugs I described there. But as for glob([...]), I think a pragma (or import option) and a plain Since people already know that bsd_glob() does not split on spaces, we I can think of several other interfaces, but this is the one I prefer. |
From tchrist@perl.comGiven: % mkdir /tmp/sandbox % perl -E 'say for <*e f*>' % perl -E 'say for <"*e f*">' % perl -E '$v = "e"; say for <"*{$e} f*">' No code needs changing, only doc. I thus propose: The C<glob> function grandfathers the use of whitespace to separate @spacies = <"*e f*">; If you had to get a variable through, you could do this: @spacies = glob "'*${var}e f*'"; Alternately, you can use the C<File::Glob> module directly, so --tom |
From @cpansproutOn Wed Oct 26 08:55:56 2011, tom christiansen wrote:
I think both need changing. See Also, File::Glob::glob is completely broken and should be deprecated and Also, I would like <...> to be more like a regexp literal under ‘use <*\**> to find files containing ‘*’. That currently is equivalent to <*>.
|
From jpl@research.att.comOn 10/26/11 11:46, Father Chrysostomos via RT wrote:
Somehow, I never saw that. I'm in (pretty much) total agreement.
This sounds great! My primary concern has been that the synopsis for
|
From @cpansproutAlthough this is a discussion about glob in particular, I’d like to make On Wed Oct 26 09:40:56 2011, jpl@research.att.com wrote:
This is complicated, not in terms of actually writing the code, but in If we make glob truly overridable under ‘use v5.16’, then we have the We could continue to have that work for <...>, but then how does Also, the while(glob...) magic (implicit defined()) disappears if all we If we make all keywords overridable, then we also have the problem of |
From @cpansproutOn Thu Oct 27 12:58:36 2011, sprout wrote:
XS modules are not really declared in any Perl scope, but XS glob |
From @cpansproutOn Thu Oct 27 13:00:50 2011, sprout wrote:
This also affects subroutines declared under ‘use v5.16’. How are This is much more of a mess than I’d hoped.... (I hope somebody is reading this and has some ideas.) |
From jpl@research.att.comOn 10/27/11 17:43, Father Chrysostomos via RT wrote:
The best should not be the enemy of the good. At minimum, there should |
From @cpansproutOn Fri Oct 28 07:40:43 2011, jpl@research.att.com wrote:
We can also add the :bsd_glob export that I suggested, but without
I’m still thinking about it. I think that the glob() magic should Now, should the same thing apply to require? I.e., should subs compiled -- Father Chrysostomos |
From @cpansproutOn Fri Oct 28 18:02:14 2011, sprout wrote:
Done with commit 5144542.
Done with commit f4cbf99.
I searched CPAN and did not find any non-core modules that use the magic However, this is still just making my brain go round in circles, so I -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'resolved' |
From @cpansproutOn Wed Oct 26 08:55:56 2011, tom christiansen wrote:
Some of that was already covered in perlfunc. But I’ve taken part of
-- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Wed Oct 26 08:55:56 2011, tom christiansen wrote:
Some of that was already covered in perlfunc. But I’ve taken part of
-- Father Chrysostomos |
From tchrist@perl.com
Good, thanks. --tom |
Migrated from rt.perl.org#96116 (status was 'resolved')
Searchable as RT96116$
The text was updated successfully, but these errors were encountered: