Re: Standard Libraries:

["GrayFace" <sergroj@...>]

Here's another function for my list:

-- compare strings case-insensitively
string.cmp(s1, s2)


And on to finding files:

KHMan wrote:
> So, in order to have common functionality, no platform is likely
> to get a perfect file system library.

I don't think so. In cases like this we can support features of each major 
platform, implementing them manually for other platforms. I only considered 
APIs of Windows and Unix (described by Sean Conner). I hope someone will 
also describe MacOS specifics.
In files searching time overhead of supporting features of both systems 
should be minimal because all extra stuff can be provided on demand. Only 
the code size can grow considerably.

Here's my proposal:


for f, stat in path.find(mask, filter) do

- 'mask' would be then split into directory path and filename mask. In 
Posix,
the mask (if it's different from "*") would be applied as an additional 
test.

- 'filter' should allow common file search needs:
1) Files only
2) Directories only (but without "." and "..")
3) List both files and directories
4) Maybe an option to ignore hidden files, maybe another one to ignore 
read-only or system files, etc.
In my project I only have the first two options, but for a common library 
the third should be supported as well. Dunno what's the best choice here.
I currently consider these meanings of the parameter:
1) "f" - files only
2) "d" - directories only (but without "." and "..")
3) any other value - list anything, even "..".  I don't know what to do with 
"." though. Does it have any practical value at all?


- 'f' is path to file, composed of directory path taken from 'mask' and file 
name from
search. IMO, typically it's the only needed thing, so it's returned 
separately as the first result.

- 'stat' is the userdata that contains current state of search. It should 
provide following properties:
1) 'FileName' - name of the file, without path
2) 'FilePath' - same as 'f' described above
3) 'Directory' - the part
4) All fields returned by windows FindFile. On Windows they would be taken 
from search struct. On Posix they would be taken from stat() call on demand.
5) 'Rewind' method that would call rewinddir() on Posix or would reinitiate 
search on Windows. Well, if rewinddir() has practical use :)


That's about it.
The "*.*" thing Sean Conner mentioned isn't a problem. "*" works well on 
Windows. It should be mentioned in help that "*.*" should be avoided. 
Another thing that shouldn't be used is "\". "/" is easier to write and 
AFAIK it's supported by most platforms.







----- Original Message ----- 
From: KHMan
To: Lua list
Sent: Friday, December 18, 2009 6:50 AM
Subject: Re: Standard Libraries:


Sean Conner wrote:
> [snip]
>   Under MS-DOS (and I assume, Windows), you have the following:
>
> FindFirstFile() - return first file in current working directory
> FindNextFile() - return the next matching file
>
>   FindFirstFile() only works for the current working directory (unlike
> Unix), it takes a simple file regex (a file glob) and some flags (include
> archive files, read-only files, system files, etc) and fills in a
> structure
> (the address of which is passed in first via another function) with the
> following information (for Unix, another all is needed to obtain this
> information):

Please don't assume. FindFirstFile() will take any valid paths.
The most convenient >=Win2K method is probably to use
FindFirstFileW() and utilize the extended path string format (to
exceed MAX_PATH-length strings) and add a UTF-16 translation layer
(if we want to enforce a consistent UTF-8 policy).

The other problem is that in Windows, you will get most of the
stat() information with the Find---File() calls. If we wish to
enforce POSIX-style functionality, calling again to get stat()
information all the time may not be everyone's cup of tea. For
apps that want maximum file system performance, perhaps they
should roll a custom library.

So, in order to have common functionality, no platform is likely
to get a perfect file system library.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia