Re: [ANN] Lua For Windows v5.1.3.3 Public Alpha2 released

["Andrew Wilson" <agrwagrw@...>]

The goal of a batteries included, no effort installation shouldn't change, but allowing for non-administrator installation without file associations seems quite reasonable given emphasis on letting people try out Lua with minimal effort. If install is happening on a non-administrator privileged account, then don't set file associations and just set path, lua_path & lua_cpath for user environment only. Add note in readme saying to get file associations need to install using an Administrator privileged account. These technicalities are Windows issues and shouldn't stop a batteiers included easy installer for Lua on Windows. 

Andrew

On Mon, May 19, 2008 at 12:15 PM, RJP Computing <rjpcomputing@gmail.com> wrote:

On Mon, May 19, 2008 at 10:59 AM, Hans Hagen <pragma@wxs.nl> wrote:

Stephen Kellett wrote:

An alternative approach to setting the file assocations (which I don't know will work) would be to write an exe that takes command line arguments and sets the file associations itself. It would do this by bumping up its privileges high enough to be able to modify the registry. Not sure if this is possible, it works for seDebug (DEBUG) privilege, but not sure it works for others.

can be done in a cmd file:

FTYPE RubyScript=c:\data\system\ruby\bin\ruby.exe %%1 %%*
FTYPE PerlScript=c:\data\system\perl\bin\perl.exe %%1 %%*
FTYPE PythonScript=c:\data\system\python\bin\python.exe %%1 %%*
FTYPE LuaScript=c:\data\system\lua\bin\lua.exe %%1 %%*

ASSOC .rb=RubyScript
ASSOC .rbw=RubyScript
ASSOC .pl=PerlScript
ASSOC .py=PythonScript
ASSOC .lua=LuaScript
ASSOC .luc=LuaScript

Hi,

Well just so you understand that a non-admin can not write to HKEY_CLASSES_ROOT registry key, so no matter if you escalate the running app (which is how the installer already works, no need to look into that) or use a cmd file, it still needs higher privileges. This is not a Vista issue, this is a user in XP that is only part of the 'Users' group. The way the present installer works is still the same. Any other ideas?

I really feel like this kind of integration is critical to the original design. For the installer to not integrate the file types, just seems counter intuitive and not meeting the requirements. Do we want to change our goals? I think a "simple, fast, and easy installer" is a great goal and anything less would sell this project short and be closer to what has already been done. Please share any thoughts, so we can discuss this further.
--
Regards,
Ryan
RJP Computing