Re: /usr/bin/env and the Lua bytecode format

[Julian Squires <tek@...>]

On Thu, Aug 02, 2001 at 09:39:22PM +0900, John Belmonte wrote:
> Right, another option for John (and superiour in my opinion) is to use
> binfmt.  With the recent release of binfmt-support it's easy to set this
> stuff up.  It's possible to feed environment variables to the bitfmt wrapper
> script to select the interpreter path as well.

Isn't binfmt a Linux-only thing? I might be wrong here, but I feel
the #! system is really the more portable way of doing it (although
the binfmt approach would be good for interim measures on a Linux
system where someone didn't want to modify the lua interpreter).

By the way, is there a commonly used /etc/magic entry for lua bytecode?
I currently use:
0	byte	0x1b
>1	string	Lua	Lua byte-code
>>4	byte	x	(version %x)

> On a more general note, I acknowledge that there are two Lua camps... both
> valid.  One treats standalone Lua (which is just a snapshot of Lua...
> remember the standard libraries can be completely changed while still
> calling the result "Lua") as if it were Perl or Python.  The other treats
> Lua as something to link to their app and extend at will.  To someone in the
> second camp like me, doing things like implementing Lua on the Java VM or
> making a Debian package that actually installs an executable is going to
> look strange.  (For example the main reason I use Lua as opposed to
> something on the Java VM is because those don't fit on my target system.)
> Anyway my point is that we should be aware that these different camps exist
> when we post to the list.

Indeed. I am also a camp two person, and actually one of the reasons
I decided to delurk a second time was to make sure that it was well
known that a lot of people are still interested in lua as a small,
fast, embeddable and extensible language. I know it is well-recognized,
but I have occasional panic attacks when I see all these proposals
for changes to lua to make it more like $language_of_the_week.

-- 
  -/ 
 |/|  Julian Squires <tek@wiw.org>
 /-