[ python-Bugs-1747858 ] chown broken on 64bit
Bugs item #1747858, was opened at 2007-07-04 16:21
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neal D. Becker (nbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: chown broken on 64bit
Initial Comment:
python-2.5 on fedora fc7 x86_64:
os.stat returns uid > 32bit:
os.stat ('shit')
(33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507,
1183558517)
os.chown doesn't like that:
os.chown ('shit', 4294967294, 4294967294)
Traceback (most recent call last):
File "", line 1, in
OverflowError: signed integer is greater than maximum
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-07-08 12:29
Message:
Logged In: YES
user_id=21627
Originator: NO
Notice that the value really is -2.
It's important to find out how uid_t is defined on the platform;
it may be that the return value of stat is already incorrect.
Merely changing the variables to uid_t and gid_t is not enough,
since then ParseTuple would stop working correctly.
Is anybody interested in providing a patch?
--
Comment By: Andrew Ferguson (owsla)
Date: 2007-07-04 17:04
Message:
Logged In: YES
user_id=19094
Originator: NO
Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables
are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which
are mapped to 'unsigned int' on at least some Unix platforms (I haven't
checked extensively.)
The wrinkle here is that chown() needs to be able to handle the case of
uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1,
-1) is valid, but so is os.chown(4294967294, 4294967294).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1747858 ] chown broken on 64bit
Bugs item #1747858, was opened at 2007-07-04 10:21
Message generated for change (Comment added) made by owsla
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neal D. Becker (nbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: chown broken on 64bit
Initial Comment:
python-2.5 on fedora fc7 x86_64:
os.stat returns uid > 32bit:
os.stat ('shit')
(33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507,
1183558517)
os.chown doesn't like that:
os.chown ('shit', 4294967294, 4294967294)
Traceback (most recent call last):
File "", line 1, in
OverflowError: signed integer is greater than maximum
--
Comment By: Andrew Ferguson (owsla)
Date: 2007-07-08 09:51
Message:
Logged In: YES
user_id=19094
Originator: NO
No, the return value of stat is correct. For that it does:
PyInt_FromLong((long)st->st_uid) in _pystat_fromstructstat(STRUCT_STAT *st)
(same file, posixmodule.c). Fedora has been defining the UID of the
nfsnobody user on 32-bit to be 65534 (USHRT_MAX - 1) and on 64-bit to be
4294967294 (UINT_MAX - 1), assuming 32-bit ints. So, yes, this absurdly
high UID is real.
So that chown('foo', -1, -1) makes sense, the UID that would be "(uid_t)
-1" is reserved. That's why Fedora went for "(uid_t) -2".
I think a patch should look something like:
$ diff -p posixmodule.c.orig posixmodule.c
*** posixmodule.c.orig Sun Jul 8 09:43:50 2007
--- posixmodule.c Sun Jul 8 09:48:27 2007
*** static PyObject *
*** 1826,1834
posix_chown(PyObject *self, PyObject *args)
{
char *path = NULL;
! int uid, gid;
int res;
! if (!PyArg_ParseTuple(args, "etii:chown",
Py_FileSystemDefaultEncoding, &path,
&uid, &gid))
return NULL;
--- 1826,1834
posix_chown(PyObject *self, PyObject *args)
{
char *path = NULL;
! unsigned int uid, gid;
int res;
! if (!PyArg_ParseTuple(args, "etII:chown",
Py_FileSystemDefaultEncoding, &path,
&uid, &gid))
return NULL;
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-07-08 06:29
Message:
Logged In: YES
user_id=21627
Originator: NO
Notice that the value really is -2.
It's important to find out how uid_t is defined on the platform;
it may be that the return value of stat is already incorrect.
Merely changing the variables to uid_t and gid_t is not enough,
since then ParseTuple would stop working correctly.
Is anybody interested in providing a patch?
--
Comment By: Andrew Ferguson (owsla)
Date: 2007-07-04 11:04
Message:
Logged In: YES
user_id=19094
Originator: NO
Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables
are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which
are mapped to 'unsigned int' on at least some Unix platforms (I haven't
checked extensively.)
The wrinkle here is that chown() needs to be able to handle the case of
uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1,
-1) is valid, but so is os.chown(4294967294, 4294967294).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1747858 ] chown broken on 64bit
Bugs item #1747858, was opened at 2007-07-04 10:21
Message generated for change (Comment added) made by owsla
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neal D. Becker (nbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: chown broken on 64bit
Initial Comment:
python-2.5 on fedora fc7 x86_64:
os.stat returns uid > 32bit:
os.stat ('shit')
(33204, 4420723, 64768L, 1, 4294967294, 500, 0, 1183558507, 1183558507,
1183558517)
os.chown doesn't like that:
os.chown ('shit', 4294967294, 4294967294)
Traceback (most recent call last):
File "", line 1, in
OverflowError: signed integer is greater than maximum
--
Comment By: Andrew Ferguson (owsla)
Date: 2007-07-08 09:58
Message:
Logged In: YES
user_id=19094
Originator: NO
Reformatted sample patch:
--- posixmodule.c.orig 2007-07-08 09:43:50.0 -0400
+++ posixmodule.c 2007-07-08 09:48:27.0 -0400
@@ -1826,9 +1826,9 @@
posix_chown(PyObject *self, PyObject *args)
{
char *path = NULL;
- int uid, gid;
+ unsigned int uid, gid;
int res;
- if (!PyArg_ParseTuple(args, "etii:chown",
+ if (!PyArg_ParseTuple(args, "etII:chown",
Py_FileSystemDefaultEncoding, &path,
&uid, &gid))
return NULL;
--
Comment By: Andrew Ferguson (owsla)
Date: 2007-07-08 09:51
Message:
Logged In: YES
user_id=19094
Originator: NO
No, the return value of stat is correct. For that it does:
PyInt_FromLong((long)st->st_uid) in _pystat_fromstructstat(STRUCT_STAT *st)
(same file, posixmodule.c). Fedora has been defining the UID of the
nfsnobody user on 32-bit to be 65534 (USHRT_MAX - 1) and on 64-bit to be
4294967294 (UINT_MAX - 1), assuming 32-bit ints. So, yes, this absurdly
high UID is real.
So that chown('foo', -1, -1) makes sense, the UID that would be "(uid_t)
-1" is reserved. That's why Fedora went for "(uid_t) -2".
I think a patch should look something like:
$ diff -p posixmodule.c.orig posixmodule.c
*** posixmodule.c.orig Sun Jul 8 09:43:50 2007
--- posixmodule.c Sun Jul 8 09:48:27 2007
*** static PyObject *
*** 1826,1834
posix_chown(PyObject *self, PyObject *args)
{
char *path = NULL;
! int uid, gid;
int res;
! if (!PyArg_ParseTuple(args, "etii:chown",
Py_FileSystemDefaultEncoding, &path,
&uid, &gid))
return NULL;
--- 1826,1834
posix_chown(PyObject *self, PyObject *args)
{
char *path = NULL;
! unsigned int uid, gid;
int res;
! if (!PyArg_ParseTuple(args, "etII:chown",
Py_FileSystemDefaultEncoding, &path,
&uid, &gid))
return NULL;
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-07-08 06:29
Message:
Logged In: YES
user_id=21627
Originator: NO
Notice that the value really is -2.
It's important to find out how uid_t is defined on the platform;
it may be that the return value of stat is already incorrect.
Merely changing the variables to uid_t and gid_t is not enough,
since then ParseTuple would stop working correctly.
Is anybody interested in providing a patch?
--
Comment By: Andrew Ferguson (owsla)
Date: 2007-07-04 11:04
Message:
Logged In: YES
user_id=19094
Originator: NO
Indeed, in Modules/posixmodule.c::posix_chown(), the uid and gid variables
are defined as type 'int'. They should be of type 'uid_t' and 'gid_t' which
are mapped to 'unsigned int' on at least some Unix platforms (I haven't
checked extensively.)
The wrinkle here is that chown() needs to be able to handle the case of
uid/gid set to -1, which means to leave them as is. Therefore, os.chown(-1,
-1) is valid, but so is os.chown(4294967294, 4294967294).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1747858&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1750013 ] os.getlogin should use the DISPLAY and not the tty
Bugs item #1750013, was opened at 2007-07-08 22:02
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=1750013&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Serge Noiraud (snoiraud)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.getlogin should use the DISPLAY and not the tty
Initial Comment:
Hi,
I have the following with gramps on kubuntu ( KDE ).
My terminals are "konsole". They don't register their pty
in utmp and I think they are correct. We are already logged. so if we register
again for each konsole, we have a bad user count.
In these case, os.getlogin() return :
OSError: [Errno 2] No such file or directory
I think getlogin should use the DISPLAY instead of the tty when we get this
error.
to correct this problem I use :
try:
user=os.getlogin()
except:
user=os.environ.get("USER")
but I'm not sure os.environ.get return the good value on every OSes ...
I have tested too :
except:
user = pwd.getpwuid(os.getuid())[0]
What is the best solution to this problem.
I looked at all bugs about getlogin and I saw we should avoid this function.
What is in this case the function we should use and which works correctly on
every OS ( Linux, Unices, Windows, MAC OS/X, ... )
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750013&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers
Bugs item #1750076, was opened at 2007-07-08 18:24 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=1750076&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers
Bugs item #1750076, was opened at 2007-07-08 18:24 Message generated for change (Comment added) made by gotgenes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. -- >Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:32 Message: Logged In: YES user_id=1180453 Originator: YES Here's a file for demonstration purposes. File Added: simple.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers
Bugs item #1750076, was opened at 2007-07-08 18:24 Message generated for change (Comment added) made by gotgenes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. -- >Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:35 Message: Logged In: YES user_id=1180453 Originator: YES Notice how in Python 2.5, the breakpoint is met once then passed over, leading straight to the final print statement -- [EMAIL PROTECTED]:~/development/playground$ python2.5 -m pdb simple.py > /home/chris/development/playground/simple.py(3)() -> a = 10 (Pdb) b 5 Breakpoint 1 at /home/chris/development/playground/simple.py:5 (Pdb) l 1 #!/usr/bin/env python 2 3 -> a = 10 4 5 B while a > 0: 6 a -= 1 # how do I check the value of a at end of last iter.? 7 8 print "Fin!" [EOF] (Pdb) r > /home/chris/development/playground/simple.py(5)() -> while a > 0: (Pdb) r Fin! --Return-- > /home/chris/development/playground/simple.py(8)()->None -> print "Fin!" (Pdb) -- Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:32 Message: Logged In: YES user_id=1180453 Originator: YES Here's a file for demonstration purposes. File Added: simple.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1750076 ] Python 2.5+ skips while statements in debuggers
Bugs item #1750076, was opened at 2007-07-08 18:24 Message generated for change (Comment added) made by gotgenes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&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: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Lasher (gotgenes) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5+ skips while statements in debuggers Initial Comment: Starting with Python 2.5, debuggers pass through a "while" statement on its declaration, but never return to it during the remainder of the loop. They should be able to return to the "while" statement as it has an evaluative step in it. This has several important implications: one may not check the state of variables at prior to their evaluation in the "while" statement, and any breakpoints set on the "while" statement are ignored once within the while loop. Python prior versions (2.4 and below) exhibit expected behavior in that the "while" statement is returned to after each successful iteration through the loop, and breakpoints on "while" statements are honored. -- >Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:37 Message: Logged In: YES user_id=1180453 Originator: YES Notice how in Python 2.4, the breakpoint is honored through each iteration through the while loop. -- [EMAIL PROTECTED]:~/development/playground$ python2.4 -m pdb simple.py > /home/chris/development/playground/simple.py(3)?() -> a = 10 (Pdb) b 5 Breakpoint 1 at /home/chris/development/playground/simple.py:5 (Pdb) l 1 #!/usr/bin/env python 2 3 -> a = 10 4 5 B while a > 0: 6 a -= 1 # how do I check the value of a at end of last iter.? 7 8 print "Fin!" [EOF] (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 10 (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 9 (Pdb) r > /home/chris/development/playground/simple.py(5)?() -> while a > 0: (Pdb) p a 8 (Pdb) -- Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:35 Message: Logged In: YES user_id=1180453 Originator: YES Notice how in Python 2.5, the breakpoint is met once then passed over, leading straight to the final print statement -- [EMAIL PROTECTED]:~/development/playground$ python2.5 -m pdb simple.py > /home/chris/development/playground/simple.py(3)() -> a = 10 (Pdb) b 5 Breakpoint 1 at /home/chris/development/playground/simple.py:5 (Pdb) l 1 #!/usr/bin/env python 2 3 -> a = 10 4 5 B while a > 0: 6 a -= 1 # how do I check the value of a at end of last iter.? 7 8 print "Fin!" [EOF] (Pdb) r > /home/chris/development/playground/simple.py(5)() -> while a > 0: (Pdb) r Fin! --Return-- > /home/chris/development/playground/simple.py(8)()->None -> print "Fin!" (Pdb) -- Comment By: Chris Lasher (gotgenes) Date: 2007-07-08 18:32 Message: Logged In: YES user_id=1180453 Originator: YES Here's a file for demonstration purposes. File Added: simple.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1750076&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
