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
File::Find always re-sorts directories last #14156
Comments
From @leonerdCreated by @leonerdThis is a bug report for perl from leonerd@leonerd.org.uk, ----------------------------------------------------------------- File::Find, even in depth-first mode, even with a preprocess function, will find({ wanted => sub { will yield the output: Considering tests... Specfically, even though I have sorted '10apidoc' before '50register.pl' it https://metacpan.org/source/SHAY/perl-5.20.1/ext/File-Find/lib/File/Find.pm#L766 and the later if(-d _)-guarded block involving a splice on this array. This bug therefore comes in two parts: 1) The documentation of File::Find nowhere makes mention of the fact it will 2) There is no control over this behaviour, and therefore no way for me to Perl Info
|
From @jkeenanOn Mon Oct 13 10:09:09 2014, leonerd@leonerd.org.uk wrote:
I suspect that the problem lies in this part of ext/File-Find/lib/File/Find.pm: ##### This code was added in 2003 in what is now commit 7bd3152 in response to RT #22195 (see attachment). That's as far as I'll be able to analyze this tonight. Thank you very much. |
From @jkeenanrt122968.7bd31527.diffcommit 7bd31527512b13192dec55ed4943599edc17b94a
Author: Jarkko Hietaniemi <jhi@iki.fi>
Date: Fri May 16 17:56:06 2003 +0000
Apply the supplied patch for [perl #22195]
"File::Find, sorted directory traversal order is inverted"
p4raw-id: //depot/perl@19531
diff --git a/lib/File/Find.pm b/lib/File/Find.pm
index c5f2a5a..fc09503 100644
--- a/lib/File/Find.pm
+++ b/lib/File/Find.pm
@@ -7,6 +7,12 @@ our $VERSION = '1.04';
require Exporter;
require Cwd;
+#
+# Modified to ensure sub-directory traversal order is not inverded by stack
+# push and pops. That is remains in the same order as in the directory file,
+# or user pre-processing (EG:sorted).
+#
+
=head1 NAME
File::Find - Traverse a directory tree.
@@ -855,6 +861,11 @@ sub _find_dir($$$) {
# This dir has subdirectories.
$subcount = $nlink - 2;
+ # HACK: insert directories at this position. so as to preserve
+ # the user pre-processed ordering of files.
+ # EG: directory traversal is in user sorted order, not at random.
+ my $stack_top = @Stack;
+
for my $FN (@filenames) {
next if $FN =~ $File::Find::skip_pattern;
if ($subcount > 0 || $no_nlink) {
@@ -866,7 +877,10 @@ sub _find_dir($$$) {
if (-d _) {
--$subcount;
$FN =~ s/\.dir\z// if $Is_VMS;
- push @Stack,[$CdLvl,$dir_name,$FN,$sub_nlink];
+ # HACK: replace push to preserve dir traversal order
+ #push @Stack,[$CdLvl,$dir_name,$FN,$sub_nlink];
+ splice @Stack, $stack_top, 0,
+ [$CdLvl,$dir_name,$FN,$sub_nlink];
}
else {
$name = $dir_pref . $FN; # $File::Find::name
|
The RT System itself - Status changed from 'new' to 'open' |
From @leonerdOn Mon, 13 Oct 2014 18:51:03 -0700
Well, not even. RT #22195 was a bug with the already-existing logic -- leonerd@leonerd.org.uk |
Migrated from rt.perl.org#122968 (status was 'open')
Searchable as RT122968$
The text was updated successfully, but these errors were encountered: