[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Clamping down on unwanted using "strict"... or others?
- From: Pierre-Yves Gérardy <pygy79@...>
- Date: Fri, 5 Jan 2018 12:15:05 +0100
Alternatively, you can
And ignore failure. If you rely on the global() function, you can
replace it with a noop shim if that pcall returns false.
On Fri, Jan 5, 2018 at 11:04 AM, Dirk Laurie <email@example.com> wrote:
> 2018-01-05 11:06 GMT+02:00 sur-behoffski <firstname.lastname@example.org>:
>> Roberto's written a short "strict.lua" script, that resides in the
>> etc/ subdirectory of the release, but isn't explicitly installed on
>> at least two Debian-descendant distributions that I've used, including
>> the source-based Gentoo Linux.
> It is not in the typical tarball that you download from lua.org,
> which does not have an /etc subdirectory.
>> Roberto's script is explicitly compatible with Lua 5.1 and 5.2. I
>> haven't checked whether the 5.3 case works (I'm limiting myself to
>> 5.1, for the moment).
> I have just tried `lua -i /path-to-5.1.5/strict.lua` from 5.3.4, and can
> confirm that the exact script with a 2008 creation date on it still works.
> AFAICS the only difference in the LuaRocks version is that the
> packager has added LDoc-style comments.
>> In summary, I don't need any extra feature that "strictness" gives
>> me, and I would strongly prefer that I could issue scripts that
>> worked with Lua binary (or source) distributions that worked
>> "out-of-the-box", but with "strict.lua" strategically placed to
>> be on the require search path, such that I did not have to ask the
>> user to install LuaRocks and/or go through other steps.
> Why must a 40-line script (7 lines of which is documentation
> and 5 blank that has not needed maintenance changes in
> almost eight years be a loaded module? You can simply include
> it in your code with a comment acknowledging the source.