Re: [PATCH] File access library for lua

[Pavel Roskin <proski@gnu.org>]

On Wed, 2009-06-24 at 12:41 +0800, Bean wrote:

> Oh, fixed typos now. As for "Windows Vista bootmgr"  and "Windows
> NT/2000/XP loader", I just copy them from 10_windows.in, I guess there
> is a reason for it there.

I don't think so.

> > inird should be initrd.  Please add check for the Fedora style names for
> > initrd, namely "initrd-KVER.img".  Or maybe you just missed ".img" in
> > the second check?
> >
> 
> Add the test for initrd-KVER.img. Is there any distro that uses
> initrd-KVER ? if not, I can just remove the second test.

Actually, I think SUSE uses initrd-KVER (no SUSE around, but Google
seems to confirm it), Fedora uses initrd-KVER.img and Debian uses
initrd.img-KVER, so we need to support all three.

> >> Extend the function of grub.file_exist to allow testing multiple names
> >> at the same time, this simplify osdetect.lua.
> >
> > The change to grub_lua_file_exist() is dubious.  It's not clear why the
> > requirement is that all files exist.  Maybe I don't know the style of
> > lua, but I think it's wrong to hardcode the AND logic just because one
> > script would benefit from it.
> 
> As lua can detect the number of parameter quite easily, I just think
> it'd be a waste not to utilize it. If you always call it with one
> parameter, then it's equivalent to the previous file_exist. It's just
> a little more code in c, but it can reduce the number of calls between
> c and lua.

I think it's not nice to add bells and whistles to a basic function
checking existence of a file.  Imagine if libc did is, and stat() would
take a list of files.

> > If we consider e.g. the wildcard expansion in make, it will return a
> > non-empty value if any file exists, i.e. the OR logic is used.
> >
> 
> We can add a new function that uses OR logic instead of AND, for
> example, grub.file_exist_any, and the current AND version can be
> called grub.file_exist_all.

Can we implement them in lua?  I think it would be better than to
implement them in C.

-- 
Regards,
Pavel Roskin