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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

sur-behoffski
G'day,

I'm writing Lua scripts, mostly for my own benefit (e.g. automate
system management tasks), but occasionally I have a specific goal of
sharing the code with others.

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.

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).

As an alternative, I've been using the module "strictness" from
LuaRocks... but LuaRocks itself is something of a moving target: On
Linux Mint (18.3), pre-packaged versions of luarocks only go up to
2.2.0.

As a result, for both Mint and Gentoo, the "luarocks list --outdated"
did not work from packages... I had to bypass the packaging system
(very bad karma) and install 2.4.3.

(I strayed briefly into the world of LuaRocks 3.x while on the Mint
system... many things were flagged as incompatible, and I had to
quickly retreat.)

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.

So, there are two items that come out of the preceding observations:

      1. How hard is it to convince Debian (and downstream distros)
         to move from 2.2.0 to 2.4.3?; and
      2a. For current Lua releases, can "make install" include copying
          etc/strict.lua to a require-accessible location?; plus
      2b. For older Lua versions (perhaps 5.0 onwards?), can the
          distro choose to add value to the package, by performing
          a suitable placement of strict.lua?

cheers,

s-b etc
programmer, Grouse Software

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
2018-01-05 11:06 GMT+02:00 sur-behoffski <[hidden email]>:

> 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.

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
> It is not in the typical tarball that you download from lua.org,
> which does not have an /etc subdirectory.

strict.lua and other tools are at http://www.lua.org/extras/

Reply | Threaded
Open this post in threaded view
|

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

Pierre-Yves Gérardy
In reply to this post by Dirk Laurie-2
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 <[hidden email]> wrote:

> 2018-01-05 11:06 GMT+02:00 sur-behoffski <[hidden email]>:
>
>> 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.
>

Reply | Threaded
Open this post in threaded view
|

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

Paul E. Merrell, J.D.
In reply to this post by sur-behoffski
On Fri, Jan 5, 2018 at 1:06 AM, sur-behoffski
<[hidden email]> wrote:
> 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.
>
> 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 use strict.lua with v. 5.3 routinely, although I don't remember
where I got it.

Best regards,

Paul


--
[Notice not included in the above original message:  The U.S. National
Security Agency neither confirms nor denies that it intercepted this
message.]

Reply | Threaded
Open this post in threaded view
|

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

Gary V. Vaughan

On Jan 5, 2018, at 7:27 AM, Paul Merrell <[hidden email]> wrote:

On Fri, Jan 5, 2018 at 1:06 AM, sur-behoffski
<[hidden email]> wrote:
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.

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 use strict.lua with v. 5.3 routinely, although I don't remember
where I got it.

Best regards,

Paul

Another option (as a luarocks dependency or for copying into place in your own distribution), with additional features over lhf’s original is:


Cheers,
Gary