#! /bin/lua (was Re: ~= vs. !=)

["Peter Hill" <corwin@...>]

>> I really don't see any need to support the use of # just to allow the use
>> of shell scripts

Reuben Thomas:
> No need; this is already supported, and has been for some time.

Rob Kendrick:
> Does it allow this from pre-compiled scripts?  I seem to recall that it
> didn't, but I've not checked later versions.  It'd be great if it did,
> though.

I don't think it does... but it SHOULD.

Specifically, the "#! /bin/lua" line is NOT a part of the script (and
shouldn't be a part of the Lua syntax). It is an operating system attachment
(just like a file extension in DOS) which, when combined with the "x" flag,
states what kind of file it is and how it should be used.

A Lua script (compiled or text) could be stored anywhere appropriate for the
operating system. It could be stored in a file, in a database (especially
for "file-less" systems like a Palm), or be received over HTTP with a MIME
type of "text/lua" (or some such). Whatever form a Lua file is stored in,
the version of Lua compiled for an operating system should be configured to
gracefully handle that system's file typing. That unix happens to put some
of the type information "in-band" is no reason not to treat it as what it
is... type information.

For Lua on a unix system, a file with the "x" flag set should start with a
"#! /bin/lua" line (whether the file is Lua text or Lua byte code) followed
by the actual file. The Lua interpreter will be piped the data after the
"#!" line (which it won't see).

When reading a Lua file from a program (on ANY system) there should be a
"file open for Lua" command (both for reading and for creation) which
gracefully handles the OS's data typing. On opening a Lua file for reading
it verifies the file as being registered as an executable Lua file but
otherwise transparently skips the type (eg, check a ".lua" extension; check
a "#! /bin/lua" preamble + "x" attribute; etc). On opening a Lua file for
creation the system transparently sets up the appropriate type for the OS
(eg, add a ".lua" extension; add a "#! /bin/lua" preamble & set the "x"
flag; set a db-type field to DB-TYPE-LUA; etc).

This should apply transparently to any part of the "file system" which a Lua
program can access. If a Lua implementation can access different file
systems then it should handle them all gracefully. Eg, if an OS allows a Lua
file to be read from both a local DOS disk (read via a DOS file open, with
".lua" extension) and an HTTP resource (read as something like
"Content-Type: program/lua") then it should handle both cases.

*cheers*
Peter Hill.