I wrote a script that collects all our log files to one tar file. The problem is that it doesn't contain soft link's data. I tried to use the dereference flag but it is not recognized for python 2.4.3.
I can't use the command line since there's a length limit and I want to support many log files.
user ~/Desktop]$python
Python 2.4.3 (#1, Jun 11 2009, 14:09:37)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
>>> import tarfile
>>> tarfile.TarFile('test.tar.gz', mode='w', dereference=True)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __init__() got an unexpected keyword argument 'dereference'
>>>
According to the Python 2.4 docs dereference = True is supported. It appears to have been supported since tarfile was added in Python 2.3.
Unless you're on a non-Posix system (Windows) you must be doing it wrong. Post your code and the error you get with dereference = True so we can tell you what that is.
Also, by soft links I assume you mean symbolic links? Because that's what dereference = True allows to work.
Edit: I just looked at the code for tarfile on Python 2.4. It does not support the dereference parameter to the constructor, but it does seem to have the needed code to actually dereference (Checked against the source for Python 2.6). So,
import tarfile
tf = tarfile.TarFile('test.tar.gz', mode='w')
tf.dereference = True
should work. Please, update with your results.
Couldn't you just use the -T or --files-from option on tar?
Related
I'm trying to run this code in vscode for a school task, but I keep getting an error of a missing file 'libc.dll' I am somewhat confused of this file since I am new to this and not sure where to look for this file...
Can someone explain to me what does this error actually mean and why I can't locate the file?
from ctypes import *
libc = CDLL("libc.dll")
libc.printf("hello everybody\n".encode('ascii'))
The error I'm getting:
Traceback (most recent call last):
File "c:\Users\User\Desktop\2-3.py", line 3, in
libc = CDLL("libc.dll")
File "C:\Users\User\AppData\Local\Programs\Python\Python311\Lib\ctypes_init_.py", line 376, in init
self._handle = _dlopen(self._name, mode)
FileNotFoundError: Could not find module 'libc.dll' (or one of its dependencies). Try using the full path with constructor syntax.
[GNU]: The GNU C Library (glibc) (if this is what your libc.dll refers to) states (emphasis is mine):
The GNU C Library project provides the core libraries for the GNU system and GNU/Linux systems, as well as many other systems that use Linux as the kernel.
So, LibC is part of Nix world (which Win is not in).
MS's equivalent is CRT (also referred to as VCRT, MSVCRT, UCRT, ...: [MS.Learn]: Microsoft C runtime library (CRT) reference).
According to [Python.docs]: ctypes - Loading dynamic link libraries (make sure to also read the notes):
Here are some examples for Windows. Note that msvcrt is the MS standard C library containing most standard C functions, and uses the cdecl calling convention.
Example:
>>> import ctypes as cts
>>> import sys
>>>
>>> sys.version
'3.10.9 (tags/v3.10.9:1dd9be6, Dec 6 2022, 20:01:21) [MSC v.1934 64 bit (AMD64)]'
>>>
>>>
>>> crt = cts.CDLL("msvcrt")
>>>
>>> crt.printf
<_FuncPtr object at 0x0000019AE5A48040>
You should also check:
[SO]: Can't import dll module in Python (#CristiFati's answer)
[SO]: C function called from Python via ctypes returns incorrect value (#CristiFati's answer) (when calling printf (or any function as a matter of fact))
Note: I also tried (a while ago) your code on Nix emulators (MSYS2, Cygwin) but they didn't work. The only thing that would work for sure is WSL2 ([MS.Learn]: Install Linux on Windows with WSL), as it has a genuine Linux kernel, but I'm not sure if that's relevant for you.
I am using remote interpreter on pycharm on WSL (configured it with this tutorial: https://www.jetbrains.com/help/pycharm/using-wsl-as-a-remote-interpreter.html)
I was able to run everything I needed successfully, but when I tried to use pwntools (https://github.com/Gallopsled/pwntools) I was able to import it successfully on the WSL bash python interpreter, but not on Pycharm.
This is what I ran:
from pwn import *
On Pycharm it was stucked and I interrupted it, this is the trace of the Exception (where it stucks):
ssh://shahar#localhost:22/usr/bin/python -u /tmp/pycharm_project_271/pwnablekr/fd.py
Traceback (most recent call last):
File "/tmp/pycharm_project_271/pwnablekr/fd.py", line 1, in <module>
from pwn import *
File "/home/shahar/.local/lib/python2.7/site-packages/pwn/__init__.py", line 6, in <module>
pwnlib.args.initialize()
File "/home/shahar/.local/lib/python2.7/site-packages/pwnlib/args.py", line 208, in initialize
term.init()
File "/home/shahar/.local/lib/python2.7/site-packages/pwnlib/term/__init__.py", line 74, in init
term.init()
File "/home/shahar/.local/lib/python2.7/site-packages/pwnlib/term/term.py", line 109, in init
c = os.read(fd.fileno(), 1)
KeyboardInterrupt
Process finished with exit code 1
enter code here
On my WSL bash it ran just fine:
shahar#MYCOMPUTERNAME:/mnt/c/Users/shahar$ python
Python 2.7.12 (default, Dec 4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pwn import *
>>>
When I looked at the piece of code where it stuck (from the trace of the Exception):
while True:
c = os.read(fd.fileno(), 1)
s += c
if c == 'R':
break
at the beginning of the script as a global variable:
fd = sys.stdout
I understood from the internet that this function (which this loop is part of it) is related to take over the terminal. Maybe it is related to the fact I am not running from terminal?
Had anyone seen this kind of problem before? has some helpful tips?
Thank you very much!
I have a potential fix as well, and it's adding a PWNLIB_NOTERM to the environment.
import os
os.environ['PWNLIB_NOTERM'] = 'True' # Configuration patch to allow pwntools to be run inside of an IDE
import pwn
Screenshot showing it runs and we get an Encoder object instance
There is another way to solve it.
If you use Pycharm , you can tick the box Run with Python console in Run configurations.
It will work in Pycharm 2020.3 with IPython.(I think it also works without IPython)
screenshot
There is no effective way, I debug it, the problem is term initialization.it may also be related to the environment variables of the TERM and TERMINFO.My solution is to modify the last line of /usr/local/lib/python2.7/dist-packages/pwnlib/args.py,delete term.init(), replace it with anything else to bypass the initialization of pwnlib.
replace this line:
debug pwntools:
I have a file: pytest.py which is one line:
print "hello world"
idle -r pytest.py
Python 2.7.9 (default, Apr 8 2015, 15:12:41)
[GCC 4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)] on freebsd10
Type "copyright", "credits" or "license()" for more information.
>>>
*** Error in script or command!
Traceback (most recent call last):
File "pytest.py", line 1
print "hello world"
^
SyntaxError: invalid syntax
>>>
running idle with no options, opening and running the file works. This is on FreeBSD 10.0 and py27-gtk2-2.24.0_3 (python binding). This stopped working at some point but I can not relate it to a specific change. All packages/port are up-to-date
Idle compiles the -r code as follows:
code = compile(source, filename, "exec")
However, by default, compile inherits the calling code's future settings:
The optional arguments flags and dont_inherit control which future statements (see PEP 236) affect the compilation of source. If neither is present (or both are zero) the code is compiled with those future statements that are in effect in the code that is calling compile()
Since idle's PyShell.py module does enable the print_function future flags, this means that by accident all of your code in -r has to use it to.
Change your code to print("Hello world") to fix the problem. As a nice side effect, your code will work in Python 3.x as well.
I caused this problem when I added
from __future__ import print_function
to the top of PyShell.py as part of backporting the bugfix in Issue 22420. The fix, which I just applied in Issue 24222, is this change to line 655.
- code = compile(source, filename, "exec")
+ code = compile(source, filename, "exec", dont_inherit=True)
Thanks to 'phihag' for pointing out the problem line.
from future import print_function
print "hello world"
gives the same result on my system
Oh poo can't use vi -- the answer was correct
I want to run snakefood (an AST-based dependency graph analyser; source code can be found here). My project has a structureinvolving several levels of Python packages, like this:
myproject
|code
|Utils
|AdaptedConfigParser
Configs_Parser.py
...
...
main.py
However, when I start running snakefood on the root directory of my project it claims that it can't find the modules from my Python package being imported:
$ sfood --internal --follow --ignore-unused ./PycharmProjects/myproject/ > ~/static_analysis.txt
WARNING : Line 9: Could not import module 'myproject.Utils.AdaptedConfigParser.Configs_parser'
I tried to get around it by adding a .pth file with the project root to the lib/python2.7/site-packages
Now when I call python with that virtual environment activated from anywhere, I can do the following:
$ python
Python 2.7.6rc1 (default, Jan 19 2014, 18:57:40)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import myproject.Utils.AdaptedConfigParser.Configs_parser
>>>
And it works just fine.
However, when snakefood is launched with that virtual environement, it still returns the same error.
$ sfood --internal --follow --ignore-unused ./PycharmProjects/myproject/ > ~/static_analysis.txt
WARNING : Line 9: Could not import module 'myproject.Utils.AdaptedConfigParser.Configs_parser'
At this point I don't even understand where the problem with imports could come from.
In addition to that, when --internal flag is taken away, it fails imports even of the python builtin module, which doesn't make any sense to me:
WARNING : Line 80: Could not import module 'builtins'
WARNING : Line 190: Could not import module 'pyamg'
Have anyone encountered such a problem previously? If yes, is there a way of getting around it?
I had similar issues, turns out the warning in my case was generated because of __all__ declarations.
e.g.
__all__ = ['abc',
'aaa',
...
]
Above code gives out the warnings:
WARNING : Line xx: Could not import module 'abc'
WARNING : Line xx: Could not import module 'aaa'
I modified the warning constant ERROR_IMPORT within snakefood\lib\python\find.py to add the name of the file where the error occurs along with the line number and module name. That way you can target the specific file and line number pretty much figure out the problem.
Hope this helps!
import itertools
print itertools#ok
the code is ok
but i can't find the itertools file.
who can tell me where is the 'itertools file'
my code is run python2.5
import itertools
print itertools.__file__
Traceback (most recent call last):
File "D:\zjm_code\mysite\zjmbooks\a.py", line 5, in <module>
print itertools.__file__
AttributeError: 'module' object has no attribute '__file__'
>>> import itertools
>>> itertools.__file__
'/usr/lib64/python2.6/lib-dynload/itertools.so'
The fact that the filename ends with .so means it's an extension module written in C (rather than a normal Python module). If you want to take a look at the source code, download the Python source and look into Modules/itertoolsmodule.c (you can also view it in your browser at http://svn.python.org/view/python/trunk/Modules/itertoolsmodule.c?view=log).
Edit (as an answer to the comment below): it also works with Python 2.5:
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import itertools
>>> itertools.__file__
'/usr/lib/python2.5/lib-dynload/itertools.so'
If you're looking for the source file (in C, of course), it's for example online here.
For the windows users (I'm running Python 2.7.2, Win7x64, default installer package) the call to __file__ will flame out as #zjm1126 has noted, I suspect the problem being that itertools is a builtin on the windows package. If you'd picked say, exceptions? You'd get the same behaviour on another platform (e.g. Python 2.6.1 on my macbook) - Windows just happens to have a few more builtins like itertools.
It's not strictly an answer as such, but you could parse sys.modules which would give you a hint as to where it's coming from:
>>> import sys
>>> sys.modules['itertools']
<module 'itertools' (built-in)>
which points at itertools being built-in to your python executable.
Also, the imp.find_module response is providing the same information: the weird return tuple is by spec (see: http://docs.python.org/2/library/imp.html#imp.find_module) and telling you that the module is of type 6, which is the enumeration for imp.C_BUILTIN
try this
>>> import imp
>>> imp.find_module("itertools")
update:
since yours is None, another go through a manual way. Do a sys.path
>>> import sys
>>> sys.path
['', '/usr/lib/python2.6/lib-dynload' ]
then depending on your system, use your system's search facility to find it. on my linux system
$ find /usr/lib/python2.6/lib-dynload -type f -iname "*itertools*"
/usr/lib/python2.6/lib-dynload/itertoolsmodule.so
OR, just search the entire system for the file with name "itertools".