[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua Distributions and Package Management
- From: Sean Conner <sean@...>
- Date: Sat, 28 Sep 2013 18:47:49 -0400
It was thus said that the Great steve donovan once stated:
> On Thu, Sep 26, 2013 at 6:18 PM, Sean Conner <firstname.lastname@example.org> wrote:
> > Coming from the Unix world, I'm used to the "configure; make; make
> > install" method of installation . And unless I change it with some
> > options to configure, everything ends up installed in /usr/local.
> As a practical contribution to this otherwise entertaining discussion,
> I've put together a generic installer script here:
> The basic idea is that you customize the script and put a little
> install function up front. For instance, LDoc is easy, since it's just
> a matter of creating a wrapper which points to ldoc.lua in the dir you
> extracted the archive:
"You" as in the person trying to install a package, or "You" as in the
author of a package? Because the way you wrote that, it sounds like "You"
as in the person trying to install a package.
> Currently this script is sitting uneasily between 'dead simple' and
> 'covers everything'; I have had to make assumptions. On Unix, if you
> run as su, scripts go to /usr/local/bin and modules go to the usual
> places. If not su, it will try to find a directory on the Lua module
> path which is user-writeable, and ditto for /home/user/bin for
Careful there, as a default Unix install of Lua has "./?.so" first in the
LUA_CPATH and "./?.lua" in the LUA_PATH, so if you aren't root, then you're
going to be trying to install in the current directory, which may not end
Some other comments going over the code:
1. To be pedantically correct (and who doesn't 8-P you should use
package.config, as that contains:
LUA_DIRSEP = package.config:sub(1,1)
LUA_PATHSEP = package.config:sub(3,3)
LUA_PATH_MARK = package.config:sub(5,5)
LUA_EXECDIR = package.config:sub(7,7)
LUA_IGMARK = package.config:sub(9,9)
From that, you should be able to determine the shared object extension by
looking for LUA_PATH_MARK .. ".(%S+)" somewhere along package.cpath.
2. I was unaware that $HOME/bin was a common Unix idiom. And why are you
checking for $HOME/bin (or /usr/local/bin)?
3. I have an issue with your Windows version of an absolute path. On
Unix, '/' as the start marks an absolute path, but that's only because Unix
does not have the concept of drive letters. On Windows though, you have
which is a relative path to the current location. Then you have
which is an abolute path on the current drive, and then
which is an absolute path on a particular drive. Also, Windows isn't the
only operating system with the concept of "drives"---there's AmigaOS, which
had the concept, but didn't limit it to a single character:
Heck, that leads me to ask (since I don't have a Windows system to test this
valid? That is, relative to the current directory on the C: drive? I seem
to recall that MS-DOS kept track of the current directory on each drive.
mkdir -p /home/spc/.luarocks/lib/lua/5.1/
cp -r lua/mod /home/spc/.luarocks/lib/lua/5.1/
cp: cannot stat `Lua/mod': No such file or directory
install: command failed: were you running as an administrator?
-spc (Just saying ... )
 Yes, that *IS* a valid path in Windows. The Windows kernel does not
care if you use '/' or '\' as a path separator and will happily
accept both. It's just the default Windows command line that
bitches, and only because Windows (and MS-DOS, the precursor to
Windows) used '/' to mark command line options .
 Which came from CP/M, which in turn, got it from RT-11. Past that,
I don't know where it came from.
 INT 21H, function 37H, Get/Set Switch Character
AH - 37H
AL - 0 read switch character
AL - 1 set switch character (in DL)
DL - character
DL - switch character
AL - 0FFH on error
It defaulted to '/' but could be changed.