Extension talk:Scribunto

• 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

Previous page history was archived for backup purposes at Extension talk:Scribunto/LQT Archive 1 on 2015-06-10.

This message is occurring no matter what I do. I've made sure that the path is indeed correct, and it is. This is my LocalSettings.php:

$wgScribuntoEngineConf['luastandalone']['luaPath'] = 'C:\xampp\htdocs\w\extensions\Scribunto\includes\engines\LuaStandalone\binaries\lua5_1_5_Win64_bin\lua5.1.exe';

I can't find anything wrong with this, and I can't find anything else by myself, so I'm asking for help. Any ideas?

I'm reaching out to seek assistance with a persistent issue I'm encountering on my MediaWiki installation. I have been experiencing a Lua error with the following message: "Internal error: The interpreter exited with status 1." Despite reinstalling Scribunto, allowing necessary permissions, and confirming the functionality of my Lua 5.1 interpreter through the command line, I have been unable to resolve the issue. The debug logs haven't provided much helpful information, and I couldn't find any specific errors related to this problem.

Let us talk about this template that invokes Module:anagrammes to display its content. It is used in page such as Modèle:anagrammes/fr/cehin. Is there a way to retrieve the full page name (i.e. Modèle:anagrammes/fr/cehin in the previous example) in order to used it in "Module:anagramme"? Something like frame:getParentTitle. Thanks in advance for your advice.

@Pamputt Sure, you can look up the page object, the way en:Module:Namespace detect does:

function p.getPageObject(page)
	-- Get the page object, passing the function through pcall in case of
	-- errors, e.g. being over the expensive function count limit.
	if page then
		local success, pageObject = pcall(mw.title.new, page)
		if success then
			return pageObject
		else
			return nil
		end
	else
		return mw.title.getCurrentTitle()
	end
end

Though, for your purposes, just calling mw.title.getCurrentTitle() alone might be enough.

@Pamputt I may have misunderstood your question, I'm realizing. But you could do something like this:

local parent_title
local parent = frame:getParent()
if parent ~= nil then
  parent_title = parent:getTitle()
end

...Does that help any?

Thank you very much for your replies. Sadly, it does not solve our problem.

Actually, we have implemented a solution that uses a parameter. Our goal was to get the full title (i.e. Modèle:anagrammes/fr/cehin) in order to extract the language code (i.e. "fr" in this case). It means that when Template:anagrammes is called via Module:anagrammes, its full name is retrievable in Module:anagrammes.

Only the title of the page directly invoking the module (i.e. Modèle:anagrammes) and the module title can be queried in Scribunto (in addition to the current page title using mw.title.getCurrentTitle()). I’m not even sure if it’s possible to get arbitrary ancestor frames in the MediaWiki parser.

If I understand this correctly, I would also like being able to get arbitrary ancestror frames and I hope the developers implement it at some point.

In my case, there is a template A which calls a template B which calls a module C. I want to access from Module:C the parameters fed to Template:A, just like frame:getParent() accesses the parameters fed to Template:B.

Like Tacsipacsi, I'm not even sure that's possible. What's more, I think it would actually be a very bad idea to implement anything like that, as it would just encourage brittle code.

Building assumptions about Template:A into Module:C is just too fragile, IMHO. It means that you have to write a lot of extra conditional code in Module:C so that it won't break in cases where it's called from any context other than Template:B inside Template:A, for one thing. Good encapsulation and self-contained, modular code would discourage any sort of assumptions of context — if your Module:C needs some piece of information about the calling context, then that information should be passed in to it as one of its arguments.

If Template:A has three parameters, then Template:B can have five, three of which can be {{{1}}} {{{2}}} and {{{3}}} (or the named equivalents). And then all five (potentially) can be passed in with the invocation of any methods from Module:C. That keeps the code far cleaner than having Module:C root around in its parents' closets for information it wasn't given. Again, purely IMHO.

In practice, Template:B is {{Wikidata}}, french Wikipedia's main template for direct Wikidata calls (the native syntax {{#property:}} is discouraged). Module:C is Interface Wikidata which then calls other modules. Template:A can be plenty of large templates, typically infoboxes, with a large number of calls to {{Wikidata}} (example: {{Infobox Société}}).

The parameter of such templates that I want to access is wikidata, which would be either a Qindex, to customize which Wikidata item the data is imported from (especially useful on test pages), or - to disable the call to Wikidata. This syntax is already in place for other infobox templates which are built by invoking directly a Lua module, where their parameters are accessed via frame:getParent(). {{Wikidata}} has a parameter entity which also works this way.

This means that there is a straightforward solution which is manually adding | entity = {{{wikidata|}}} inside all the calls to {{Wikidata}} of the infobox templates. This is conceptually simple but results in bloated, harder to read code because there are very frequent calls to {{Wikidata}} inside each template. It also takes work to do this in all the wikidata calls of all the templates.

In contrast, accessing the parameter directly at Module:Interface Wikidata would require very little code if it were possible. The module does not need the parameter wikidata (or entity from {{Wikidata}}) to operate: if it is not supplied it just targets the wikidata item which is linked to the current page.

Hi!

Recently I upgraded mediawiki from 1.39.1 to 1.39.3. Initially there was no problems but Now I'm getting this error on most of my pages:

Error: Call to undefined function MediaWiki\Extension\Scribunto\Engines\LuaStandalone\shell_exec()

Backtrace:

from /home/escforumwiki/public_html/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php(89)

#0 /home/escforumwiki/public_html/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php(49): MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneEngine->getClockTick()

#1 /home/escforumwiki/public_html/extensions/Scribunto/includes/Hooks.php(305): MediaWiki\Extension\Scribunto\Engines\LuaStandalone\LuaStandaloneEngine->reportLimitData(ParserOutput)

#2 /home/escforumwiki/public_html/includes/HookContainer/HookContainer.php(338): MediaWiki\Extension\Scribunto\Hooks::reportLimitData(Parser, ParserOutput)

#3 /home/escforumwiki/public_html/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)

#4 /home/escforumwiki/public_html/includes/HookContainer/HookRunner.php(2946): MediaWiki\HookContainer\HookContainer->run(string, array)

#5 /home/escforumwiki/public_html/includes/parser/Parser.php(828): MediaWiki\HookContainer\HookRunner->onParserLimitReportPrepare(Parser, ParserOutput)

#6 /home/escforumwiki/public_html/includes/parser/Parser.php(767): Parser->makeLimitReport()

#7 /home/escforumwiki/public_html/includes/content/WikitextContentHandler.php(301): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)

#8 /home/escforumwiki/public_html/includes/content/ContentHandler.php(1721): WikitextContentHandler->fillParserOutput(WikitextContent, MediaWiki\Content\Renderer\ContentParseParams, ParserOutput)

#9 /home/escforumwiki/public_html/includes/content/Renderer/ContentRenderer.php(47): ContentHandler->getParserOutput(WikitextContent, MediaWiki\Content\Renderer\ContentParseParams)

#10 /home/escforumwiki/public_html/includes/Revision/RenderedRevision.php(266): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput(WikitextContent, Title, integer, ParserOptions, boolean)

#11 /home/escforumwiki/public_html/includes/Revision/RenderedRevision.php(237): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached(WikitextContent, boolean)

#12 /home/escforumwiki/public_html/includes/Revision/RevisionRenderer.php(221): MediaWiki\Revision\RenderedRevision->getSlotParserOutput(string, array)

#13 /home/escforumwiki/public_html/includes/Revision/RevisionRenderer.php(158): MediaWiki\Revision\RevisionRenderer->combineSlotOutput(MediaWiki\Revision\RenderedRevision, array)

#14 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}(MediaWiki\Revision\RenderedRevision, array)

#15 /home/escforumwiki/public_html/includes/Revision/RenderedRevision.php(199): call_user_func(Closure, MediaWiki\Revision\RenderedRevision, array)

#16 /home/escforumwiki/public_html/includes/poolcounter/PoolWorkArticleView.php(91): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()

#17 /home/escforumwiki/public_html/includes/poolcounter/PoolWorkArticleViewCurrent.php(97): PoolWorkArticleView->renderRevision()

#18 /home/escforumwiki/public_html/includes/poolcounter/PoolCounterWork.php(162): PoolWorkArticleViewCurrent->doWork()

#19 /home/escforumwiki/public_html/includes/page/ParserOutputAccess.php(299): PoolCounterWork->execute()

#20 /home/escforumwiki/public_html/includes/page/Article.php(714): MediaWiki\Page\ParserOutputAccess->getParserOutput(WikiPage, ParserOptions, MediaWiki\Revision\RevisionStoreCacheRecord, integer)

#21 /home/escforumwiki/public_html/includes/page/Article.php(528): Article->generateContentOutput(User, ParserOptions, integer, OutputPage, array)

#22 /home/escforumwiki/public_html/includes/actions/ViewAction.php(78): Article->view()

#23 /home/escforumwiki/public_html/includes/MediaWiki.php(542): ViewAction->show()

#24 /home/escforumwiki/public_html/includes/MediaWiki.php(322): MediaWiki->performAction(Article, Title)

#25 /home/escforumwiki/public_html/includes/MediaWiki.php(904): MediaWiki->performRequest()

#26 /home/escforumwiki/public_html/includes/MediaWiki.php(562): MediaWiki->main()

#27 /home/escforumwiki/public_html/index.php(50): MediaWiki->run()

#28 /home/escforumwiki/public_html/index.php(46): wfIndexMain()

#29 {main}

I removed this line from /LuaStandaloneEngine.php

self::$clockTick = intval( shell_exec( 'getconf CLK_TCK' ) );

All seems to work now fine, but don't know if this will not cause more problems.

I installed a new Instance of MediaWiki 1.39 on a Debian 11 server with PHP 8.2.2. I installed the Scribunto extension (and its dependencies) with Luastandalone binaries at first and it worked. A script that we would like to use seems to meant for Luasandbox, though, so I wanted to switch to Luasandbox.

I followed the instructions from Extension:Scribunto and LuaSandbox. Because the prepackaged installation with "sudo apt-get install php-luasandbox" only seems to be able to get packages for php7.4 I used the manual installation.

Following the installation php -ini lists:

luasandbox

luasandbox support => enabled

and php -m contains:

luasandbox

In the LocalSettings.php I removed the other Scribunto entries and added

$wgScribuntoDefaultEngine = 'luasandbox';

instead.

The Special:Version page continued to list Scribunto as an active extension but when a script is invoked, it failes with an Internal Error:

Fatal exception of type "Scribunto_LuaInterpreterNotFoundError"

Does anybody know why this happens or have any pointers on how to diagnose the issue further? How can I make sure Scribunto looks in the right place? (i.e. the location where I downloaded and compiled the luasandbox files as described in the installation instructions) Are there any additional log files I could check?

Wiki pages with unresolved issues relating to their use of modules are automatically added to "Category:Pages with script errors", which is quite helpful. There are, however, wiki pages in the same category that show no sign of anything being incorrect, whether in the module itself or in the way it is used. No error messages appear on the page, so how do we learn what's happening. Or are there perhaps kmown issues with false positives?

P.S. The category label is visible at the bottom of pages with visible errors but invisible on pages with invisible errors, although the latter are listed on the category page and do show the category when inspected through SMW's Special:Browse. I'm beginning to suspect that this might just be an issue with MediaWiki categories lagging behind.

I have a private wiki and while I don't have root access to the server, I do have SSH credentials which allowed me to install and set up Scribunto/Lua.* Scribunto is working most of the time, but it is on the odd occasion, probably after an edit, that I get the infamous error message:

proc_open(): open_basedir restriction in effect. File(/dev/null) is not within the allowed path(s): [...] in [...]/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php on line 154

The error reports I found all point to basic installation issues (forgetting to chmod stuff, not having access to SSH, etc.), but in my case, the error message is both sporadic and temporary.

• P.S. in Plesk, I had already set open_basedir to {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/dev/null{:}/bin/bash

Is there any way to generate an equivalent to Special:WantedTemplates to show missing modules?

I thought S:WantedTemplates already listed modules, but after testing, much to my surprise it does not. It looks like the relevant Phab ticket is phab:T104002.

I'm surprised that would even work, with Modules. A missing module results in a Script error: No such module... message from Scribunto, not a redlink. (Redlinks are how the other "Wanted ..." lists get populated.)

I'd have expected the issue to be that Scribunto itself needs to track missing modules. After all, {{#invoke:}} will never be missing as long as Scribunto itself is installed. But, maybe it already knows how to track those script failures as "module redlinks".

Yes, it does and should track script failures as redlinks – treating them as readlinks ensures that the script failures go away once the module is created, otherwise the parse result with the script error could get stuck in the cache.

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

Hello ! I just started to use Scribunto, but when I wanted to copy/paste a code from Wikipédia, I got this error, and I can't do anything on Module. So my infobox keep having errors.

I work on 1.35.7, and have PHP 7.4 activated. I don't use SyntaxHighlight or CodeEditor.

Error "-129" isn't one of the documented known error codes, so more detailed information will likely be needed about your setup. Please post details on your MediaWiki platform (OS/distro, web server platform, etc.), how and where you installed Scribunto, what type of Lua interpreter you are using and where/how it was installed, and provide the full text of everything you added or changed in LocalSettings.php when configuring Scribunto.

I'm back. (Sorry for that late answer, got a lot of work recently).

1)So, first things first. I'm using OVH (French web provider), ans I assume that they us Linux for their servers. I don't know how to get this information.

2)I have installed Scribunto with MediaWiki 1.35.7, that I put, in a specific file (My server is used first for a website, not for the wiki). So, the way is :

/www/wiki/extensions/Scribunto

There, is all the files from Scribunto.

3)I have modified several things. Because I didn't know what to do, for Scribunto to work. Here's the code from my LocalSettings.php :

wfLoadExtension( 'Scribunto' ); $wgScribuntoDefaultEngine = 'luastandalone'; $wgScribuntoEngineConf['luastandalone']['errorFile'] = ' /home/hirderr/www/wiki/extensions/Scribunto/file.txt';

I only have change $wgScribuntoDefaultEngine = 'luastandalone'; from 'luastandalone' to 'luasandbox' once, to see if there was any change. Nothing change.

I can also say that I have given chmod to the files who needs it, and from that, the extension was load, and able to write, but, I still can't use it.

4)I also have this that comes to all my website pages : Warning: proc_open( /home/hirderr/www/wiki/extensions/Scribunto/file.txt): failed to open stream: No such file or directory in /home/hirderr/www/wiki/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneInterpreter.php on line 153

@HirderWiki: OK, thanks, that looks like helpful information. Let's see:

• For #3, changing to $wgScribuntoDefaultEngine = 'luasandbox' won't actually work unless the Lua extension is also installed in the server's PHP interpreter, it's completely separate from the standalone Lua binaries shipped with Scribunto. It's often more convenient on Windows to install a PHP extension, vs. getting the webserver to run an external binary. But on Linux, there's not usually much advantage. And if you don't have the ability/permissions to install PHP extensions, luasandbox is of no use at all.

• #4 actually may be a good sign, as it seems PHP is trying to launch the Lua binary, but failing when it can't access (or, probably, can't create) the errorFile.
  
  (Note that the rest of my response will assume you have command-line (shell) access to the server, since you mentioned using chmod on files. Hopefully that's the case, or this gets harder.)
  
  It's very possible the path you listed above isn't writable by the webserver process. (And probably shouldn't be. It's usually a good idea for the webserver to have read-only access to content files, to prevent remote-exploit attacks that rely on the server modifying its own inputs.) So, you may need to change the errorFile path to a location that's writable by the server.
  
  Honestly, I'd probably start by using some location that allows mostly-unrestricted write access, like /tmp/ or /var/tmp/. Unless it's really locked down, your webserver probably has permission to create a file like /var/tmp/lua_errors.txt, so it's simplest to try using that path (or similar) for the errorFile location.
  
  Otherwise, the errorFile needs to be in some directory with either the owner or group matching the webserver process, where write permission is also set for that user/group. If they're running Apache as the server, you can use ps -ef |grep httpd to find out the process owner. (First column, ignoring the first instance that's owned by root.) If they're running some other server, the process name probably won't be httpd so you'll get no results. You could also try removing the errorFile configuration entirely (with no other changes), just to see if perhaps it's the only thing preventing your server from executing the Lua binary. You won't get Lua errors logged, if there are any, but you can at least see if you're hitting any additional PHP errors. (Lua errors tend to be surprisingly uninformative, anyway, to the extent that the errorFile is nearly useless in practice.

Thanks for the answer !

So, I've erased the line about the error file, because that wasn't helping at all. I also gave permissions to all folders of Scribunto. I gave them a 777, to be sure that it is not that. I've try then to upload Lua, and I got the same error. Erreur : Erreur Lua : erreur interne : l’interpréteur s’est arrêté avec le signal « -129 ».

In English, that can be translated in :

Error : Lua Error : Internal Error : The interpreter stoped with the signal "-129"

That's all I have actually.

Ah, OK! It turns out the exit code is calculated by the extension, which subtracts 128 from the value under certain circumstances. So, this is really a -1 exit condition.

Some possibilities:

1. proc_open is unavailable in your PHP implementation
2. The webserver doesn't permit execution of programs from the MediaWiki extension directory
3. The Linux server uses SELinux, which doesn't permit the owner of the server process to execute binaries unless they have a certain file context.

Did I ever ask what OS the server is running? The contents of /etc/system-release and the output of uname -a run from a shell would be the most informative. For example, on my Fedora systems I get:

$ uname -a
Linux (__hostname__) 5.19.13-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Oct 4 15:42:43 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/system-release
Fedora release 36 (Thirty Six)

If proc_open is restricted, it should appear in the disable_functions list of the php.ini for the server. (Possibly /etc/php.ini, or a file in /etc/php.d/.) If you have access to modify that configuration and can unrestrict it, that may let luastandalone run.

If SELinux is involved, the command getenforce will (a) exist, and (b) return "Enforcing". If the command is not found, then SELinux isn't a worry.

There may also be more helpful error messages in the webserver's error log, or the system journal/logs. But tracking those down is highly dependent on the OS and webserver used.

I've look everywhere in my option, but it is impossible for me to know winch OS is running on my servers. Even when I try to contact OVH to ask for it, then don't respond.

Create a PHP file with this content:

<?php phpinfo(); ?>

and open in your browser. The first line of the table (System) should display the same info uname -a would if you had shell access. (You could use php_uname as well, but phpinfo provides much more information, some of which may be useful for further debugging.)

After getting the required information, I suggest you to delete the file so that others are unlikely to see it, as all the system information provided by phpinfo may help hackers to do targeted attacks based on the software you actually use or your PHP configuration.

Here what I got under System :

Linux (hostname) 4.14.253-ovh-vps-grsec-zfs-classid #1 SMP Thu Oct 28 11:15:35 CEST 2021 x86_64

UPDATE : Finaly installed SyntaxHighlight and CodeEditor. Nothing change. I delete Sribunto from my extension files, and reupload it. Nothing change. I try to activate the error log file. I can't do it, i don't know why. When i try to add a Module page, even an empty one, the log file can be found, even when i clearly specify the way /home/hirderr/www/wiki/extensions/Scribunto/file.txt. Not sure if i have to it in .txt ...

Please, help.

One of the most important things you can check: If you go to your wiki's Special:Version, in the first table under "Installed Software" do you see either a "Lua" or "LuaSandbox" version listed? Unless you have that, Scribunto won't be able to access the Lua interpreter required to run any Module code. (For that matter, can you confirm that "Scribunto" is listed in the "Installed Extensions" table farther down, under "Parser Hooks"?)

I can confirm that Scribunto is indeed installed. And I can also confirmed that Lua is listed under "Installed Software". It is in use of version 5.1.5.