allFilesMatching:do:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

allFilesMatching:do:

SeanTAllen
Apparently I'm now abusing a new method. I'm investigating the best  
way to handle a couple tasks...

I have this:

/Users/Spooneybarger/test/
/Users/Spooneybarger/test/x/
/Users/Spooneybarger/test/x/ed.txt
/Users/Spooneybarger/test/ed.txt/
/Users/Spooneybarger/test/ed.txt/file


As I test, I wanted to find anything named ed.txt...

/Users/Spooneybarger/test/x/ed.txt
/Users/Spooneybarger/test/ed.txt/

so i did:

st> file allFilesMatching: '*ed.txt' do: [ :each | each name printNl ]
'/Users/Spooneybarger/test/ed.txt'
'/Users/Spooneybarger/test/x/ed.txt'

which i believe is the only way to get both as its trying to match  
against

x
x/ed.txt
ed.txt
ed.ext/file

problem

if i add

/Users/Spooneybarger/test/fred.txt

st> file allFilesMatching: '*ed.txt' do: [ :each | each name printNl ]
'/Users/Spooneybarger/test/ed.txt'
'/Users/Spooneybarger/test/fred.txt'
'/Users/Spooneybarger/test/x/ed.txt'

right so there is no way to use allFilesMatching to get every file  
named ed.txt like this.
not real intuitive...

st> file allFilesMatching: '*ed.txt' do: [ :each | each stripPath =  
'ed.txt' ifTrue: [ each name printNl ] ]
'/Users/Spooneybarger/test/ed.txt'
'/Users/Spooneybarger/test/x/ed.txt'

it would seem that the recursive nature of allFilesMatching pretty  
much demands that pattern is a full regular expression,
otherwise, I can't see a real use case for allFilesMatching:do: that  
isnt quite limited.

With a regex i could still do what it does right now

.*ed.txt

or what i thought it would do

.*/?ed.txt


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: allFilesMatching:do:

Paolo Bonzini-2

>  ( File name: '/top' ) all namesDo: [ :e | ( File stripPathFrom: e ) ]
>
> I think the more common use case is the latter.... Let me know what you
> think, I can either send over the patch as it exists now or I can change
> it so that allFilesMatching and companions work on names with the paths
> completely stripped off...

I agree that this is the common use case.  You can also change it to
prepend (?:^|/) to the regex; it's probably faster than stripping the path.

> If I expanded out to use stripPathFrom when selecting what to match, I
> would make sure to still return full relative path from filesMatching:

Of course.  The names passed to the block by #namesMatching:do: should
also not be affected.

> Sorry this was so long. Just trying to be complete.

No problem.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk