Re: How to use sub/method 'dir'
On Mon, Nov 26, 2018 at 6:26 PM Trey Harris wrote:
>
>
>
> On Mon, Nov 26, 2018 at 04:56 Fernando Santagata
> wrote:
>>
>> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert wrote:
>>>
>>> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
>>> is that it is passed strings.
>>
>>
>> Thank you!
>> I could have inferred that from the declaration of the 'test' argument here
>> https://docs.perl6.org/routine/dir where the test is being done against '.'
>> and '..', two strings:
>>
>>> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
>>> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>
>>
>> but I guess it's a long stretch.
>> Maybe a note in the docs would be useful to others.
>>
>>>
>>> I would argue that inside of the `test` that `$*CWD` should be set to
>>> `a`, and/or the values should be IO objects.
>>> (They are going to become IO objects eventually anyway.)
>>
>>
>> Indeed I think that even tough one can do any kind of test on the
>> directory's content, the most usual ones are those using the file test
>> operators, so defaulting to IO is probably more useful than defaulting to
>> Str.
>
>
> I'm not sure that's true. I think it's a question of following the Principle
> of Least Surprise.
Exactly, the way it works right now is surprising (to new Perl 6 programmers).
It even took me a few seconds to realize what the problem was, and
I've been learning Perl 6 for about a decade.
> The only substantive difference between `my $i = "foobar".IO` and `my $s =
> "foobar"` besides needing to stick the `.IO` in when you want to do IO-y
> things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
> instantiation. But `dir` always returns paths that stringify _relative to
> `$*CWD` at the time of the `dir` call._ Notice the difference between
> `$i.gist` (which, if evaluated, will not consistently re-create the original
> object) and `$i.perl` (which will):
>
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
> > chdir "/tmp"
> "/tmp".IO
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
>
> The string, OTOH, is also relative to the `$*CWD` at the time of the `dir()`
> call, but if you call `.IO` on it after changing directories, the path object
> is interpreted relative to the new directory. This is unsurprising; what
> _would be_ surprising is if a string changed as a result of external program
> state.
I was only talking about the object within the `:test` argument of the
`dir` call.
The resulting sequence wouldn't change at all.
> Large-scale file-munging operations have always been squarely in Perl's
> wheelhouse, and doing fancy operations with complex subtrees (such as
> syncing, normalizing, archiving, collating, etc.) are common.
Precisely why I suggested changing it.
The way it works now is harder to use than it could be.
> The string doesn't offer as much in the way of features, but I think it
> behaves much more predictably when doing these sorts of operations. If you
> `chdir $dest` after the `dir` but before doing your munging, then you must
> remember to prepend the old working directory if you need to access the
> original file (i.e., `$src = $*CWD; for @files -> $f { $src.add($f) ... }`),
> while the new files would just be `$f`. If you don't change directories, then
> you must say `$dest.add($f)` to refer to the new files, while the old file is
> just `$f`. But in either case, it's unsurprising and predictable.
Actually Str behaves less predictably than an IO object for the `test` argument.
If you want to compare it stringwise, do so and it works:
my $dir = IO::Path( 'b', :CWD('a'.IO) );
say $dir eq 'b'; # True
If you want to see if it is a directory, just ask it:
say $dir.d; # True
`.gist` doesn't stringify an object, it returns enough information for
a human to be able to figure out what the object is.
When you do stringy operations on an IO::Path object (or any object),
it calls the `.Str` method not `.gist`.
The only things which implicitly call `.gist` is `say` and `note`.
Now what I proposed was having the CWD set to the directory being
examined inside of `test`, which is a different `CWD` than the result
of the `dir` call.
> say dir('a'):test( {temp $*CWD = 'a'.IO; .IO.d && .IO ~~ none(<. ..>)} )
("a/b".IO)
> say dir('a', :test( {temp $*CWD = 'a'.IO; .IO.d && .IO ~~
none(<. ..>)} ))».CWD
(/home/brad)
Note that `none(<. ..>)` still worked just fine against such an
object. (the default `:test` argument)
I also didn't say they had to be IO objects, just that the CWD should
be inside of the directory of the dir being tested within the `:test`
argument.
>
> If, OTOH, these were IO objects, if you changed directories, you'd think from
> the gist that you'd do the same. And if you don't
Re: How to use sub/method 'dir'
I can only argue that since the function's name 'dir' reminds a shell level
command, and 'ls a' and 'dir a' work in a certain way, I was expecting that
the function 'dir' worked in the same way, following the Principle of Least
Surprise :-)
On Tue, Nov 27, 2018 at 1:37 AM Trey Harris wrote:
>
> On Mon, Nov 26, 2018 at 19:26 Trey Harris wrote:
>
>>
>>
>> On Mon, Nov 26, 2018 at 04:56 Fernando Santagata <
>> nando.santag...@gmail.com> wrote:
>>
>>> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert wrote:
>>>
The reason `dir('a', test => { .IO.d })` doesn't work like you expect
is that it is passed strings.
>>>
>>> Thank you!
>>> I could have inferred that from the declaration of the 'test' argument
>>> here https://docs.perl6.org/routine/dir where the test is being done
>>> against '.' and '..', two strings:
>>>
>>> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>>
>>> but I guess it's a long stretch.
>>> Maybe a note in the docs would be useful to others.
>>>
>>>
I would argue that inside of the `test` that `$*CWD` should be set to
`a`, and/or the values should be IO objects.
(They are going to become IO objects eventually anyway.)
>>>
>>> Indeed I think that even tough one can do any kind of test on the
>>> directory's content, the most usual ones are those using the file test
>>> operators, so defaulting to IO is probably more useful than defaulting to
>>> Str.
>>>
>>
>> I'm not sure that's true. I think it's a question of following the
>> Principle of Least Surprise.
>>
>> The only substantive difference between `my $i = "foobar".IO` and `my $s
>> = "foobar"` besides needing to stick the `.IO` in when you want to do IO-y
>> things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
>> instantiation. But `dir` always returns paths that stringify _relative to
>> `$*CWD` at the time of the `dir` call._ Notice the difference between
>> `$i.gist` (which, if evaluated, will not consistently re-create the
>> original object) and `$i.perl` (which will):
>>
>> > $f.gist
>> "foobar".IO
>> > $i.perl
>> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
>> :CWD("/home/trey/perl6/rakudo-star"))
>> > chdir "/tmp"
>> "/tmp".IO
>> > $f.gist
>> "foobar".IO
>> > $i.perl
>> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
>> :CWD("/home/trey/perl6/rakudo-star"))
>>
>
> Oops, ignore the changing variable names here; I was copying lines from a
> REPL session where I'd used `$f`, and then I changed `$f` to match `$i` in
> the text before it and didn't fully complete the renaming. It's just a
> single variable.
>
>
>> The string, OTOH, is also relative to the `$*CWD` at the time of the
>> `dir()` call, but if you call `.IO` on it after changing directories, the
>> path object is interpreted relative to the new directory. This is
>> unsurprising; what _would be_ surprising is if a string changed as a result
>> of external program state.
>>
>> Large-scale file-munging operations have always been squarely in Perl's
>> wheelhouse, and doing fancy operations with complex subtrees (such as
>> syncing, normalizing, archiving, collating, etc.) are common.
>>
>> The string doesn't offer as much in the way of features, but I think it
>> behaves much more predictably when doing these sorts of operations. If you
>> `chdir $dest` after the `dir` but before doing your munging, then you must
>> remember to prepend the old working directory if you need to access the
>> original file (i.e., `$src = $*CWD; for @files -> $f { $src.add($f) ...
>> }`), while the new files would just be `$f`. If you don't change
>> directories, then you must say `$dest.add($f)` to refer to the new files,
>> while the old file is just `$f`. But in either case, it's unsurprising and
>> predictable.
>>
>> If, OTOH, these were IO objects, if you changed directories, you'd think
>> from the gist that you'd do the same. And if you don't change directories,
>> you _could_ do the same (`$dest = "/destdir".IO; $dest.add($f)` works using
>> the gist). But if you do change directories, it's now the _old file_ that's
>> just `$f`; the new file becomes `$*CWD.add($f)`. This feels quite strange
>> and surprising to me.
>>
>> The very slight keystroke-saving convenience of not requiring the outputs
>> of `dir` to be followed with `.IO` before doing IO operations on individual
>> IO objects in-place doesn't seem worth the strangeness of their behavior
>> when doing bulk operations on them from a distance.
>>
>> (I was thinking through possible have-your-cake-and-eat-it-too solutions
>> like `.gist` and `.path` of IO objects created from strings changing their
>> string representation if and only if you changed working directories and
>> these all seem to just Waterbed Complexify the problem elsewhere. Perhaps
>> someone can come up with an everybody-wins solution—but except for moving
>> the filetest operations into `Cool`
Re: How to use sub/method 'dir'
On Mon, Nov 26, 2018 at 19:26 Trey Harris wrote:
>
>
> On Mon, Nov 26, 2018 at 04:56 Fernando Santagata <
> nando.santag...@gmail.com> wrote:
>
>> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert wrote:
>>
>>> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
>>> is that it is passed strings.
>>>
>>
>> Thank you!
>> I could have inferred that from the declaration of the 'test' argument
>> here https://docs.perl6.org/routine/dir where the test is being done
>> against '.' and '..', two strings:
>>
>> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
>>> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>>
>>
>> but I guess it's a long stretch.
>> Maybe a note in the docs would be useful to others.
>>
>>
>>> I would argue that inside of the `test` that `$*CWD` should be set to
>>> `a`, and/or the values should be IO objects.
>>> (They are going to become IO objects eventually anyway.)
>>>
>>
>> Indeed I think that even tough one can do any kind of test on the
>> directory's content, the most usual ones are those using the file test
>> operators, so defaulting to IO is probably more useful than defaulting to
>> Str.
>>
>
> I'm not sure that's true. I think it's a question of following the
> Principle of Least Surprise.
>
> The only substantive difference between `my $i = "foobar".IO` and `my $s =
> "foobar"` besides needing to stick the `.IO` in when you want to do IO-y
> things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
> instantiation. But `dir` always returns paths that stringify _relative to
> `$*CWD` at the time of the `dir` call._ Notice the difference between
> `$i.gist` (which, if evaluated, will not consistently re-create the
> original object) and `$i.perl` (which will):
>
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
> > chdir "/tmp"
> "/tmp".IO
> > $f.gist
> "foobar".IO
> > $i.perl
> IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
> :CWD("/home/trey/perl6/rakudo-star"))
>
Oops, ignore the changing variable names here; I was copying lines from a
REPL session where I'd used `$f`, and then I changed `$f` to match `$i` in
the text before it and didn't fully complete the renaming. It's just a
single variable.
> The string, OTOH, is also relative to the `$*CWD` at the time of the
> `dir()` call, but if you call `.IO` on it after changing directories, the
> path object is interpreted relative to the new directory. This is
> unsurprising; what _would be_ surprising is if a string changed as a result
> of external program state.
>
> Large-scale file-munging operations have always been squarely in Perl's
> wheelhouse, and doing fancy operations with complex subtrees (such as
> syncing, normalizing, archiving, collating, etc.) are common.
>
> The string doesn't offer as much in the way of features, but I think it
> behaves much more predictably when doing these sorts of operations. If you
> `chdir $dest` after the `dir` but before doing your munging, then you must
> remember to prepend the old working directory if you need to access the
> original file (i.e., `$src = $*CWD; for @files -> $f { $src.add($f) ...
> }`), while the new files would just be `$f`. If you don't change
> directories, then you must say `$dest.add($f)` to refer to the new files,
> while the old file is just `$f`. But in either case, it's unsurprising and
> predictable.
>
> If, OTOH, these were IO objects, if you changed directories, you'd think
> from the gist that you'd do the same. And if you don't change directories,
> you _could_ do the same (`$dest = "/destdir".IO; $dest.add($f)` works using
> the gist). But if you do change directories, it's now the _old file_ that's
> just `$f`; the new file becomes `$*CWD.add($f)`. This feels quite strange
> and surprising to me.
>
> The very slight keystroke-saving convenience of not requiring the outputs
> of `dir` to be followed with `.IO` before doing IO operations on individual
> IO objects in-place doesn't seem worth the strangeness of their behavior
> when doing bulk operations on them from a distance.
>
> (I was thinking through possible have-your-cake-and-eat-it-too solutions
> like `.gist` and `.path` of IO objects created from strings changing their
> string representation if and only if you changed working directories and
> these all seem to just Waterbed Complexify the problem elsewhere. Perhaps
> someone can come up with an everybody-wins solution—but except for moving
> the filetest operations into `Cool` so they work like in Perl 5, a ship
> that's already sailed, I can't think of one.)
>
Re: How to use sub/method 'dir'
On Mon, Nov 26, 2018 at 04:56 Fernando Santagata
wrote:
> On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert wrote:
>
>> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
>> is that it is passed strings.
>>
>
> Thank you!
> I could have inferred that from the declaration of the 'test' argument
> here https://docs.perl6.org/routine/dir where the test is being done
> against '.' and '..', two strings:
>
> subdir(Cool $path = '.', Mu :$test = none('.', '..'))
>> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>>
>
> but I guess it's a long stretch.
> Maybe a note in the docs would be useful to others.
>
>
>> I would argue that inside of the `test` that `$*CWD` should be set to
>> `a`, and/or the values should be IO objects.
>> (They are going to become IO objects eventually anyway.)
>>
>
> Indeed I think that even tough one can do any kind of test on the
> directory's content, the most usual ones are those using the file test
> operators, so defaulting to IO is probably more useful than defaulting to
> Str.
>
I'm not sure that's true. I think it's a question of following the
Principle of Least Surprise.
The only substantive difference between `my $i = "foobar".IO` and `my $s =
"foobar"` besides needing to stick the `.IO` in when you want to do IO-y
things with `$s` is that `$i` retains the knowledge of $*CWD at the time of
instantiation. But `dir` always returns paths that stringify _relative to
`$*CWD` at the time of the `dir` call._ Notice the difference between
`$i.gist` (which, if evaluated, will not consistently re-create the
original object) and `$i.perl` (which will):
> $f.gist
"foobar".IO
> $i.perl
IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
:CWD("/home/trey/perl6/rakudo-star"))
> chdir "/tmp"
"/tmp".IO
> $f.gist
"foobar".IO
> $i.perl
IO::Path.new("foobar", :SPEC(IO::Spec::Unix),
:CWD("/home/trey/perl6/rakudo-star"))
The string, OTOH, is also relative to the `$*CWD` at the time of the
`dir()` call, but if you call `.IO` on it after changing directories, the
path object is interpreted relative to the new directory. This is
unsurprising; what _would be_ surprising is if a string changed as a result
of external program state.
Large-scale file-munging operations have always been squarely in Perl's
wheelhouse, and doing fancy operations with complex subtrees (such as
syncing, normalizing, archiving, collating, etc.) are common.
The string doesn't offer as much in the way of features, but I think it
behaves much more predictably when doing these sorts of operations. If you
`chdir $dest` after the `dir` but before doing your munging, then you must
remember to prepend the old working directory if you need to access the
original file (i.e., `$src = $*CWD; for @files -> $f { $src.add($f) ...
}`), while the new files would just be `$f`. If you don't change
directories, then you must say `$dest.add($f)` to refer to the new files,
while the old file is just `$f`. But in either case, it's unsurprising and
predictable.
If, OTOH, these were IO objects, if you changed directories, you'd think
from the gist that you'd do the same. And if you don't change directories,
you _could_ do the same (`$dest = "/destdir".IO; $dest.add($f)` works using
the gist). But if you do change directories, it's now the _old file_ that's
just `$f`; the new file becomes `$*CWD.add($f)`. This feels quite strange
and surprising to me.
The very slight keystroke-saving convenience of not requiring the outputs
of `dir` to be followed with `.IO` before doing IO operations on individual
IO objects in-place doesn't seem worth the strangeness of their behavior
when doing bulk operations on them from a distance.
(I was thinking through possible have-your-cake-and-eat-it-too solutions
like `.gist` and `.path` of IO objects created from strings changing their
string representation if and only if you changed working directories and
these all seem to just Waterbed Complexify the problem elsewhere. Perhaps
someone can come up with an everybody-wins solution—but except for moving
the filetest operations into `Cool` so they work like in Perl 5, a ship
that's already sailed, I can't think of one.)
Re: How to use sub/method 'dir'
On Sun, Nov 25, 2018 at 5:34 PM Brad Gilbert wrote:
> The reason `dir('a', test => { .IO.d })` doesn't work like you expect
> is that it is passed strings.
>
Thank you!
I could have inferred that from the declaration of the 'test' argument here
https://docs.perl6.org/routine/dir where the test is being done against '.'
and '..', two strings:
subdir(Cool $path = '.', Mu :$test = none('.', '..'))
> method dir(IO::Path:D: Mu :$test = none('.', '..'))
>
but I guess it's a long stretch.
Maybe a note in the docs would be useful to others.
> I would argue that inside of the `test` that `$*CWD` should be set to
> `a`, and/or the values should be IO objects.
> (They are going to become IO objects eventually anyway.)
>
Indeed I think that even tough one can do any kind of test on the
directory's content, the most usual ones are those using the file test
operators, so defaulting to IO is probably more useful than defaulting to
Str.
--
Fernando Santagata
Re: How to use sub/method 'dir'
The reason `dir('a', test => { .IO.d })` doesn't work like you expect
is that it is passed strings.
> dir('a', test => {.say});
.
c
b
..
("a/.".IO "a/c".IO "a/b".IO "a/..".IO)
So `.IO.d` is looking to see if the CWD directory had a directory of
that name, not the `a` directory.
To get it to work append the `a`
> dir('a', test => { "a/$_".IO.d })
("a/.".IO "a/b".IO "a/..".IO)
---
I would argue that inside of the `test` that `$*CWD` should be set to
`a`, and/or the values should be IO objects.
(They are going to become IO objects eventually anyway.)
This would make it so your code would just work.
sub dir ( $path, : ){
my @paths = ::dir($path);
indir $path, { # set $*CWD
my @results = @paths.grep: {
test( $_.IO ) # use IO object, not Str
}
}
@results
}
On Sat, Nov 24, 2018 at 3:19 PM Fernando Santagata
wrote:
>
> Hello,
>
> I think that I don't understand how the 'test' argument of 'dir' works.
> I have a directory 'a', which contains a subdirectory 'b' and a file 'c'; I
> want to select only the subdirectories of 'a'.
>
> Using the REPL I tried to ask the content of the directory 'a':
>
> > my @dirs = dir('a')
> ["a/c".IO "a/b".IO]
> > my @dirs = dir('a', test => { .IO.d })
> ["a/.".IO "a/..".IO]
> Why omitting the test the code returns the right list, while adding the test
> it returns just '.' and '..'?
>
> If I do the same thing for the top level directory '.' the behavior is
> different:
>
> > my @dirs = dir('.', test => { .IO.d })
> [".".IO "a".IO "..".IO]
>
> Now I can see the directory 'a'.
> If I descend a level, doing a 'cd a', the behavior is consistent with what I
> see at the previous level.
> I'm confused.
>
> I'm using version 2018.10.
>
> --
> Fernando Santagata
Re: How to use sub/method 'dir'
To further clarify, what I did to prepare this test is:
mkdir -p test/a/b
cd test
echo > a/c
On Sun, Nov 25, 2018 at 11:11 AM Fernando Santagata <
nando.santag...@gmail.com> wrote:
> Here's output of 'a/b'.IO.d from the REPL:
>
> > 'a/b'.IO.d
> True
>
> On Sun, Nov 25, 2018 at 1:52 AM Timo Paulssen wrote:
>
>> The dir method gives you entries in the directory you pass. If you don't
>> pass a test it'll use the default test which is none(".", ".."), i.e.
>> "anything except . and ..".
>>
>> I'm not sure why using { .IO.d } as the test would not give you b,
>> though. Can you check what "a/b".IO.d outputs? Maybe that can give us a
>> clue.
>>
>> HTH
>> - Timo
>> On 24/11/2018 22:18, Fernando Santagata wrote:
>>
>> Hello,
>>
>> I think that I don't understand how the 'test' argument of 'dir' works.
>> I have a directory 'a', which contains a subdirectory 'b' and a file 'c';
>> I want to select only the subdirectories of 'a'.
>>
>> Using the REPL I tried to ask the content of the directory 'a':
>>
>> > my @dirs = dir('a')
>> ["a/c".IO "a/b".IO]
>> > my @dirs = dir('a', test => { .IO.d })
>> ["a/.".IO "a/..".IO]
>> Why omitting the test the code returns the right list, while adding the
>> test it returns just '.' and '..'?
>>
>> If I do the same thing for the top level directory '.' the behavior is
>> different:
>>
>> > my @dirs = dir('.', test => { .IO.d })
>> [".".IO "a".IO "..".IO]
>>
>> Now I can see the directory 'a'.
>> If I descend a level, doing a 'cd a', the behavior is consistent with
>> what I see at the previous level.
>> I'm confused.
>>
>> I'm using version 2018.10.
>>
>> --
>> Fernando Santagata
>>
>>
>
> --
> Fernando Santagata
>
--
Fernando Santagata
Re: How to use sub/method 'dir'
Here's output of 'a/b'.IO.d from the REPL:
> 'a/b'.IO.d
True
On Sun, Nov 25, 2018 at 1:52 AM Timo Paulssen wrote:
> The dir method gives you entries in the directory you pass. If you don't
> pass a test it'll use the default test which is none(".", ".."), i.e.
> "anything except . and ..".
>
> I'm not sure why using { .IO.d } as the test would not give you b, though.
> Can you check what "a/b".IO.d outputs? Maybe that can give us a clue.
>
> HTH
> - Timo
> On 24/11/2018 22:18, Fernando Santagata wrote:
>
> Hello,
>
> I think that I don't understand how the 'test' argument of 'dir' works.
> I have a directory 'a', which contains a subdirectory 'b' and a file 'c';
> I want to select only the subdirectories of 'a'.
>
> Using the REPL I tried to ask the content of the directory 'a':
>
> > my @dirs = dir('a')
> ["a/c".IO "a/b".IO]
> > my @dirs = dir('a', test => { .IO.d })
> ["a/.".IO "a/..".IO]
> Why omitting the test the code returns the right list, while adding the
> test it returns just '.' and '..'?
>
> If I do the same thing for the top level directory '.' the behavior is
> different:
>
> > my @dirs = dir('.', test => { .IO.d })
> [".".IO "a".IO "..".IO]
>
> Now I can see the directory 'a'.
> If I descend a level, doing a 'cd a', the behavior is consistent with what
> I see at the previous level.
> I'm confused.
>
> I'm using version 2018.10.
>
> --
> Fernando Santagata
>
>
--
Fernando Santagata
Re: How to use sub/method 'dir'
The dir method gives you entries in the directory you pass. If you don't
pass a test it'll use the default test which is none(".", ".."), i.e.
"anything except . and ..".
I'm not sure why using { .IO.d } as the test would not give you b,
though. Can you check what "a/b".IO.d outputs? Maybe that can give us a
clue.
HTH
- Timo
On 24/11/2018 22:18, Fernando Santagata wrote:
> Hello,
>
> I think that I don't understand how the 'test' argument of 'dir' works.
> I have a directory 'a', which contains a subdirectory 'b' and a file
> 'c'; I want to select only the subdirectories of 'a'.
>
> Using the REPL I tried to ask the content of the directory 'a':
>
> > my @dirs = dir('a')
> ["a/c".IO "a/b".IO]
> > my @dirs = dir('a', test => { .IO.d })
> ["a/.".IO "a/..".IO]
> Why omitting the test the code returns the right list, while adding
> the test it returns just '.' and '..'?
>
> If I do the same thing for the top level directory '.' the behavior is
> different:
>
> > my @dirs = dir('.', test => { .IO.d })
> [".".IO "a".IO "..".IO]
>
> Now I can see the directory 'a'.
> If I descend a level, doing a 'cd a', the behavior is consistent with
> what I see at the previous level.
> I'm confused.
>
> I'm using version 2018.10.
>
> --
> Fernando Santagata
