Hello Alan
Alan_C wrote:
>
> On Tuesday 25 July 2006 15:56, Rob Dixon wrote:
>
>>Nishi Bhonsle wrote:
>>
>> > I got the last soln, ie to use File::Basename module. Please ignore the
>> > last thread.
>> >
>> > I am still interested to know why Rob's soln doesnt work for me?
>>
>>So was I, and it's because I made a mistake. Because the values returned by
>>readdir don't include a full path, the file test only works if the
>>directory being listed is the current one. Try this version instead with my
>>humble apologies.
>
> [ snip ]
>
> I'd experimented *before* I saw this post.
>
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> my @dir = do {
> # opendir my $dh, 'C:\build\Sample\NewDir' or die $!;
> opendir my $dh, '/home/al/temp4' or die $!;
> # grep -f, readdir $dh;
> readdir $dh;
> };
>
> print "$_\n" foreach @dir;
> # print @dir, "\n";
At least use
print "@dir\n"
or the filenames will all be concatenated together without being able to tell
where they start and end.
> That works on Linux (not matters the current dir, I was in /home/al when I ran
> it) which leads me to guess that something be wrong with the grep line.
Exactly, and I fixed it in the part of my post that you snipped! The
requirements of the OP were that directories be excluded from the list and that
only the filenames be present without their paths. readdir() returns just the
filenames, but the error in my code was that without a full path the -f operator
will look for the file in the current directory to decide whether it is a plain
file or not instead of in its proper place. Files were being filtered out of the
list because they didn't exist at all (in the current directory), not because
they were the unwanted directories. Your code succeeds because you have removed
the grep() but now it no longer fulfils the requirement because all the
directories are in there as well.
> Also, on Windows, doesn't it need to be either C:\\build\\Sample\\NewDir
>
> or
>
> C:/build/Sample/NewDir
>
> In my past Win days, I used to do it like that latter.
>
> I'm guess maybe it's must do that when it's double quotes. I see you used
> single quotes.
Exactly. Perl won't try to interpolate the contents of singly-quoted strings and
lone backslashes are fine, but with two exceptions: the escape character itself
can be escaped to 'protect' it, so a double backslash in the source will produce
a single one in the resulting string, just the same as within double-quotes; and
the string delimiter can also be escaped to allow embedded single quotes, which
means that a path with a trailing backslash needs two backslashes there to avoid
losing the closing quote. So:
'C:\WINDOWS'
but
'C:\WINDOWS\\'
and hence a lone backslash always needs doubling, whether in single or double
quotes:
'\\' or "\\"
Perl, of course, is quite happy whether you use forward or backward slashes as
the path separator, and certainly forward slashes cause less hassle. The problem
comes in Windows if you need to interact with external software, which will
expect and supply backslashes in all its paths. You then have to choose between
using backslashes throughout or translating to and from the friendlier forward
slash before the data is allowed into or out of the Perl environment.
HTH,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
