I would like to find files in Pharo like the UNIX find command: find . -iname "*.txt" -type f -printfind . \( -iname "*.txt" -o -iname "*.csv" \) -print find . -maxdepth 2 -name "example*" -type f -print find . -type f -atime -7 -size +2M -perm 644 -print |
Hernán,
We obviously don't have as many options as find, but this should get you started: Check the category 'enumerating' in AbstractFileReference, with methods like #childrenMatching: and #allChildrenMatching: Once you have a reference, you can use other meta data, see the 'accessing' protocol to further your query. HTH, Sven > On 18 Jun 2017, at 04:59, Hernán Morales Durand <[hidden email]> wrote: > > I would like to find files in Pharo like the UNIX find command: > > find . -iname "*.txt" -type f -print > > find . \( -iname "*.txt" -o -iname "*.csv" \) -print > > find . -maxdepth 2 -name "example*" -type f -print > > find . -type f -atime -7 -size +2M -perm 644 -print > > Do we have some package on top of FileSystem to make complex find searches? > > Hernán > |
In reply to this post by hernanmd
Why not just use OsProcess or OsSubprocess to run the unix commands (works on Mac OS and Linux)?
Sent from my iPhone > On Jun 17, 2017, at 19:59, Hernán Morales Durand <[hidden email]> wrote: > > I would like to find files in Pharo like the UNIX find command: > > find . -iname "*.txt" -type f -print > > find . \( -iname "*.txt" -o -iname "*.csv" \) -print > > find . -maxdepth 2 -name "example*" -type f -print > > find . -type f -atime -7 -size +2M -perm 644 -print > > Do we have some package on top of FileSystem to make complex find searches? > > Hernán > |
I know file system commands could be executed using the OS wrappers. 2017-06-18 3:59 GMT-03:00 john pfersich <[hidden email]>: Why not just use OsProcess or OsSubprocess to run the unix commands (works on Mac OS and Linux)? |
In reply to this post by Sven Van Caekenberghe-2
Thanks Sven, Just checking some brave soul out there with a cool "unpublished" package...2017-06-18 3:58 GMT-03:00 Sven Van Caekenberghe <[hidden email]>: Hernán, |
In reply to this post by hernanmd
I would love that too :).
Can you tell us what is missing from the file properties? On Sun, Jun 18, 2017 at 4:59 AM, Hernán Morales Durand <[hidden email]> wrote: > I would like to find files in Pharo like the UNIX find command: > > find . -iname "*.txt" -type f -print > > find . \( -iname "*.txt" -o -iname "*.csv" \) -print > > find . -maxdepth 2 -name "example*" -type f -print > > find . -type f -atime -7 -size +2M -perm 644 -print > > Do we have some package on top of FileSystem to make complex find searches? > > Hernán > |
In reply to this post by hernanmd
Hi Hernan,
On Sat, Jun 17, 2017 at 11:59:59PM -0300, Hern??n Morales Durand wrote: > I would like to find files in Pharo like the UNIX find command: > > find . -iname "*.txt" -type f -print > > find . \( -iname "*.txt" -o -iname "*.csv" \) -print > > find . -maxdepth 2 -name "example*" -type f -print > > find . -type f -atime -7 -size +2M -perm 644 -print > > Do we have some package on top of FileSystem to make complex find searches? You might also like to look at the FileSystemVisitor class and subclasses. Currently you can't strictly do a "-type f" test. The closest at the moment is "isDirectory" and "isDirectory not" (which is what #isFile is defined as). I've got some patches lined up which will allow you to test things like #isRegular (which matches "-type f"), #isSymlink, etc. But it will be a while before they become available as it involves a new VM plugin. Cheers, Alistair |
In reply to this post by Stephane Ducasse-3
I took the time to review FileSystemDirectoryEntry.
UNIX has 3 types of timestamps -The access time is the last time when the content was accessed. -The modification time is last time when the content was modified. -The change time is the last time when the metadata was modified. FileSystemDirectoryEntry>>crea This is wrong because there is no such thing as creation time in UNIX. I checked in Linux chmod'ing an empty file and #creationTime displays the chmod "change time". Then added content to the file echo prueba >> test1.txt And both "creation" and "modification" instance variables were updated. I couldn't find #accessTime method to get the last timestamp of last access. Cheers, Hernán 2017-06-18 10:43 GMT-03:00 Stephane Ducasse <[hidden email]>: I would love that too :). |
Hi Hernan,
On Mon, Jun 19, 2017 at 09:23:35PM -0300, Hern??n Morales Durand wrote: > I took the time to review FileSystemDirectoryEntry. > > UNIX has 3 types of timestamps > > -The access time is the last time when the content was accessed. > -The modification time is last time when the content was modified. > -The change time is the last time when the metadata was modified. > > FileSystemDirectoryEntry>>creationTime > This is wrong because there is no such thing as creation time in UNIX. Several linux file systems do support creation time, called birth time, but my understanding is that there is no standard way to retrieve the birth time commonly available and cross platform. > I checked in Linux chmod'ing an empty file and #creationTime displays the chmod > "change time". > Then added content to the file > > echo prueba >> test1.txt > > And both "creation" and "modification" instance variables were updated. > > I couldn't find #accessTime method to get the last timestamp of last access. Linux kernel 4.11 introduced statx(), which adds creation time, but I don't know if it will be adopted by BSD or MacOS. The patches I mentioned earlier and plan for Pharo 7 add support for all 4 timestamps (creation, change, modification, access). Which fields get populated depends on the platform. There's a #hasCreationTime flag which allows you to distinguish between the real creation time and the change time. Cheers, Alistair |
2017-06-20 3:14 GMT-03:00 Alistair Grant <[hidden email]>: Hi Hernan, Thanks for the update, I checked and creation time seems not required by POSIX. > I checked in Linux chmod'ing an empty file and #creationTime displays the chmod Maybe #creationTime should answer nil or raise an exception if not supported by underlying file system. It would be nice to has full support for tags. Cheers, Hernán Cheers, |
On Tue, Jun 20, 2017 at 04:22:31AM -0300, Hern??n Morales Durand wrote:
> > > 2017-06-20 3:14 GMT-03:00 Alistair Grant <[hidden email]>: > > Hi Hernan, > > On Mon, Jun 19, 2017 at 09:23:35PM -0300, Hern??n Morales Durand wrote: > > I took the time to review FileSystemDirectoryEntry. > > > > UNIX has 3 types of timestamps > > > > -The access time is the last time when the content was accessed. > > -The modification time is last time when the content was modified. > > -The change time is the last time when the metadata was modified. > > > > FileSystemDirectoryEntry>>creationTime > > This is wrong because there is no such thing as creation time in UNIX. > > Several linux file systems do support creation time, called birth time, > but my understanding is that there is no standard way to retrieve the > birth time commonly available and cross platform. > > > > Thanks for the update, I checked and creation time seems not required by POSIX. > > > > I checked in Linux chmod'ing an empty file and #creationTime displays the > chmod > > "change time". > > Then added content to the file > > > > echo prueba >> test1.txt > > > > And both "creation" and "modification" instance variables were updated. > > > > I couldn't find #accessTime method to get the last timestamp of last > access. > > Linux kernel 4.11 introduced statx(), which adds creation time, but I > don't know if it will be adopted by BSD or MacOS. > > The patches I mentioned earlier and plan for Pharo 7 add support for all > 4 timestamps (creation, change, modification, access). Which fields get > populated depends on the platform. There's a #hasCreationTime flag > which allows you to distinguish between the real creation time and the > change time. > > > > Maybe #creationTime should answer nil or raise an exception if not supported by > underlying file system. > > It would be nice to has full support for tags. If this were new behaviour I would raise an exception, but currently my version of #creationTime continues to return the change time for backward compatibility (it also seems to be common behaviour on Posix systems). The #hasCreationTime flag is there for applications that want to be specific in their behaviour. I'm open to changing this if there is sufficient support or a good enough argument. Cheers, Alistair |
Free forum by Nabble | Edit this page |