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

[Daniel Silverstone <dsilvers@...>]

On Thu, 2003-11-27 at 15:10, Peter Hill wrote:
> > the 'shebang' as it is often referred to indicates to the kernel (or
> > shell, or whatever feels like parsing it) what program to run (and what
> > args to give it) to get it to parse the program in question...
> Ie, it denotes that the rest of the file is an 'executable' suitable for
> handling by the program mentioned in the 'shebang'.

It denotes that the entire file (including the shebang) is for the
program mentioned.

> You seem to have missed my point. The 'shebang' is a feature of a specific
> _Operating System_... NOT of Lua.

Indeed the 'execute this in the right way' bit of it is, but a Lua
interpreter on a system which uses shebangs needs to be able to cope
with it.

> It's sloppiness of the part of an operating system to put such data 'in
> band' (Windows handles it by giving the file and extension, eg ".lua", and
> mapping ".lua -> C:\Program Files\Lua\WinLua.exe"), and recognising it is
> not something that should occur as high up as the Lua syntax (which can be
> sourced from a variety of places & systems). Ie, the Lua Parser should NEVER
> see it at all. Rather, it should be handled lower down in base routines that
> are closer to the operating system.

Unfortunately you are dealing here with a standard which has been in
place since way before I was born. You'd best go back in time to when
the UNIX operating system was being designed and implemented, and
persuade them not to use #! at the start of their scripts.

> It is my understanding of shells (correct me if I'm wrong) that putting a
> 'shebang' at the front of a file causes the shell to execute the 'shebang'
> program with the *remainder* of the file piped as standard input. Thus,
> appending a 'shebang' to the front of a Lua byte-code file should work just
> fine if it is just run from the shell prompt. Of course Lua code loaders
> like 'loadstring' etc used on the contents of the file would not work unless
> they understood the 'shebang' but that is a different issue.

You are wrong, as I explained before. It does *NOT* cause any piping of
the script, as you could see from my example. Also, pre-pending a
shebang to a lump of binary goo (while completely 'correct' from the
point of view of unix) somewhat goes against the grain that the shebang
is meant for human-editable scripting languages rather than 'compiled'
executables.

> The core of Lua works in the ANSI standard. By necessity, porting Lua to
> different Operating Systems may require that some low-level routines use
> non-ANSI Operating System specific system calls (some systems where Lua runs
> are, after all, very esoteric). I did not say that an implementer *must*
> recognise the 'x' flag... that is their choice (they might simply use the
> 'shebang' to identify the file). What I'm doing is giving people the
> *option* to do so by encapsulating the 'typing' of Lua executables in low
> level routines.

Unfortunately that would require changes at a fundamental level to most
operating systems currently available. Well, either that, or a large
number of OS specific extensions to Lua for when things need to be
switched on or off depending on what operating system services are
available.

> Rob Kendrick:
> > It already does rely on system knowledge.  (The ignoring of #! lines in
> > text lumps.)
> You said it all!
> The core of Lua should not rely on any operating system stuff, and Shebangs
> are just that! Not all Operating Systems use them and unless Lua is compiled
> for such a system it *should* have such OS-specific code commented out!

I think here is where you hit the nail on the head. The shebang *is* for
UNIX and unixlike operating systems and to an extent, really shouldn't
be included if you compile your Lua binary to run on Windows (excepting
of course the facilities which Cygwin offers you).

My essential gripe with your posting before (which both you and Rob
appeared to miss) was simply that on systems where you would expect a
shebang to work, it *IS* up to the interpreter (lua in this case) to
handle the shebang, since the OS will simply trigger on it and launch
the right interpreter with some commandline arguments. There is no
institutionalised stripping of the shebang before the interpreter gets
its hands on the file.

Having the type information and semantics for loading the right
interpreter "out of band" seems to be your argument, and to that extent,
using the linux binfmt_misc associations, or the windows extension
associations (or whatever your particular OS chooses to provide) is the
more pleasant way of going about it.

Your only issue then, is what if I want to write a lua program which
uses *my* lua interpreter which I compiled and put somewhere else on the
system? If the decision is hidden away from the user in some system
defined way, how can I tell the OS to use my interpreter instead?

Anyway, an interesting set of comments by all three of us I think, and
perhaps the Lua guys will consider making the #! skipping part of the
ZIO layer rather than the parser (if it isn't already) and as such make
it possible for shebangs to prefix compiled chunks; and subsequent to
that, make it possible to compile it out (perhaps via a -DNOSHEBANG in
the CFLAGS) if you don't want such processing in your system.

Regards,

D.

(P.S. what flavour of fairys do you have photos of?)

-- 
Daniel Silverstone                       http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler: Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org       KeyId: 20687895