Quite simply I'd like to print out all variables that are in scope in my genshi template, as a debugging and discovery measure. Is there a way to do it?
The standard Python function locals() (which returns a dict) works for me. I'm using Genshi 0.5.1, and as you'll see, everything seems to be in __data__.
${repr(locals())}
Related
In python, there is a common construction of the form if __name__ == "__main__": to detect whether the file was imported or executed directly. Usually, the only action taken in this conditional is to execute some "sensible, top level" function. This allows the same file to be used as a basic script and as a library module (and also as something an interactive user can import and use).
I was wondering if there is a clean and reliable way to do this in lua. I thought I could use the _REQUIREDNAME global variable, but it turns out that this was changed in Lua 5.1. Currently, the lua require passes arguments (in the variadic ...), so in principle, these can be examined. However, this is either not reliable, not clean, or probably both, because obviously when a script is executed arguments can be passed. So to do this safely, you would have to examine the arguments.
FWIW, require passes the module name as argument 1 (the string you called require on), and the path to the file it eventually found as argument 2. So there is a obviously some examination that can be done to try to detect this, which if not nearly as nice as if __name__ == "__main__": and can always be bypassed by a user by passing two suitably constructed arguments to the script. Not exactly a security threat, but I would hope there is a better solution.
I also experimented with another method, which I found very ugly but promising. This was to use debug.traceack(). If the script is executed directly, the traceback is very predictable, in fact, it only has 3 lines. I thought this might be it, although, like I said, an ugly hack for sure.
Do any more frequent lua users have advice? In effect, if I am writing module X, I want to either return X.main_func() in script mode or return X in import mode.
EDIT:
I took out an item which was actually incorrect (and makes my traceback solution workable). Additionally, the link provided in the comment by Egor Skriptunoff did provide another trick from the debug library which is even cleaner than using the traceback. Other than that, it seems that everyone ran into the same issues as me and the lua team has been disinterested in providing an official means to support this.
Based on the links provided by Egor, the current cleanest and safest way to do this seems to be as outlined here:
How to determine whether my code is running in a lua module?
which I repeat for ease of reference:
if pcall(debug.getlocal, 4, 1) then
print("in package")
else
print("in main script")
end
There is a whole thread about it here:
http://lua.2524044.n2.nabble.com/Modules-with-standalone-main-program-td7681497.html
Like I said, it seems this is a popular feature which is going to remain unsupported for the time being, but the debug.getlocal method seems to be what common lua developers have settled on for now.
A require() returning in package.loaded.
So simply check package.loaded for what you want.
Also as a good start for more experience in that methodic i suggest to write package.preload functions for require() stuff without manipulating the path.
A simple example for showing this...
# /usr/local/bin/lua -i
Lua 5.4.3 Copyright (C) 1994-2021 Lua.org, PUC-Rio
> package.preload.mymod=function() return {dump=function(...)
>> local args={...}
>> local test,dump=pcall(assert,args[1])
>> if test then
>> for key,value in pairs(dump) do
>> io.write(string.format("%s=%s\n",key,value)):flush()
>> end
>> return true
>> else
>> return test,dump
>> end
>> end} end
> mymod=require('mymod')
> mymod.dump(package.loaded)
string=table: 0x56693590
mymod=table: 0x566aa890
utf8=table: 0x56694d80
package=table: 0x56691ed0
math=table: 0x56693cb0
table=table: 0x566920d0
_G=table: 0x56690730
debug=table: 0x566950e0
coroutine=table: 0x56692310
os=table: 0x56692e60
io=table: 0x566921b0
true
I obfuscated this script using some site
But i'm wondering how to deobfuscate it? can someone help me?
i tried using most decompilers and a lot of ways but none has worked
local howtoDEOBFUSCATEthis_Illll='2d2d341be85c64062f4287f90df25edffd08ec003b5d9491e1db542a356f64a488a1015c2a6b6d4596f2fa74fd602d30b0ecb05f4d768cd9b54d8463b39729eb1fe84630c0f8983f1a0087681fe4f2b322450ce07b
something like that for an example.
the whole script: https://pastebin.com/raw/fDGKYrH7
First reformat into a sane layout. a newline before every local and end will do a lot. Then indenting the functions that become visible is pretty easy.
After that use search replace to inline constants. For example: local howtoDEOBFUSCATEthis_IlIlIIlIlIlI=8480; means you can replace every howtoDEOBFUSCATEthis_IlIlIIlIlIlI with 8480. Though be careful about assignments to it. If there are any then it's better to rename the variable something sensible.
If an identifier has no match you can delete the statement.
Eventually you get to functions that are actually used.
Looking at the code it seems to be an interpreter implementation. I believe it's a lua interpreter
Which means that you'll need to verify that and decompile what the interpreter executes.
I am writing my first wireshark dissector. I am writing it in Lua, using this as an example. On the second page it says that I can use functions like critical(), warn(), debug() to help debug the code. However, when I add even the simplest
critical("foo")
wireshark complains that
attempt to call global 'critical' (a nil value)
I can't seem to figure out how to use these utility functions. What am I missing?
UPDATE: In case it is relevant, I am running Wireshark 3.0.0
I made that tutorial.
It looks like the logging functions were removed from Wireshark in 3.0 (release notes):
Lua: the various logging functions (debug, info, message, warn and critical) have been removed. Use the print function instead for
debugging purposes.
So use print() instead:
print("foo")
I'm trying to internationalize / translate a python app that is implemented as a wx.App(). I have things working for the most part -- I see translations in the right places. But there's a show-stopper bug: crashing at hard-to-predict times with errors like:
Traceback: ...
self.SetStatusText(_('text to be translated here'))
TypeError: 'numpy.ndarray' object is not callable
I suspect that one or more of the app's dependencies (there are quite a few) is clobbering the global translation function, _( ). One likely way would be doing so by using _ as the name of a dummy var when unpacking a tuple (which is fairly widespread practice). I made sure its not my app that is doing this, so I suspect its a dependency that is. Is there some way to "defend" against this, or otherwise deal with the issue?
I suspect this is a common situation, and so people have worked out how to handle it properly. Otherwise, I'll go with something like using a nonstandard name, such as _translate, instead of _. I think this would work, but be more verbose and a little harder to read., e.e.,
From the above I can not see what is going wrong.
Don't have issues with I18N in my wxPython application I do use matplotlib and numpy in it (not extensive).
Can you give the full traceback and/or a small runnable sample which shows the problem.
BTW, have you seen this page in the wxPython Phoenix doc which gives some other references at the end.
wxpython.org/Phoenix/docs/html/internationalization.html
Aha, if Translate works then you run into the issue of Python stealing "", you can workaround that by doing this:
Install a custom displayhook to keep Python from setting the global _ (underscore) to the value of the last evaluated expression. If we don't do this, our mapping of _ to gettext can get overwritten. This is useful/needed in interactive debugging with PyShell.
you do this by defining in your App module:
def _displayHook(obj):
"""Custom display hook to prevent Python stealing '_'."""
if obj is not None:
print repr(obj)
and then in your wx.App.OnInit method do:
# work around for Python stealing "_"
sys.displayhook = _displayHook
I'm using a closed-source application that loads Lua scripts and allows some customization through modifying these scripts. Unfortunately that application is not very good at generating useful log output (all I get is 'script failed') if something goes wrong in one of the Lua scripts.
I realize that dynamic languages are pretty much resistant to static code analysis in the way C++ code can be analyzed for example.
I was hoping though, there would be a tool that runs through a Lua script and e.g. warns about variables that have not been defined in the context of a particular script.
Essentially what I'm looking for is a tool that for a script:
local a
print b
would output:
warning: script.lua(1): local 'a' is not used'
warning: script.lua(2): 'b' may not be defined'
It can only really be warnings for most things but that would still be useful! Does such a tool exist? Or maybe a Lua IDE with a feature like that build in?
Thanks, Chris
Automated static code analysis for Lua is not an easy task in general. However, for a limited set of practical problems it is quite doable.
Quick googling for "lua lint" yields these two tools: lua-checker and Lua lint.
You may want to roll your own tool for your specific needs however.
Metalua is one of the most powerful tools for static Lua code analysis. For example, please see metalint, the tool for global variable usage analysis.
Please do not hesitate to post your question on Metalua mailing list. People there are usually very helpful.
There is also lua-inspect, which is based on metalua that was already mentioned. I've integrated it into ZeroBrane Studio IDE, which generates an output very similar to what you'd expect. See this SO answer for details: https://stackoverflow.com/a/11789348/1442917.
For checking globals, see this lua-l posting. Checking locals is harder.
You need to find a parser for lua (should be available as open source) and use it to parse the script into a proper AST tree. Use that tree and a simple variable visibility tracker to find out when a variable is or isn't defined.
Usually the scoping rules are simple:
start with the top AST node and an empty scope
item look at the child statements for that node. Every variable declaration should be added in the current scope.
if a new scope is starting (for example via a { operator) create a new variable scope inheriting the variables in the current scope).
when a scope is ending (for example via } ) remove the current child variable scope and return to the parent.
Iterate carefully.
This will provide you with what variables are visible where inside the AST. You can use this information and if you also inspect the expressions AST nodes (read/write of variables) you can find out your information.
I just started using luacheck and it is excellent!
The first release was from 2015.