4.2.0: init.lua in subdirectories not loaded anymore
Summary
Switching from Wireshark 4.0.2 to 4.2, any init.lua files existing in subdirectories of the plugin folder, are not loaded anymore. This bug seems to have been introduced with the following change in v4.2: 9fb85a84 (comment 1678629848)
Steps to reproduce
Put a lua-script for example under //init.lua, and it will not be loaded in the new Wireshark version. Tested on Windows 10 x64.
What is the expected correct behavior?
Old versions used to load those "normally", i.e. like any other script, but one actually might consider to load this file first like other init.lua files tho? -> RFC
I think "true" lua behaviour actually would be, to not load other script files from that directory at all, and just run init.lua, but I'd say that's more of a future feature request.
Build information
Version 4.2.0 (v4.2.0-0-g54eedfc63953).
Compiled (64-bit) using Microsoft Visual Studio 2022 (VC++ 14.37, build 32822),
with GLib 2.78.0, with Qt 6.5.3, with libpcap, with zlib 1.3.0, with PCRE2, with
Lua 5.2.4 (with UfW patches), with GnuTLS 3.7.9 and PKCS #11 support, with
Gcrypt 1.10.2-unknown, with Kerberos (MIT), with MaxMind, with nghttp2 1.57.0,
with nghttp3 1.0.0, with brotli, with LZ4, with Zstandard, with Snappy, with
libxml2 2.11.5, with libsmi 0.5.0, with QtMultimedia, with automatic updates
using WinSparkle 0.8.0, with AirPcap, with Minizip, with binary plugins.
Running on 64-bit Windows 10 (22H2), build 19045, with Intel(R) Core(TM)
i7-10750H CPU @ 2.60GHz (with SSE4.2), with 32513 MB of physical memory, with
GLib 2.78.0, with Qt 6.5.3, with Npcap version 1.78, based on libpcap version
1.10.4, with PCRE2 10.42 2022-12-11, with c-ares 1.19.0, with GnuTLS 3.7.9, with
Gcrypt 1.10.2-unknown, with nghttp2 1.57.0, with nghttp3 1.0.0, with brotli
1.0.9, with LZ4 1.9.3, with Zstandard 1.5.2, without AirPcap, with dark display
mode, with mixed DPI, with QPA plugin "windows", with
LC_TYPE=English_Austria.utf8, binary plugins supported.
Edited by Fabian “Folfy” Fritzer