[issue5985] Implement os.path.samefile and os.path.sameopenfile on Windows
Erik Sandberg added the comment: An alternative solution which I would have considered, is to extend stat/fstat on Windows to set st_dev and st_ino to sensible values (based on dwVolumeSerialNumber and nFileIndexLow/High), and then use the POSIX implementations of samefile/sameopenfile. There may be one potential problem with this solution though: It would require stat to perform a CreateFile in addition to GetFileAttributesEx, and I don't know if there are situations where one is allowed to call the latter but not the former on a file. There would be no such problems with fstat, though. In your patch, I think the dwShareMode parameter to CreateFile* should be changed to FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE so make the operation less intrusive. -- ___ Python tracker <http://bugs.python.org/issue5985> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6450] normpath() sometimes maps unicode to str
New submission from Erik Sandberg : On Linux, I get the following: >>> import os >>> os.path.normpath(u'/') '/' I would expect unicode to be mapped to unicode. os.path.abspath() has the same problem, see also issue 3426. This causes problems in my project, where a function requires its parameters to be Unicode. Do the standard Python library functions that operate on strings guarantee anything in general with respect to conserving unicode? Can I make any assumption as to which codec was used to encode the str returned from normpath? -- components: Library (Lib) messages: 90341 nosy: sandberg severity: normal status: open title: normpath() sometimes maps unicode to str type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6450> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5985] Implement os.path.samefile and os.path.sameopenfile on Windows
New submission from Erik Sandberg : It would be nice if samefile / sameopenfile was present on Windows. Right now I usually work around this by keeping a platform-specific hack for Windows that approximates samefile by comparing normalized paths; this is ugly and doesn't handle junctions correctly. In one of my projects I have written a C implementation of samefile, which I manually monkey-patched os.path with. It would probably be rather easy to adapt it to become a native part of ntpath. My code relies on GetFileInformationByHandle, which is only available in Windows 2000 professional and newer (http://msdn.microsoft.com/en-us/library/aa364952(VS.85).aspx); if I understood it correctly this should not be a problem as Python 2.6 and newer doesn't support older versions of Windows. Unfortunately I don't use Windows myself, but I have rdesktop access to an XP machine with cygwin and Visual Studio 2005 installed (which seems insufficient to build python 2.6, at least), so it will be difficult for me to test my code. But I'll post some code soon. -- messages: 87518 nosy: sandberg severity: normal status: open title: Implement os.path.samefile and os.path.sameopenfile on Windows type: feature request versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue5985> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5484] subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
Erik Sandberg added the comment: Did you test your code? I'm pretty sure I tried almost exactly the code you suggest, and got an error like "'t' is not recognized as an internal or external command...' (I cannot test this right now as I don't have access to Windows machines). In order to use shell=False, I think the correct thing should be something like this, though I haven't tried it myself yet: subprocess.call(["/c", "t(o.bat"], executable="cmd.exe") (this guess is based on what I read in msdn.com's docs on CreateProcess: """To run a batch file, you must start the command interpreter; set lpApplicationName to cmd.exe and set lpCommandLine to the following arguments: /c plus the name of the batch file.""") -- ___ Python tracker <http://bugs.python.org/issue5484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5484] subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
Erik Sandberg added the comment:
I experimented further, the only way to run a .bat file whose name
contains funny characters, seems to be:
subprocess.call('""f(o.bat""', shell=True)
--
___
Python tracker
<http://bugs.python.org/issue5484>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5484] subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
Erik Sandberg added the comment: argh, it seems that the problem is in how CreateProcess works; exactly the same error can be provoked from C. -- Added file: http://bugs.python.org/file13321/parenbug.c ___ Python tracker <http://bugs.python.org/issue5484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5484] subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
Erik Sandberg added the comment: I have narrowed down the problem further: The same error happens with the following code: import win32process win32process.CreateProcess(None, 'f(o.bat', None, None, 1, 0, None, None, win32process.STARTUPINFO()) -- ___ Python tracker <http://bugs.python.org/issue5484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5484] subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
Erik Sandberg added the comment: I'm using Python 2.5.1, by the way. -- ___ Python tracker <http://bugs.python.org/issue5484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5484] subprocess.call() fails for .bat files on Windows, if executable path contains parenthesis
New submission from Erik Sandberg :
When subprocess.call is told to execute a .bat file on Windows, and the
path to the batch file is given as an absolute path, and the path
includes a left parenthesis ('('), then the call fails with a message
similar to the following; it appears that the parenthesis is incorrectly
quoted.
'c:\tmp\f' is not recognized as an internal or external command,
operable program or batch file.
Traceback (most recent call last):
File "parenbug.py", line 7, in
subprocess.check_call(os.path.join(os.getcwd(), bat))
File "c:\Python25\lib\subprocess.py", line 461, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'c:\tmp\f(o.bat' returned
non-zero exit status 1
I have reproduced this on Windows XP.
--
components: Library (Lib), Windows
files: parenbug.py
messages: 83518
nosy: sandberg
severity: normal
status: open
title: subprocess.call() fails for .bat files on Windows, if executable path
contains parenthesis
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file13319/parenbug.py
___
Python tracker
<http://bugs.python.org/issue5484>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3963] Problems when calling exec from a function
Erik Sandberg <[EMAIL PROTECTED]> added the comment: Thanks! Passing an explicit global namespace solves the problem and is something I wanted to do anyways, when I think about it. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3963] Problems when calling exec from a function
New submission from Erik Sandberg <[EMAIL PROTECTED]>: When an exec statement called from a function f defines a top-level function g, the body of g cannot access the top-level symbols defined by the exec statement (which also happen to be the local variables of f). Example: x = 2 def f(): exec "x = 1\ndef b(): return x" print b() f() An unqualified guess is that the mix of being top-level and being a local variable, makes the symbol end up somewhere between locals() and globals(). Example: The problem causes real-life problems when I want to create a wrapper function around execfile() to handle certain exceptions. -- components: Interpreter Core messages: 73795 nosy: sandberg severity: normal status: open title: Problems when calling exec from a function type: behavior versions: Python 2.4, Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3928] os.mknod missing on Solaris
New submission from Erik Sandberg <[EMAIL PROTECTED]>: When building Python on Solaris, I don't get the os.mknod function. This seems to be a combination of two errors: 1. The definition of posix_mknod() in posixmodule.c is surrounded by: #if defined(HAVE_MKNOD) && defined(HAVE_MAKEDEV) It works fine if I remove the HAVE_MAKEDEV define. 2. The reason why HAVE_MAKEDEV doesn't work, is that the Python configure script only looks for makedev in , while on Solaris you need to include as well. cc -V gives: cc: Sun C 5.9 SunOS_sparc Patch 124867-01 2007/07/12 uname -a gives: SunOS zelda 5.9 Generic_117171-07 sun4us sparc FJSV,GPUZC-M -- components: Extension Modules messages: 73562 nosy: sandberg severity: normal status: open title: os.mknod missing on Solaris type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3928> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
