# Removing directory references '.' and '..' from the listing
my $rmdir = shift (@file_list);
my $rmdir2 = shift (@file_list);
Are you sure this works? I just tested and on my system . and .. are returned somewhere in the middle of the list at seemingly random positions, which means your code wouldn't be portable to my system and probably many Linux systems in general. Much better (File::Spec is a core module):
use File::Spec::Functions qw/no_upwards/;
...
my @file_list = no_upwards readdir($dirhandle);
Or even better (one difference being that @file_list will contain Path::Class objects that include the directory):
use Path::Class qw/dir file/;
my @file_list = dir($dirname)->children;
| [reply] [d/l] [select] |
Yeah, I appreciate that the removal of . and .. may not be portable to your system, but you could just add a loop to iterate over the array in the subroutine before returning the list, finding both, and deleting the elements. Wouldn't be too hard - I write mostly on Windows where I work which is why I just shift them off the start of the array.
| [reply] |
Yeah, I appreciate that the removal of . and .. may not be portable to your system - I write mostly on Windows where I work which is why I just shift them off the start of the array.
Are you sure that Windows guarantees that the first two results are "." and ".."? I would not bet a cent on that. If it works, it does so by pure luck.
If you are sure, post a link to the relevant documentation from Microsoft where Microsoft guarantees that the first two results are "." and ".." (in any order), under all circumstances.
I failed to find such a statement in FindFirstFile(), FindNextFile(), and FindFirstFileEx(). Quite the opposite is true for these three functions. Microsoft clearly states that these functions return unsorted data. So if your "solution" ever worked, then only by pure luck. You are writing and propagating bad code.
but you could just add a loop to iterate over the array in the subroutine before returning the list, finding both, and deleting the elements. Wouldn't be too hard
Well, yes, but you would not loop and remove manually. grep can do that within a single line of code:
use strict;
use warnings;
use autodie qw( :all);
opendir my $d,'/where/ever';
my @content=grep { !/^\.{1,2}$/ } readdir $d;
closedir $d;
Of course, you don't need a regexp, you could also use two string compares:
use strict;
use warnings;
use autodie qw( :all);
opendir my $d,'/where/ever';
my @content=grep { ($_ ne '.') and ($_ ne '..') } readdir $d;
closedir $d;
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] [d/l] [select] |
my @sourcefiles = &get_files($source_directory);
You don't need the ampersand in Perl 5 to call a function. Quite the opposite is true: You should avoid the ampersand in Perl 5 when calling functions, as it can introduce nasty, hard-to-debug errors. The ampersand was needed in Perl 4, but that was decades ago.
Read more at Re^2: Merge log files causing Out of Memory (just a note on ampersand).
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] [d/l] |
"Removing directory references '.' and '..' from the listing"
BTW: use Path::Tiny; @paths = path($dir)->children;
"Returns a list of Path::Tiny objects for all files and directories within a directory. Excludes "." and ".." automatically."
Automatically sounds always good, right?
See Path::Tiny
Regards, Karl
«The Crux of the Biscuit is the Apostrophe»
perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help
| [reply] [d/l] [select] |