Extension talk:Scribunto/Flow

I would love to use Scribunto modules, but any time I try to invoke (or even view a module page) I get an error:

Fatal exception of type "MediaWiki\Extension\Scribunto\Engines\LuaCommon\LuaInterpreterNotExecutableError"

Is there some troubleshooting steps I could take to help me determine what I'm missing?

Version information is:

• MediaWiki 1.41.0
• PHP 8.3.4 (litespeed)
• Scribunto – (4b702cb) 21:44, 19 December 2023 (came packaged with MW)

PhpInfo says:

• PCRE 10+
• mbstring enabled

And I set permissions on extensions/Scribunto/includes/Engines/LuaStandalone/binaries/<all OS>/lua to 755

Localsettings.php says

wfLoadExtension( 'Scribunto' ); 
$wgScribuntoDefaultEngine = 'luastandalone';

Were you able to solve this issue? I'm currently running into the same problem and have not been able to find any solution.

No. This issue still occurs.

Hey mate. This might not fix your problem because you actually did what I did to fix it, but it might help someone else and this is the only page that shows up when I Googled this error. (I barely know how any of this stuff works but I fixed the problem for myself after a frustrating day of messing around)

1. I set the four debug configuration options in Manual:How to debug to "true"
2. After doing that, when trying to edit a Module my error changed from Fatal exception of type "MediaWiki\Extension\Scribunto\Engines\LuaCommon\LuaInterpreterNotExecutableError" to /index.php?title=Module:Infobox&action=submit MediaWiki\Extension\Scribunto\Engines\LuaCommon\LuaInterpreterNotExecutableError: The lua binary (/home/caseambe/public_html/extensions/Scribunto/includes/Engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua) is not executable. and the backtrace
3. I went to that file in my cpanel file manager and found that the permissions of the "lua" file itself was set to 0644 (I was looking at the permissions of the folder one level up it was contained in before). I set this to 0755 and it immediately fixed my problem.

Here is my version information:

MediaWiki	1.42.3
PHP	8.1.31 (litespeed)
ICU	64.2
MariaDB	10.5.27-MariaDB-cll-lve
Lua	5.1.5

I'm running MediaWiki with Semantic MediaWiki and am getting 'Lua error: Internal error: The interpreter has terminated with signal "11".'

MediaWiki 1.41.4

PHP 8.2.24 (litespeed)

MySQL 8.0.33-cll-lve

Lua 5.1.5

Semantic MediaWiki 4.2.0

In LocalSettings.php I have $wgScribuntoDefaultEngine = 'luastandalone';

I set execute permissions for the Lua binaries. /LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua is 755.

SELinux is disabled on the server.

In my log file I see:

[rdbms] LCStoreDB::get [0s] localhost: SELECT  lc_value  FROM `mwvq_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:scribunto-doc-page-name'  LIMIT 1  
[ContentHandler] Registered handler for Scribunto: MediaWiki\Extension\Scribunto\ScribuntoContentHandler
[Scribunto] MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneInterpreter::__construct: creating interpreter: 'exec' '/bin/sh' '/home/mediawiki-1.41.4/extensions/Scribunto/includes/Engines/LuaStandalone/lua_ulimit.sh' '7' '8' '51200' ''\''/home/mediawiki-1.41.4/extensions/Scribunto/includes/Engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua'\'' '\''/home/mediawiki-1.41.4/extensions/Scribunto/includes/Engines/LuaStandalone/mw_main.lua'\'' '\''/home/mediawiki-1.41.4/extensions/Scribunto/includes'\'' '\''0'\'' '\''8'\
[rdbms] LCStoreDB::get [0s] localhost: SELECT  lc_value  FROM `mwvq_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:scribunto-luastandalone-signal'  LIMIT 1  
[rdbms] LCStoreDB::get [0s] localhost: SELECT  lc_value  FROM `mwvq_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:scribunto-common-no-details'  LIMIT 1  
[rdbms] LCStoreDB::get [0s] localhost: SELECT  lc_value  FROM `mwvq_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:scribunto-common-error-category'  LIMIT 1  
[Scribunto] MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneInterpreter::__construct: creating interpreter: 'exec' '/bin/sh' '/home/mediawiki-1.41.4/extensions/Scribunto/includes/Engines/LuaStandalone/lua_ulimit.sh' '7' '8' '51200' ''\''/home/mediawiki-1.41.4/extensions/Scribunto/includes/Engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua'\'' '\''/home/mediawiki-1.41.4/extensions/Scribunto/includes/Engines/LuaStandalone/mw_main.lua'\'' '\''/home/mediawiki-1.41.4/extensions/Scribunto/includes'\'' '\''1'\'' '\''8'\

I'm assuming that since Special:Version is showing Lua 5.1.5 and the log seems to indicate that LuaStandaloneInterpreter is functioning that I have installed and configured the extension properly, but there is some other issue?

My Ubuntu version is 22.04.3, and my Lua version is 5.1.5. I am trying to create a new module, but the system reports an error: lua error: internal error: the interpreter exited with status 127. I have tried pointing the Lua path to both the one included with the Scribunto plugin and the system-installed Lua path, but both return the same error 127. I have correctly set the permissions, and both Lua versions work fine. What should I do now?

Continue non-Lua methods (e.g. Widgets).

With templates I've used Extension:Widgets to display external images. I would prefer not to use set $wgAllowExternalImages = true. Is it possible to display external images when using Lua? Thanks.

I gave up far too soon... within minutes I noticed that it's possible to use Widgets via Lua using Extension:Scribunto/Lua_reference_manual#frame:callParserFunction.

But is there a better way?

Ext:Widgets doesn't have any built-in Lua bindings, so callParserFunction is pretty much it. If your widget call is in a template and you want it to stay there, you could also use frame:expandTemplate.

Thank you very much.

Reply: table.insert the pieces into a table, then table.concat when you want to return the string

I've been muddling through with Lua, and have been using output = output .. 'xyz' throughout modules, then return output at the end. But I read that repeated string concatenation isn't the best way of doing this. What is the recommended way for MediaWiki modules? Thanks :-)

For strings that get repeatedly concatenated to, a good method is to table.insert the pieces into a table, then table.concat when you want to return the string

In general, string concatenation will work just fine. It does use more resources than Dinoguy1000's method, as Lua will need to allocate memory for each intermediate string, and then garbage collect unused strings as necessary. However, it will not make an appreciable difference unless you are concatenating a lot of strings.

If you are concatenating less than, say, 100 strings to make your output, it's probably not worth the effort of switching from one style to another. It will probably need to be tens of thousands of string concatenations before you notice an actual performance difference between the two styles. Although, as with everything performance-related, you have to actually measure it to know for sure.

If you are willing to take on an additional dependency, you could also use something like Module:OutputBuffer. This module provides an easy-to-use wrapper for table.concat.

Worrying about the performance of mw.text.split is unnecessary microoptimization, for most purposes.

I just want to be able to split comma-separated Cargo list fields. The notes on mw.text.split at Extension:Scribunto/Lua_reference_manual says "this function can be over 60 times slower than a reimplementation that is not Unicode-aware". I modified something from the internet. Would it make any noticeable speed difference - does it look like it will work all right? - are there better ways? It seems to work but I don't know Lua yet.

-- Source: http://lua-users.org/wiki/MakingLuaLikePhp (modified)
-- Credit: http://richard.warburton.it/
function explode(str)
    local pos,arr = 0,{}
    for st,sp in function() return string.find(str,',',pos,true) end do
        table.insert(arr,string.sub(str,pos,st-1))
        pos = sp + 1
    end
    table.insert(arr,string.sub(str,pos))
    return arr
end

You shouldn't worry about Lua performance until you have to; if the code you posted finishes in 10 microseconds on a typical list, mw.text.split will "only" take ~600 microseconds - i.e. still less than a millisecond. Even when you do have to worry about performance (e.g. page parses are consistently taking more than a second), you'll probably find the largest gains elsewhere, not in this microopimization.

Thanks :-)

@Jonathan3 And if you were going to use any accelerated, non-Unicode-aware reimplementation of mw.text.split, the sensible one to use would be the one that's provided right in the documentation you linked to. When the wheel has already been invented twice, why reinvent it a third time?

I agree 1000% with @Dinoguy1000 that fretting over such microoptimizations is misguided and unnecessary. (In fact, IMHO those extensive code blocks containing reimplemented mw.text.sub and mw.text.gsub functions should be removed from the Lua reference manual and relocated... well, either somewhere else, or nowhere at all. At most, a footnote regarding the speed of the functions is the appropriate level of making-users-worry-over-nothing.) But given that they are, for the moment, still there...

"When the wheel has already been invented twice, why reinvent it a third time?"

Purely because it was shorter, silly as that sounds now :-)

I had a feeling that Lua would be faster than byzantine templates, so had speed on my mind, and "60 times slower" made me ask the question here... so perhaps you are right about editing the reference manual!

(I'm still new to Wiki, so excuses if this is the wrong forum/format/question, but please bare with me.)

I have a fresh install of WikiMedia version 1.35, running on IIS (Windows 2016. It can't be avoided to run on Windows). After installing the usual extensions, I run into a problem with Scribunto. As per the manual, I have in my LocalSettings.php:

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

error_reporting( -1 );

ini_set( 'display_errors', 1);

$wgShowExeptionDetails = true;

$wgDebugLogFile = "D:/log/debug-{$wgDBname}.log";

$wgScribuntoEngineConf['luastandalone']['errorFile'] = 'D:/log/scribunto.log';

On a page I have the line below in the source (without the tildes, or that would be interpreted here):

~{~{\#invoke:main|main~}~}

When viewing the page, I get the error: Lua error: Internal error: The interpreter exited with status 1.

In the log file I see this:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/mw_main.lua" "D:\wwwroot\kb\extensions\Scribunto\includes" "0" "8""

As you can see, there is a mix of slashes and backslashes which may the cause of the error (?)

Doing some searching in the code, it seem to come from: LuaStandaloneInterpreter.php

In particular the lines:

$options['luaPath'] = __DIR__ . "/binaries/$path";

and:

__DIR__ . '/mw_main.lua',

Where __DIR__ has the value: "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone", while the code seems to expect to be "D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone"

I don't see where __DIR__ gets initialized, so the problem could be in a different PHP file?

I have also tried to add the below line to my LocalSettings.php:

#$wgScribuntoEngineConf['luastandalone']['luaPath'] = 'D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe';

After which the page still doesn't work and logs shows this:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/mw_main.lua" "D:\wwwroot\kb\extensions\Scribunto\includes" "0" "8""

So that only partially fixed the problem, but the filepath to mw_main.lua still has mixed slashes.

I have made some changes to LuaStandaloneInterpreter.php by hardcoding the path (just for testing). The log now shows:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/mw_main.lua" "D:/wwwroot/kb/extensions/Scribunto/includes" "0" "8""

But I still get the same error on the page and in the Scribunto.log file shows this:

'""D:' is not recognized as an internal or external command, operable program or batch file.

Which seems to indicate that it doesn't like the drive letter?

Removing the drive letter from the code, gives a similar output as above (without the drive letter) but the Scribunto.log files shows:

'""' is not recognized as an internal or external command, operable program or batch file.

After extensive Googling and trying different options, I don't know what else to do, but hopefully, the above informaiton will make more sense to an expert? Thanks for your help in advance!!

Ps. I have checked that all folders and files mentioned here exist and the process has access to it.

I know it's been almost a month, but... ¯\_(ツ)_/¯.

I believe __DIR__ is simply the current directory in PHP, IOW __DIR__ . "/binaries/$path" is just a way to build a relative path. If it mixes the slashes, then I assume it can interpret them either way and that's not actually the problem at all. If you notice, your output before and after the change is exactly the same:

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:\wwwroot\kb\extensions\Scribunto\includes\engines\LuaStandalone/mw_main.lua" "D:\wwwroot\kb\extensions\Scribunto\includes" "0" "8""

vs.

[Scribunto] Scribunto_LuaStandaloneInterpreter::__construct: creating interpreter: ""D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe" "D:/wwwroot/kb/extensions/Scribunto/includes/engines/LuaStandalone/mw_main.lua" "D:/wwwroot/kb/extensions/Scribunto/includes" "0" "8""

Aside from the mixed slashes, those are identical. So, changing it only "fixed the problem" if the slashes were the problem. (That's also assuming forward slashes would be the correct format to use, which isn't clear at all so far.)

The problem is likely not the drive letter, or the slashes; it looks like it's the quoting. If you parse the log messages you posted carefully, what they're saying is, respectively:

• ""D: is not recognized as an internal or external command, etc...
• "" is not recognized as an internal or external command, etc...

Something seems to be causing your commands and/or command args to get double-doublequoted, in a way that's breaking... something else, whether it's PHP, MediaWiki, Scribunto, or lua5.1.exe. And then only the contents up to the first slash are being interpreted... which may be a symptom of the bad quoting, it could be a sign of possibly-now-wrong slashes, or there may be some other issue entirely. At this point things are so muddled that it's hard to say.

You can try following the advice given to Vapblack below, and install an external version of Lua somewhere, then set $wgScribuntoEngineConf['luastandalone']['luaPath'] to the path to that Lua executable in your site config. But even if you do that, you should also completely reinstall Scribunto to ensure that any changes you made are reversed.

As this blog post indirectly makes clear, MediaWiki and Scribunto both work fine running under IIS, it's just a matter of properly configuring everything. But you don't need to modify its source code to do that. Any changes you made are more likely to interfere with getting it to work, even after you've got the configuration right. (And because of that, how could you even tell if it's correctly configured, once it is?)

I'm having a similar issue to GerardNL3 (did you manage to solve it?). I did a fresh install of Mediawiki 1.35.2 and am running on Windows 10 & xampp 8.0.6.

MediaWiki	1.35.2
PHP	8.0.6 (apache2handler)
MariaDB	10.4.19-MariaDB
Lua	5.1.5

Whenever i type the {{}} syntax, I get the message - Lua error: Internal error: The interpreter exited with status 1. I have added the following to LocalSettings.php

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['errorFile'] = "$IP/images/temp/lua-error.log";

wfLoadExtension( 'ParserFunctions' );

$wgPFEnableStringFunctions = true;

I have tried to add $wgScribuntoEngineConf['luastandalone']['luaPath'] = "$IP/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe"; as according to the suggestion above, but somehow it simply does not work. Similar to GerardNL3, I have double double-quotations

The error log would indicate:

'""D:\xampp\htdocs\wiki' is not recognized as an internal or external command, operable program or batch file.

If i remove that line from the LocalSettings.php, then the error log would indicate:

'""D:\xampp\htdocs\wiki\extensions\Scribunto\includes\engines\LuaStandalone' is not recognized as an internal or external command, operable program or batch file.

It seems that by adding the luaPath to LocalSettings.php, it stopped navigating to the extensions\Scribunto.....\LuaStandalone folder. It simply stopped at $IP (contents up to the first slash - as mentioned in FeRDNYC's post), so I removed that line.

I also checked the LuaStandaloneInterpreter.php. I tried changing lines 82 & 92 to point it to the lua5.1.exe file, but no matter what combinations I try, it just does not seem to work.

                   $path = 'lua5_1_5_Win64_bin/lua5.1.exe';

           $options['luaPath'] = __DIR__ . "/binaries/$path";

I also tried copying the file into the /extensions/Scribunto/includes/engines/LuaStandalone/ folder and changing line 92 to __DIR__ . "/lua5.1.exe"; but it still does not work.

I tried saving the page with the {{}} code, and the error showed:

[487f59ff3f43638788ef7c01] /wiki/index.php?title=Test&action=submit MWException from line 95 of D:\xampp\htdocs\wiki\extensions\Scribunto\includes\engines\LuaStandalone\LuaStandaloneInterpreter.php: The lua binary (D:\xampp\htdocs\wiki\extensions\Scribunto\includes\engines\LuaStandalonelua5.1.exe) is not executable.

I noted that the "LuaStandalonelua5.1.exe" had a missing \. Line 95 of LuaStandaloneInterpreter.php shows:

               throw new MWException(

What's wrong with this line?

Hey just comment out line 132 in $wiki/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php

looks like this: //$cmd = '"' . $cmd . '"';

It might break something somewhere, but it made it work for me. I probably don't have spaces in the filename; it might break if you do.

(this eliminates the double quote problem)

I did a clean install of Mediawiki 1.36 with new extensions and new LocalSettings.php. I imported my database and images only from my previous wiki version 1.34. I was getting this same issue. I tried all different ways to put the path into the LocalSettings.php following the other posts I have seen about this, and nothing worked.

SOLVED.

Commenting out line 132 as the above person wrote, did work. Why this changed between 1.34 and 1.36, I don't know. Looks like this would only be a problem for those installing on a windows server (NT type OS).

As the previous poster wrote, I hope this doesn't break anything else.

OMG!! It looks like it worked! Thank you Lonepointe! Thank you 63.245.160.132!

The thing of it is, that line of code has actually been in Scribunto for nine years already (ever since this commit), the only changes have been to move which source file it's located in. And enclosing the entire command string with double-quotes has long been an accepted workaround for bugs in PHP's handling of cmd.exe subprocesses.

So, either the "what's changed" is elsewhere (a change in the method used to launch the Lua interpreter?), or something external — a newer version of PHP that finally fixes this, perhaps? Or maybe PowerShell has finally replaced cmd.exe, as the subshell for external processes?

For me, the solution provided by Lonepointe leads to:

Fatal error: Maximum execution time of 30 seconds exceeded in C:\Apache24\htdocs\wiki\extensions\Scribunto\includes\engines\LuaStandalone\LuaStandaloneInterpreter.php on line 462

Any help? I installed everything as it should be, perhaps I am missing something?

Hmm. What's at that line? Is it the same as in the current source code — part of the dispatch function?

That function does contain a potentially dangerous loop. Theoretically it should always terminate, either by returning from the function, breaking out of the loop, or throwing an exception. (Wonder why it's even a loop, then?)

But... I'm not particularly well-versed in PHP as a language, so for someone who knows it better: What would happen if the $msgFromLua array didn't contain a member 'op'? Could that bypass all branches of the switch, and turn the while( true ) into an infinite loop?

No, in this case $msgFromLua['op'] evaluates to null (emitting an E_NOTICE about undefined array index), so the default branch applies (unless MediaWiki turns E_NOTICE into an exception; I don’t know if it happens, but the result is an exception anyway). The only way it’s an infinite loop is that $this->receiveMessage()['op'] is 'call' for an infinite number of calls—the break breaks out only from the switch, not the loop.

However, line 462 is actually within another function, and it’s an fread call. The documentation says it normally reads exactly 16 bytes (the second parameter of the function call), so if Lua writes less than 16 bytes and doesn’t send EOF on its standard output (doesn’t terminate or close its stdout manually), PHP will wait infinitely for the rest.

Yikes, I somehow read 432 instead of 462! Sorry for the misdirection there, @Anoneedes. (And of course thanks to @Tacsipacsi for bringing some sense to combat my ramblings.)

So, I was sort of playing along at home with this, having become curious about the issue, and I did finally get Lua working under IIS on Windows 10, with PHP 8.0. The trick was, I abandoned the luaStandalone binary entirely, and instead downloaded the (just released less than 2 months ago) PHP luaSandbox extension from PECL: https://pecl.php.net/package/LuaSandbox

Click on "DLL", then choose the build that matches your PHP install (for me it was PHP 8.0, x64, non-thread safe — the details are at the very top of the long, long output of php.exe -i from a command line), and download the provided zip file. After extraction, only two files are important:

• php_luasandbox.dll, a PHP extension module that goes wherever the rest of your extensions are. (For me, C:\Program Files\PHP\v8.0\ext\.)
• lua5.1.dll, an embeddable Lua interpreter that gets installed... well, I'm not 100% sure. Either it goes in the PHP extensions directory, or in the directory above it where the PHP binary lives. I hedged my bets and dropped it in both places, but I'm pretty sure the right one was the latter (C:\Program Files\PHP\v8.0\ ).

After that, just edit your php.ini to add:

extension=php_luasandbox.dll

and edit LocalSettings.php to include:

$wgScribuntoDefaultEngine = 'luasandbox';

(making sure to remove or comment out any lines about luaStandalone).

Relaunch IIS, and that should be that. If you have MediaWiki working at all, you've already got PHP running, so using Lua that way, as a PHP extension, just makes eminent amounts of sense.

(Ugh, stupid filename typo in my above comment now corrected.)

Is this something that should be noted in Extension:Scribunto#Lua error: Internal error: The interpreter exited with status 1.

Or does this only happen to a few windows users? For me it happens with first time setup of MediaWiki 1.36.1 and XAMPP 8.0.8

@Ketho : I'm beginning to suspect that it affects (or likely affects) anyone running MediaWiki on Windows, at least if they use IIS as their webserver. Its configuration is... byzantine, and it's not well-incline to running executable programs from random (what it considers) content locations. Which is actually a pretty understandable bias, so hard to fault it. When using other webservers, even on Windows, it's possible this doesn't come up at all for most people.

One related issue, regardless, is that despite some handwaving about Windows support, the docs on the Scribunto extension page are currently entirely Linux-focused. (See e.g. the use of chmod and chcon commands in Bundled binaries, and the file command in Lua error: Internal error: 2. on ARM architecture, as well as the /bin/bash shell in the footnote at the bottom of the page. Those won't do Windows users any good at all.)

Still, adding a mention to that section of the docs is probably worth it (couldn't hurt, really). The question is, what advice we give Windows users for correcting the problem when it's encountered?

My initial inclination would've been to go all-in on the sandbox, and just recommend luasandbox in preference to luastandalone as the default for integration. Possibly even replacing the bundled binaries with either bundled DLLs or instructions on installing from PECL (the PHP Extension… something something).

But I see now from a read of some Lua wiki info and mailing list threads (see http://lua-users.org/wiki/SandBoxes and the mailing-list posts linked there) that sandboxing of Lua scripts is a controversial topic, and process-based isolation like the bundled standalone binaries is the recommended approach for running untrusted code. I don't know how much that holds for luasandbox.dll specifically but I have to imagine it's at least a concern.

(Standalone process isolation is recommended, I should say, in combination with external limits on process runtime and access to operating system resources, to prevent problem scripts from causing resource exhaustion. Measures, I feel obligated to point out, which are not really discussed on the Scribunto page at all.

There are some configuration variables provided for luastandalone, to set some limits — specifically, memoryLimit and cpuLimit. But the documentation also reports that those are "enforced by ulimit", a POSIX operating system feature which does not exist on Windows. So, I don't know how or if those work on Windows platforms. Not to mention, luasandbox is documented to accept those same two configuration variables.)

So, now I'm sort of at a loss for what approach makes sense. Recommending luasandbox may be ill-advised, but making luastandalone work on Windows is at least difficult, possibly impossible, at least with certain webservers. And it may be no safer, to boot, unless the user (a) knows to, and (b) knows how to, impose external restrictions on the Lua binary.

Aha! Yeah, here we go. The luasandbox configuration limiters are documented in the PHP documentation, where it's noted...

To make full use of the timer features, LuaSandbox should be installed on Linux.

If FreeBSD or Mac OS X is used, only real (wall-clock) time is supported, the functions purporting to return CPU time will actually return wall clock time.

If Windows is used, no timer functions will be supported. The time limits will be inoperable.

So, that covers that, at least for sandbox. I have a nagging suspicion the same holds for standalone, though.

Just upgraded from 1.37.1 to 1.39.0; running on Windows 11. This same problem occurs with Lua; (i.e. it sees "" at the start of the line and gets all cranky). I made the same update to comment out the line; but as of 1.39 it is now lines 137-143.in $wiki/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php

looks like this:

if ( php_uname( 's' ) == 'Windows NT' ) {

//... comments not copied

//$cmd = '"' . $cmd . '"';

Messing about with LuaSandBox seemed too much work :) (I ensured that my paths have no spaces else this entire hack might not work)

The hack that was used before is not working for me.

@Chubbuck3: Can you elaborate a bit on what "not working for me" looks like? We can't see your screen. Are you getting any error messages? What have you tried? In what version(s) of MediaWiki, PHP, Scribunto, etc...?

Hi all,

so I solved it by putting luaPath in localsettings.php and then putting $cmd = '"' . $cmd . '"'; in an if condition so that it does not break something somewhere else and that is

# smeer

if($cmd != ''){

$cmd = '"' . $cmd . '"';

}

that means if $cmd is not empty, that was the case in Infobox issue.

Thanks

In 2024, I encountered the same issue. It's hard to imagine that, without understanding the code, I eventually discovered that the problem lay in the configuration I wrote:

$wgScribuntoEngineConf['luastandalone']['luaPath'] = "$wgResourceBasePath/extensions/Scribunto/includes/Engines/LuaStandalone/binaries/lua5_1_5_Win64_bin/lua5.1.exe";

It seemed to conform to the official writing style, but it actually didn't. The correct configuration for Windows should be:

$wgScribuntoEngineConf['luastandalone']['luaPath'] = null;

Because once luaPath is set to null, the judgment in the LuaStandaloneInterpreter.php will automatically determine the operating system and version, and automatically match the path to lua5.1.exe for you.🤣😂

I feel like an idiot🤡

Looking at the actual source for LuaStandaloneInterpreter.php, that appears to be the case for every supported OS combination, at least when attempting to use the binaries bundled with Scribunto.

Do we recommend just setting the path to null, at least for starters? If not, we should. That seems way easier. If it doesn't work, then people can try other things.

Hi everyone,

I've been trying to solve this using error fixing advice I found elsewhere on this site, but it hasn't worked. I'm desperate at this point and really need help. I'm afraid I also know very little about all this, so please be patient with me.

What I'm trying to do is import Infoboxes from Wikipedia onto my own wiki. I followed the instructions under [1] and believe I've imported everything I need, but when I load e.g. [2], I get the following red error message:

"Lua error: Internal error: The interpreter exited with status 126."

This is new actually. It had previously been "status 11" (I think), but after following the instructions I found at [3], the message changed to "status 126".

Please, please help me!! And thank you in advance! :)

[1] Manual:Importing Wikipedia infoboxes tutorial

[2] Trying to avoid the spam filter here. My wiki is at "lacerta.palfreyman.de/wiki". There, search for "Template:Infobox".

[3] (Solved) Lua scribunto error on many pages (status 127)

Status 126 means that your Lua binary is not executable, according to bug T48135. To fix it, you need to change the permissions for the Lua binary. Probably running a command like this will work:

chmod +x path/to/lua

That bug report says that the message "The interpreter exited with status 126" was replaced with a more helpful error message, but on checking the code, it seems that the helpful error message is not output if you set the path to the Lua binary explicitly using the "luaPath" option.

i ran into this issue after migrating to an arm64/ARMv8 cluster (Linux.)

Scribunto does not ship with a compatible binary.

my deployments are containerized and k8s-managed, so I was able to fix this by layering a standalone Lua5.1 package on top of the official mediawiki container image (1.39) using apt, then updating wiki settings to point at the compatible image:

$wgScribuntoEngineConf['luastandalone']['luaPath'] = '/usr/bin/lua5.1'

incidentally, I also purged the files which aren't necessary for my platform, to reduce the image size a bit, from

extensions/Scribunto/includes/engines/LuaStandalone/binaries/

pushed the container image and performed a rollout restart to the cluster and presto-chango! working as intended again! took all of 5 minutes :) hope this helps someone else someday!

Wilson, you're a G. Luckily, my arm64 came with its own lua5.1 package, and the same /usr/bin/lua5.1 command worked, with the exception that it requires a semicolon ; at the end of the line.

Adding

$wgScribuntoEngineConf['luastandalone']['luaPath'] = '/usr/bin/lua5.1';

I've had the same status 126 error today.

So I added the following to LocalSettings.php:

$wgScribuntoEngineConf['luastandalone']['errorFile'] = '/var/lib/mediawiki/extensions/Scribunto/includes/Engines/LuaStandalone/ErrorFolder/luaerrors';

and this output the following:

/var/lib/mediawiki/extensions/Scribunto/includes/Engines/LuaStandalone/lua_ulimit.sh: 1: exec:

/var/lib/mediawiki/extensions/Scribunto/includes/Engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua: Exec format error

which seems to confirm the path to the lua executables.

However this was apparently incorrect, because when I then ran the command:

which lua

it output a different path:

/usr/bin/lua

So I updated the luaPath row in LocalSettings.php to:

$wgScribuntoEngineConf['luastandalone']['luaPath'] = '/usr/bin/lua';

which fixed the problem.

I found by running command-line command:

file lua

that the lua in the two paths were different, with the '/usr/bin/lua' one being for the ARM architecture, and the other not.

So error 126, on this occasion at least, is not that the lua is not executable. Instead it is that it is the incorrect version for the hardware.

I'm trying to make syntax highlighting working in modules but apparently sth is missing. I have installed WikiEditor, SyntaxHighlight, CodeEditor and have done everything as said in manual. All installed extension are working , just seems it dosen't work with Scribunto, so I guess the problem must be sth else

wfLoadExtension( 'WikiEditor' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'CodeEditor' );

wfLoadExtension( 'Scribunto' );

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['key'] = 'value';

$wgScribuntoUseGeSHi = true;

$wgScribuntoUseCodeEditor = true;

http://escforumwiki.com/index.php?title=Module:Documentation

I do not see a solution and outcome here. I am having the same issue. We do not have CodeEditor installed though. Is that required?

Syntax highlighting is working on all other pages as expected. With the following should we see module syntax highlighting or do we need anything else?

$wgScribuntoDefaultEngine = 'luastandalone';

$wgScribuntoEngineConf['luastandalone']['key'] = 'value';

$wgScribuntoUseGeSHi = true;

wfLoadExtension( 'WikiEditor' );

wfLoadExtension( 'SyntaxHighlight_GeSHi' );

wfLoadExtension( 'Scribunto' );

Update: I just copied the Lua code from a Module window. Pasted it into a blank page and surrounded it with <syntaxhighlight lang="Lua">. When I click show demo it was all nice and colorful and matches how it looks on the same module on Wikipedia. So our SyntaxHighlight seems fine. The Module view just does not show it on our Wiki.

Five years on, has anyone found a solution to this problem of Scribunto seemingly failing to call CodeEditor and WikiEditor in the text editor? (I'm not referring to the SyntaxHighlight extension, which is a different topic). Or have any clues where to look for potential problems?

MW 1.39.6 | WikiEditor 0.5.3 | CodeEditor (no version number) | Scribunto (no version number, luastandalone), with Lua 5.1.5 and $wgScribuntoUseCodeEditor = true. I have tried playing with the order of the settings, to no avail. CodeEditor is working fine on JavaScript and CSS pages and so is WikiEditor.

Got it. An older extension I was using interfered with Scribunto because it neglected to abort the hook (it returned true). I removed it and CodeEditor works again.

Hi all. I am trying to debug some Scribunto modules but the log journal is not displayed when an error occurs.

As a consequence, you only get the details when everything goes right... and '''no''' details when it goes wrong.

This is frustrating and the opposite of what I expect.

Do you mean the red "Script error" error messages that get displayed on wiki pages? You can click on those, and they will give you more details of what went wrong.

Sorry I was not specific enough.

In the debugging console, when an error occurs, it displays the error and the call stack but '''not''' the log buffer where all the mw.log and mw.logObject messages are stored.