[ python-Bugs-1438537 ] modules search in help() crashes on insufficient file perms

2006-02-25 Thread SourceForge.net 
Bugs item #1438537, was opened at 2006-02-25 09:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing modules 
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1438537 ] modules search in help() crashes on insufficient file perms

2006-02-25 Thread SourceForge.net 
Bugs item #1438537, was opened at 2006-02-25 09:41
Message generated for change (Comment added) made by hauptbeuteltier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing modules 
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

--

>Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 09:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1438537 ] modules search in help() crashes on insufficient file perms

2006-02-25 Thread SourceForge.net 
Bugs item #1438537, was opened at 2006-02-25 09:41
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: A. Coder (hauptbeuteltier)
Assigned to: Nobody/Anonymous (nobody)
Summary: modules search in help() crashes on insufficient file perms

Initial Comment:
In the python interpreter, in the interactive online
help, typing modules 
throws a permission denied error (Errno 13) and dumps
the user back to the main interpreter if the user has
insufficient permission to read any .py file from the
site-packages directory.


Example:
~:$ ls -l /usr/lib/python2.4/site-packages/pygtk.py
-rw-r-  1 root root 2619 2005-02-20 14:18
/usr/lib/python2.4/site-packages/pygtk.py
~:$ python
>>> help()

help> modules html

Here is a list of matching modules.  Enter any module
name to get more help.

HTMLParser - A parser for HTML and XHTML.
htmlentitydefs - HTML character entity references.
htmllib - HTML 2.0 parser.
markupbase - Shared support for scanning document type
declarations in HTML and XHTML.
pydoc - Generate Python documentation in HTML or text
for interactive use.
test.test_htmllib 
test.test_htmlparser - Tests for HTMLParser.py.
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/site.py", line 328, in __call__
return pydoc.help(*args, **kwds)
  File "/usr/lib/python2.4/pydoc.py", line 1650, in
__call__
self.interact()
  File "/usr/lib/python2.4/pydoc.py", line 1668, in
interact
self.help(request)
  File "/usr/lib/python2.4/pydoc.py", line 1686, in help
self.listmodules(split(request)[1])
  File "/usr/lib/python2.4/pydoc.py", line 1790, in
listmodules
apropos(key)
  File "/usr/lib/python2.4/pydoc.py", line 1900, in apropos
ModuleScanner().run(callback, key)
  File "/usr/lib/python2.4/pydoc.py", line 1886, in run
desc = synopsis(path) or ''
  File "/usr/lib/python2.4/pydoc.py", line 182, in synopsis
file = open(filename)
IOError: [Errno 13] Permission denied:
'/usr/lib/python2.4/site-packages/tageditor.py'
>>>

--

Comment By: splitscreen (splitscreen)
Date: 2006-02-25 12:34

Message:
Logged In: YES 
user_id=1126061

Could this just be silently skipped? i.e returning None if
the user does not have the corrept permissions to access a
particular file?

Just wrap the 'file = open(filename)' in pydoc.py: line 182
in a try: except block returning None if there's an error
(such as permission denied).

I have written a patch I can supply if anyone wants it and
if this is the Right Thing To Do (TM).


--

Comment By: A. Coder (hauptbeuteltier)
Date: 2006-02-25 09:44

Message:
Logged In: YES 
user_id=1420716

My apologies. The tageditor.py file had the same permissions
for my test as pygtk.py. The particular file is irrelevant
in this case, it only matters that a user has insufficient
permissions for any file in the site-packages directory.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438537&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1385040 ] compiler module does not detect a syntax error

2006-02-25 Thread SourceForge.net 
Bugs item #1385040, was opened at 2005-12-19 01:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
>Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error

Initial Comment:
import compiler 
compiler.parse("def foo(a=1,b): pass") 
 
Gives: 
 
Module(None, Stmt([Function(None, 'foo', ['a', 'b'], 
[Const(1)], 0, None, Stmt([Pass()]))])) 
 
However, the python interpreter itself barks for the 
same code: 
 
SyntaxError: non-default argument follows default 
argument 
 
 
-Harri 
 
 

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 13:59

Message:
Logged In: YES 
user_id=33168

FYI.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-999444 ] compiler module doesn't support unicode characters in laiter

2006-02-25 Thread SourceForge.net 
Bugs item #999444, was opened at 2004-07-28 07:00
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
>Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module doesn't support unicode characters in laiter

Initial Comment:
I'm not positive that this is a bug.  The buit-in
compile function acepts unicode with non-ascii text in
literals:

>>> text = u"print u'''\u0442\u0435\u0441\u0442'''"
>>> exec compile(text, 's', 'exec')
тест
>>> import compiler
>>> exec compiler.compile(text, 's', 'exec')
Traceback (most recent call last):
  File "", line 1, in ?
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 64, in compile
gen.compile()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 111, in compile
tree = self._get_tree()
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/pycodegen.py",
line 77, in _get_tree
tree = parse(self.source, self.mode)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 50, in parse
return Transformer().parsesuite(buf)
  File
"/usr/local/python/2.3.4/lib/python2.3/compiler/transformer.py",
line 120, in parsesuite
return self.transform(parser.suite(text))
UnicodeEncodeError: 'ascii' codec can't encode
characters in position 10-13: ordinal not in range(128)
>>> 

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 14:00

Message:
Logged In: YES 
user_id=33168

FYI

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-07-29 04:38

Message:
Logged In: YES 
user_id=38388

Note that the tokenizer converts the input string into UTF-8
(transcoding it as necessary if a source code encoding shebang
is found) and the compiler will assume this encoding when
creating
Unicode literals.

I'm not sure whether the compiler package is up-to-date w/r to
these internal changes in the C-based compiler.

--

Comment By: Michael Hudson (mwh)
Date: 2004-07-29 04:30

Message:
Logged In: YES 
user_id=6656

thinking about this a little harder, doing a proper job probably 
invloves mucking around in the depths of python to support 
source-as-unicode throughout.  the vile solution is this sort of 
thing:

>>> parser.suite('# coding: utf-8\n' + u"print 
u'''\u0442\u0435\u0441\u0442'''".encode('utf-8'))



--

Comment By: Michael Hudson (mwh)
Date: 2004-07-29 04:19

Message:
Logged In: YES 
user_id=6656

the immediate problem is that the parser module does support 
unicode:

>>> import parser
>>> parser.suite(u"print u'''\u0442\u0435\u0441\u0442'''")
Traceback (most recent call last):
  File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in 
position 10-13: ordinal not in range(128)

there may well be more bugs lurking in Lib/compiler wrt this 
issue, but this is the first... I don't know how easy this will be to 
fix (looking at what the builtin compile() function does with 
unicode might be a good start).

--

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 07:02

Message:
Logged In: YES 
user_id=73023

Also in 2.3

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999444&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-999042 ] Compiler module doesn't handle global statement correctly

2006-02-25 Thread SourceForge.net 
Bugs item #999042, was opened at 2004-07-27 15:15
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Fulton (dcjim)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Compiler module doesn't handle global statement correctly

Initial Comment:
If we don't use the compiler module:

>>> code = 'global x\nx=1'
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}, 'x': 1}, {})

with the compiler module:

>>> code = compiler.compile('global x\nx=1', 'd', 'exec') 
>>> d1={'__builtins__': {}}; d2={}; exec code in d1, d2
>>> d1, d2
({'__builtins__': {}}, {'x': 1})

global is ignored

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 14:01

Message:
Logged In: YES 
user_id=33168

FYI

--

Comment By: Darek Suchojad (dsuch)
Date: 2005-04-29 15:04

Message:
Logged In: YES 
user_id=954779

Hi, I have submitted a simple fix some time ago
python.org/sf/1090482, do you think it is correct?

--

Comment By: Jim Fulton (dcjim)
Date: 2004-07-28 07:01

Message:
Logged In: YES 
user_id=73023

Also in 2.3

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=999042&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1438185 ] os.renames() crashes NTFS junctions

2006-02-25 Thread SourceForge.net 
Bugs item #1438185, was opened at 2006-02-24 10:03
Message generated for change (Comment added) made by logistix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Rohlfing (damiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.renames() crashes NTFS junctions

Initial Comment:
Hello

There is a problem using os.renames() with a path, 
that was created as a ntfs junction.

You will find more information about junctions and a 
tool to create them on:
http://www.sysinternals.com/Utilities/Junction.html
The source is also available there.

Try this to reproduce the problem:

*in DOS*
mkdir C:\dir1
echo >>C:\dir1\old.txt
junction.exe C:\dir2 C:\dir1

*in Python*
>>> import os
>>> os.renames("C:\\dir2\\old.txt", "C:\\dir2
\\new.txt")

If you now look in 'dir1' you will find new.txt
thats fine, but junction 'dir2' not longer exist.

os.rename() is not affected by this problem.

My OP is Windows 2000 [Version 5.00.2195] with SP4 and 
im using Python 2.4.2

I hope you will find this information usefull.

greets from germany
Daniel Rohlfing


--

Comment By: Grant Olson (logistix)
Date: 2006-02-25 17:02

Message:
Logged In: YES 
user_id=699438

This is because 'os.rmdir' doesn't throw an exception when
deleting a junction, since it doesn't really have any files
under it.  Does look like a bug to me though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438185&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1438480 ] shutil.move raises OSError when copystat fails

2006-02-25 Thread SourceForge.net 
Bugs item #1438480, was opened at 2006-02-25 05:26
Message generated for change (Comment added) made by piman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438480&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Wreschnig (piman)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.move raises OSError when copystat fails

Initial Comment:
If you are on a Linux system, and shutil.move a file
from anywhere onto a partition where you have write
permission but are not the owner, os.utime will fail
with an EPERM OSError. This can (and did) happen moving
a file on a vfat partition mounted with umask=, so
every user had read/write/execute but all files were
owned by root.

This happens in shutil.copystat, so shutil.move doesn't
remove the old file. The resulting error code (OSError,
EPERM) is not distinguishable from several other
permission errors that can happen during shutil.move,
even though a failure to set a utime is not fatal for
most move operations (mv(1) succeeds, for example).

I would suggest either ignoring an EPERM from copystat,
or catching it in shutil.copy2 and raising a more
specific exception so that it can be easily
distinguished from genuine failure due to permissions.

--

>Comment By: Joe Wreschnig (piman)
Date: 2006-02-26 05:08

Message:
Logged In: YES 
user_id=796

The attached patch causes shutil.copy and shutil.copy2 (and
so copytree, and move) to ignore EACCES and EPERM from
copymode and copystat respectively. Other errors are
reraised with the original traceback. Any error copying the
file, rather than the metadata, is still considered fatal.
User calls to copymode and copystat still fail as before.

Justification: On Linux, utime(2) says the distinction
between EACCES and EPERM is blurry and "Linux is not careful
to distinguish between the EACCES and EPERM" so the patch
ignores both. In my opinion, anyone wanting to deal with
low-level details like mtimes and modes is probably not
using shutil, so ignoring is better than a new exception
(which would just result in complicated new code, and
surprise old code). It's also easy for a caller to check if
the mode/utimes were copied, if it's important to them.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1438480&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com