Extension talk:Scribunto

About this board

  • This page uses "Structured Discussions".
  • It has most recently started discussions at the top.
  • The page loads dynamically, meaning you can't tell how much more you will see when you scroll down

Two questions about parsing

Rand(1,2022) (talkcontribs)

Question moved from the Lua manual talk page

Dear community, I have two questions, which are about parsing on both the input and output side of using #invoke:

- Is there a way to pass content as an argument to "invoke" without having it parsed first? From what I read I suspect not but I may have overlooked something. For instance, I tried to write a Lua equivalent to Page Forms's #arraymap parser function, but ended up creating one that would only accept a 'masked' version of wiki syntax.

- Is there a way to output content from a module leaving it unparsed so that, for instance, it can be passed to/reused by other parser functions? Something similar to using a parser function with the appropriate ishtml/noparse settings. (I know there's another way, which is to call those other parser functions within Lua, but that's not quite what I'm asking)

Rand(1,2022) (talkcontribs)

In the meantime, I found that the answer to both these questions is yes and that <code>mw.text.nowiki</code> is what provides the solution.

Reply to "Two questions about parsing"
BoldLuis (talkcontribs)

Is there any logo for Scribunto, from Wikimedia Commons, to include in the page?

FeRDNYC (talkcontribs)
Reply to "Logo"

Error running LuaStandalone on Windows

GerardNL3 (talkcontribs)

(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):


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";


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

FeRDNYC (talkcontribs)

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


[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?)

Raikkonso (talkcontribs)

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?

Lonepointe (talkcontribs)

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) (talkcontribs)

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.


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.

Raikkonso (talkcontribs)

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

FeRDNYC (talkcontribs)

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?

Anoneedes (talkcontribs)

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?

FeRDNYC (talkcontribs)

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?

Tacsipacsi (talkcontribs)

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.

Tacsipacsi (talkcontribs)

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.

FeRDNYC (talkcontribs)

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

FeRDNYC (talkcontribs)

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:


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.

FeRDNYC (talkcontribs)

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

Ketho (talkcontribs)
FeRDNYC (talkcontribs)

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

FeRDNYC (talkcontribs)

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.

Mwgbell (talkcontribs)

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)

Chubbuck3 (talkcontribs)

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

FeRDNYC (talkcontribs)

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

Mindroastermeer (talkcontribs)

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.


Reply to "Error running LuaStandalone on Windows"

Is that possible to get raw wikitext by Lua?

Cirno.Tim (talkcontribs)

I find out frame.args will receive parsed wikitext, so how to get raw wikitext without using <nowiki> tag?

Mr. Stradivarius (talkcontribs)

You can get the unparsed wikitext of an entire page using title:getContent(). I don't think there's a way to get unparsed wikitext of just the template arguments.

Tacsipacsi (talkcontribs)

It’s definitely impossible at the moment, and I don’t even think it would be possible at all to implement it in Scribunto: by design, the MediaWiki parser only allows getting expanded (parsed) contents of template/parser function arguments.

FeRDNYC (talkcontribs)

If you think about it, it's kind of a logistical impossibility — how can a module possibly ask the parser to supply anything without first... well... parsing it? The wikitext containing the {{#invoke:... }} has to be parsed for the interpreter to even identify that a Lua module is being called; which one, specifically; and how the remainder of the text up to the closing }} represents any arguments to the call.

The <nowiki>...</nowiki> feature exists specifically because that IS the method of telling the parser, "hands off this chunk of content, I want it to be preserved in an unparsed state as it moves through the parse tree" — or to put it another way, to "get raw wikitext". Without those tags, you're gonna get the results of the parser doing its job on whatever it finds.

It'd require direct modifications to the wikitext parser itself, for it to also store and make available the unparsed version of the child content at each node in the parse tree without needing to use <nowiki>...</nowiki>.

Reply to "Is that possible to get raw wikitext by Lua?"

Can Scribunto do anything for the client other than generate static text?

Ham Pastrami (talkcontribs)

I was looking for scripting capabilities along the lines of client-side dynamics, with the ability to change its own generated text on the fly. I understood that there would be limits to functionality for security reasons, but it seems like Scribunto can't actually do anything above and beyond what could be done with ParserFunctions, which is to generate some text on page load. Am I missing something or is that really all it does?

Dinoguy1000 (talkcontribs)

That is really all it does. If you need reader-facing dynamic content you'll need to look at Javascript (though you might end up using Scribunto to generate the page structures that the JS makes dynamic).

FeRDNYC (talkcontribs)

To be fair, when browsing the web, "generat[ing] some text on page load" is how everything is done. Any functionality provided by a web service is the result of the particular HTML source payload (AKA "some text") that the server sends back in response to a client request.

Granted, Scribunto doesn't have access to even a fraction of that power, since it can't inject arbitrary code into the response, or cause anything to be run on the client side. For very good reason: A truly dynamic page, one where the content depends on the requesting client in any way, wouldn't be cacheable. Keep in mind that the primary focus for Scribunto has always been to script the process of generating-to-cached-static-content for high-volume sites like the various Wikipediae. If the Module code that generates an article's content had to be executed in full each and every time the page is requested, the added server load would take those sites down almost instantly.

It's not really true that Scribunto adds nothing over ParserFunctions, though. Primarily, with Scribunto you have access to real looping and recursion, meaning that you're no longer limited to a fixed set of template parameters that all have to be processed explicitly. Instead, you can just loop over the parameter list until you reach the end. One of the first things people used Modules for was to replace all of these tedious templates:

{{#if: {{{1|}}}|Handle {{{1}}}
}}{{#if: {{{2|}}}|Handle {{{2}}}
}}{{#if: {{{3|}}}|Handle {{{3}}}

...with module implementations that only have to write the "Handle {{{n}}}" part once, and can loop over an arbitrary number of parameters instead of being hard-limited to however many times the template author replicated the code for incrementally higher parameter IDs.

(And it works just as well with named parameters. Thanks to en:Module:Citation/CS1, Wikipedia's {{cite web}} and friends now technically support an infinite-length set of |lastn=, |firstn= parameters for author names (limited only by the Lua process' memory constraints). They're processed iteratively, the code just keeps incrementing the n value and checking parameters until it sees two consecutive n values where |lastn= and |firstn= are both undefined, at which point it decides it's finished and breaks out of the loop.

(It also collects the values from all of the author parameters it does find, and stores the entire (sanitized and homogenized) list of authors as a Lua table. So, once it's done a single pass over all of the separate parameters, the data's stored in a structured form that can be passed between functions and easily dereferenced as needed. It never accesses the original |lastn=, |firstn= parameter values past that point.)

ParserFunctions can do a lot, but they can't do anything that requires storing data or keeping state across multiple invocations. Lua brings quite a bit to the table, even if its scripting is still limited to server-side content generation.

Dinoguy1000 (talkcontribs)

This is technically true*, but it's also almost completely unrelated to the problem Ham Pastrami is trying to solve.

* Except for Lua keeping state across invocations; page-global statefulness is not intended and is always removed when someone finds a way to do it, since it would break the linear parsing model that Parsoid is moving to.

FeRDNYC (talkcontribs)

@Dinoguy1000: Yeah, sorry, I worded that badly. I wasn't talking about Lua preserving state across Module invocations, only within them. A Lua script's internal storage/state represents the "moral equivalent" of state being preserved across ParserFunction invocations, since a single Lua call can generally replace an entire template packed with dozens or even hundreds of separate ParserFunctions (all of which were completely isolated and had no ability to share state).

...I still feel like I'm not wording that great, but hopefully it's at least better.

Dinoguy1000 (talkcontribs)

Aah, yeah, that makes more sense.

Novem Linguae (talkcontribs)

it seems like Scribunto can't actually do anything above and beyond what could be done with ParserFunctions, which is to generate some text on page load. In my opinion, Scribunto's purpose on Wikipedia is to provide a way to organize template logic code like actual program code, instead of a bunch of un-indented spaghetti. Anytime a template starts getting complicated, I am always tempted to re-write it in Lua. It is much more readable and maintainable. Hope this helps to explain its purpose.

Reply to "Can Scribunto do anything for the client other than generate static text?"

Script error: Lua error: Internal error: The interpreter has terminated with signal "-129".

Marcellinjobard (talkcontribs)

Hello ! On a mediawiki installed on web host (https://www.ovhcloud.com/en-gb/web-hosting/professional-offer/ ) I have this error when i try to open Module or Template using modules.

this is my specs :

Produit Version
MediaWiki 1.39.3
PHP 7.4.33 (fpm-fcgi)
MySQL 5.7.42-log
ICU 63.1
Lua 5.1.5

according to Extension:Scribunto :

  • pcre: 10.35 2020-05-09 (>8.33)
  • pcntl: no (but not "requirement removed in Scribunto for MediaWiki 1.29.")
  • mbstring: yes
  • `function_exists("proc_open")` on php file retruns `true`
  • `$wgScribuntoDefaultEngine = 'luastandalone';` on LocalSettings.php
  • I did `chmod 755 /path/to/extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/lua` on ssh (because `uname -m` returns `x86_64`)
  • `uname -r` returns `5.15.80-ovh-vps-grsec-zfs-classid`

does anyone have any idea where this might come from? Is it coming from the web hosting environment? How to test if Lua can be executed on the server? (I tried a simple "./lua" and it gives "segmentation fault")

FeRDNYC (talkcontribs)


I tried a simple "./lua" and it gives "segmentation fault"

Well, that's probably a bad sign, as it should start an interactive lua session, displaying a > prompt and waiting for input. If it's crashing when you run it from a shell, there's a good chance it's crashing when PHP tries to run it too. But as to why it's crashing... tricky to say.

Some things you can try (assuming your current directory is .../extensions/Scribunto/includes/engines/LuaStandalone/binaries/lua5_1_5_linux_64_generic/):

  1. It's possible the crash is only in the interactive interpreter; perhaps it's having trouble accessing the terminal for some reason. In that case, executing a lua statement defined in the arguments might have a different outcome. Here's a simple one you can try:
    ./lua -e 'print(math.pi)'
    On my system that outputs 3.1415926535898.
  2. If that also segfaults, and ldd is available in the environment, you can check what libraries the dynamic loader is resolving for the binary. But its dependencies are pretty minimal, and unlikely not to be met. On my Fedora 38 system:
    $ ldd ./lua
     linux-vdso.so.1 (0x00007ffced7d1000)
     libm.so.6 => /lib64/libm.so.6 (0x00007f4bb40dd000)
     libc.so.6 => /lib64/libc.so.6 (0x00007f4bb3c22000)
     /lib64/ld-linux-x86-64.so.2 (0x00007f4bb4206000)
  3. If gdb is available, you could run the binary in the debugger, so you'd at least get a stack trace when it segfaults. To do that, you'd:
    # Run the debugger and load the lua binary
    $ gdb ./lua
    # When you get a '(gdb)' prompt, gdb is waiting for debugger commands
    # First, run that same math.pi test
    (gdb) run -e 'print(math.pi)'
    # When the program segfaults and drops you back to the debugger again,
    # collect a stack trace
    (gdb) bt

Unfortunately, you won't have any debugging symbols loaded, so that stack trace is going to be pretty incomprehensible. Still, it might at least give us a hint of whether the crash is occurring on a lua binary instruction, or if it's something deeper down inside one of the system libraries.

Reply to "Script error: Lua error: Internal error: The interpreter has terminated with signal "-129"."

Vote for LuaSandbox on Plesk

Rand(1,2022) (talkcontribs)

Apologies for cross-posting

For anyone who is on Plesk hosting, or considering to move to Plesk, and is sad to miss out on all the wonderfulness that is Lua because of shared hosting restrictions and what not, don't give up but please vote for the following feature request:


Lua/Scribunto is not only incredibly useful, but may become one of few viable alternatives when Parsoid has made the move to parallel parsing and extensions like Variables and Arrays are no longer guaranteed to work.

Let's not 'miss the boat' and please make your voice heard.

Reply to "Vote for LuaSandbox on Plesk"

LogicException: This ParserOutput contains no text!

Marx.FelipeForte (talkcontribs)

In our MediaWiki instance, Scribunto runs fine. The problem is when the code is displayed through SyntaxHighlight. The internal error in the topic title appears on the page for every Lua module. This problem began once MediaWiki was updated to 1.39.3.

Partial backtrace:

from /var/www/prole/includes/parser/ParserOutput.php(363)

#0 /var/www/prole/extensions/Scribunto/includes/ScribuntoContentHandler.php(224): ParserOutput->getRawText()

#1 /var/www/prole/extensions/Scribunto/includes/ScribuntoContentHandler.php(193): MediaWiki\Extension\Scribunto\ScribuntoContentHandler->highlight()

Context of MediaWiki's ParserOutput.php (361–367):

public function getRawText() {
	if ( $this->mText === null ) {
		throw new LogicException( 'This ParserOutput contains no text!' );
	return $this->mText;

Context of includes/ScribuntoContentHandler.php (212–230, without comments):

protected function highlight( $text, ParserOutput $parserOutput, ScribuntoEngineBase $engine ) {
	global $wgScribuntoUseGeSHi;
	$language = $engine->getGeSHiLanguage();
	if (
		$wgScribuntoUseGeSHi && $language && ExtensionRegistry::getInstance()->isLoaded( 'SyntaxHighlight' )
	) {
		$status = SyntaxHighlight::highlight( $text, $language, [ 'line' => true, 'linelinks' => 'L' ] );
        	if ( $status->isGood() ) {
		$parserOutput->addModules( ['ext.pygments.linenumbers'] );
		$parserOutput->setText( $parserOutput->getRawText() . $status->getValue() );
		return true;
        return false;

Also, our MediaWiki instance runs multiples languages. For some odd reason, this problem only happens on the English instance.

Reply to "LogicException: This ParserOutput contains no text!"

Lua Error: Internal error: the interpreter exited with status 1 on infobox

Chubbuck3 (talkcontribs)

I'm using Windows, and I am having this error. When I setup the log file, I saw that the error was that apparently the directory where Lua is installed cannot be found.

I've searched around. Anyone have any leads?

Reply to "Lua Error: Internal error: the interpreter exited with status 1 on infobox"

Lua error: Internal error: The interpreter exited with status 1. on infobox

8 (talkcontribs)

hi i was making it but i get error Lua error: Internal error: The interpreter exited with status 1. on infobox and i am using windows when i looked at the internet they are not helpful how do i fix this crap?

Keyacom (talkcontribs)

The fact you're using Windows aides me in giving help. There should be a line that says:

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

in this extension's /includes/engines/LuaStandalone/LuaStandaloneInterpreter.php. For the extension to work, comment out the line (i.e. prepend # or //). (talkcontribs)

yes i went to the line but its only

(string)( $options['cpuLimit'] + 1 ), (talkcontribs)

oh there is (talkcontribs)

nope still did not (talkcontribs)

infobox took long to load (talkcontribs)


but need some templates

( ͡° ͜ʖ ͡°)

Chubbuck3 (talkcontribs)

how did you get this to work? I have the same issue.

Reply to "Lua error: Internal error: The interpreter exited with status 1. on infobox"