Topic on Extension talk:Scribunto/Flow

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