Re: Clamping down on unwanted using "strict"... or others?

[Pierre-Yves Gérardy <pygy79@...>]

Alternatively, you can

    pcall(require, "strict")

And ignore failure. If you rely on the global() function, you can
replace it with a noop shim if that pcall returns false.


—Pierre-Yves


On Fri, Jan 5, 2018 at 11:04 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2018-01-05 11:06 GMT+02:00 sur-behoffski <sur_behoffski@grouse.com.au>:
>
>> 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.
>