[ 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 (Comment added) made by loewis
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: Closed
>Resolution: Invalid
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, ... )
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-07-10 10:45
Message:
Logged In: YES
user_id=21627
Originator: NO
os.getlogin is a wrapper around the getlogin(3) POSIX function. It is
important that Python exposes the function as-is, rather than trying to be
more clever than the operating system designers. getlogin(3) is specified
as "getlogin() returns a pointer to a string containing the name of the
user logged in on the controlling terminal of the process, or a null
pointer if this information cannot be determined." See the man page for the
precise list of error conditions; ENOENT is returned if there is no utmp
entry.
Whether konsole is correct in not listing the controlling terminal in
utmp, I don't know. Notice that xterm (which should be considered an
authority in such matters) *does* create an utmp entry.
It's not clear to me how DISPLAY could be used at all, but even if it
could, using it here would be incorrect.
Closing as invalid.
--
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-Feature Requests-1637365 ] if __name__=='__main__' missing in tutorial
Feature Requests item #1637365, was opened at 2007-01-17 06:11
Message generated for change (Comment added) made by sonderblade
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: if __name__=='__main__' missing in tutorial
Initial Comment:
I could not find any reference to the big idiom:
if __name__=="__main__":
xxx()
inside the Python tutorial. Of course it is documented in the Library Reference
and the Reference Manual, but such an important idiom should be on the Tutorial
for beginners to see.
I can't provide a patch, and English is not my native language, but I think a
short text like the following would suffice (in section More on Modules, before
the paragraph "Modules can import other modules..."):
Sometimes it is convenient to invoke a module as it were a script, either for
testing purposes, or to provide a convenient user interfase to the functions
contained in the module. But you don't want to run such code when the module is
imported into another program, only when it's used as a standalone script. The
way of differentiate both cases is checking the \code{__name__} attribute: as
seen on the previous section, it usually holds the module name, but when the
module is invoked directly, it's always \samp{__main__} regardless of the
script name.
Add this at the end of \file{fibo.py}:
\begin{verbatim}
if __name__=="__main__":
import sys
fib(int(sys.argv[1]))
\end{verbatim}
and then you can execute it using:
\begin{verbatim}
python fibo.py 50
1 1 2 3 5 8 13 21 34
\end{verbatim}
--
Comment By: Bj�rn Lindqvist (sonderblade)
Date: 2007-07-10 13:10
Message:
Logged In: YES
user_id=51702
Originator: NO
I just ran into this "problem" today, when teaching someone python. It is
definitely a glaring omission and needs to be fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1751245 ] Popen pipe file descriptor leak on OSError in init
Bugs item #1751245, was opened at 2007-07-10 11:04
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=1751245&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: Justin Francis (justinfrancis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Popen pipe file descriptor leak on OSError in init
Initial Comment:
OS: Gentoo Linux 2.6.12-r6
Python: 2.5 r25:51908
When creating a Popen object that refers to a file that does not exist, the
pipes that are created are not closed, and remain in the system. In
long-running processes, this will eventually use up all the file descriptors
available.
>> import os, subprocess
>> os.system('/usr/sbin/lsof | grep python | grep -i pipe')
...
python18822 jfrancis6r FIFO0,5 56188 pipe
python18822 jfrancis7r FIFO0,5 56190 pipe
>> p = subprocess.Popen('doesnotexist', stdout=subprocess.PIPE)
OSError: [Errno 2] No such file or directory
>> os.system('/usr/sbin/lsof | grep python | grep -i pipe')
...
python18822 jfrancis6r FIFO0,5 56188 pipe
python18822 jfrancis7r FIFO0,5 56190 pipe
python18822 jfrancis8r FIFO0,5 56713 pipe
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751245&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 17:38 Message: Logged In: YES user_id=769182 Originator: NO Did this get fixed in subprocess.py? The patches all seem to be for popen2. I have been observing similar problems in subprocess.py, so I downloaded the test script and ran it with the -s option. It didn't work out of the box, I had to pass "shell=True" to the subprocess.Popen before it did anything at all. Which also made me wonder if the subprocess variant of this problem got forgotten. Having done that, I have observed failures using Python 2.4.4 on Red Hat EL3 Linux, and also using Python 2.4.3 on Red Hat EL4 linux. Most of the time it works, sometimes it hangs forever, and sometimes we get something that look like this: Started 20 threads Exception in thread Thread-19: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "popen_bug.py", line 53, in run pipe.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes P.S. Googling for "[Errno 10] No child processes" suggests others have this problem. There have been long discussions on the Zope list as to why some people on Linux get exceptions that look like this, for example. -- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think the object should get removed from _active - otherwise, it would stay there forever. Of course, care is then need to avoid __del__ adding it back to _active. Putting these all together, I propose v3 of the patch. Another aspect that puzzles me is the repeated test that waitpid() really returns the pid you asked for. How could it not? If it
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by gjb1002 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 18:00 Message: Logged In: YES user_id=769182 Originator: NO As an additional note, I have also reproduced the popen problem using Python 2.4.4, though only once. It seems to occur more frequently in subprocess.py. -- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 17:38 Message: Logged In: YES user_id=769182 Originator: NO Did this get fixed in subprocess.py? The patches all seem to be for popen2. I have been observing similar problems in subprocess.py, so I downloaded the test script and ran it with the -s option. It didn't work out of the box, I had to pass "shell=True" to the subprocess.Popen before it did anything at all. Which also made me wonder if the subprocess variant of this problem got forgotten. Having done that, I have observed failures using Python 2.4.4 on Red Hat EL3 Linux, and also using Python 2.4.3 on Red Hat EL4 linux. Most of the time it works, sometimes it hangs forever, and sometimes we get something that look like this: Started 20 threads Exception in thread Thread-19: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "popen_bug.py", line 53, in run pipe.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes P.S. Googling for "[Errno 10] No child processes" suggests others have this problem. There have been long discussions on the Zope list as to why some people on Linux get exceptions that look like this, for example. -- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fine with me, feel free to check it in. BTW, nice comments and precondition checks in the test. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 08:40 Message: Logged In: YES user_id=21627 This looks all fine. As a further issue, I think _cleanup should also clean processes which already have been waited on. So if waitpid gives ECHILD (in _cleanup), I think
[ python-Bugs-1183780 ] Popen4 wait() fails sporadically with threads
Bugs item #1183780, was opened at 2005-04-15 16:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1183780&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Taale Skogan (tskogan) Assigned to: Neal Norwitz (nnorwitz) Summary: Popen4 wait() fails sporadically with threads Initial Comment: Calling wait() on a popen2.Popen4 object fails intermittently with the error Traceback (most recent call last): ... File "/usr/local/lib/python2.3/popen2.py", line 90, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes when using threads. The problem seems to be a race condition when a thread calls wait() on a popen2.Popen4 object. This also apllies to Popen3 objects. The constructor of Popen4. calls _cleanup() which calls poll() which calls the system call waitpid() for all acitve child processes. If another thread calls poll() before the current thread calls wait() on it's child process and the child process has terminated, the child process is no longer waitable and the second call to wait() fails. Code to replicate this behavoir is attached in popen_bug. py. Solution: Popen4 and Popen3 should be threadsafe. Related modules: A seemingly related error occurs with Popen from the new subprocess module. Use the -s option in the popen_bug.py script to test this. Tested on Linux RedHat Enterprise 3 for Python 2.3.3, Python 2.3.5 and Python 2.4.1 and Solaris for Python 2. 4.1. The error did not occur on a RedHat 7.3 machine with Python 2.3.5. See the attached file popen_bug.py for details on the platforms. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-07-10 23:50 Message: Logged In: YES user_id=21627 Originator: NO If you are seeing a bug in subprocess, please report it separately. This one has been fixed. Please don't assume that it is the "same" problem as the one reported here, unless you have a working patch that proves that it is indeed a similar problem. -- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 18:00 Message: Logged In: YES user_id=769182 Originator: NO As an additional note, I have also reproduced the popen problem using Python 2.4.4, though only once. It seems to occur more frequently in subprocess.py. -- Comment By: Geoffrey Bache (gjb1002) Date: 2007-07-10 17:38 Message: Logged In: YES user_id=769182 Originator: NO Did this get fixed in subprocess.py? The patches all seem to be for popen2. I have been observing similar problems in subprocess.py, so I downloaded the test script and ran it with the -s option. It didn't work out of the box, I had to pass "shell=True" to the subprocess.Popen before it did anything at all. Which also made me wonder if the subprocess variant of this problem got forgotten. Having done that, I have observed failures using Python 2.4.4 on Red Hat EL3 Linux, and also using Python 2.4.3 on Red Hat EL4 linux. Most of the time it works, sometimes it hangs forever, and sometimes we get something that look like this: Started 20 threads Exception in thread Thread-19: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "popen_bug.py", line 53, in run pipe.wait() File "/usr/lib/python2.4/subprocess.py", line 1007, in wait pid, sts = os.waitpid(self.pid, 0) OSError: [Errno 10] No child processes P.S. Googling for "[Errno 10] No child processes" suggests others have this problem. There have been long discussions on the Zope list as to why some people on Linux get exceptions that look like this, for example. -- Comment By: cheops (atila-cheops) Date: 2006-04-10 16:55 Message: Logged In: YES user_id=1276121 see patch # 1467770 for subprocess.py library module -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-24 09:16 Message: Logged In: YES user_id=21627 Committed as 43286. I also added .cmd to Popen4. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-24 08:56 Message: Logged In: YES user_id=33168 It makes sense to remove from _active on ECHILD. I wondered the same thing about waitpid(), but left it as it was. I don't believe it's possible for waitpid to return any pid other than what you ask for unless the O/S is very, very broken. This patch is fi
[ python-Bugs-1751598 ] struni: str() doesn't call __str__() of subclasses of str
Bugs item #1751598, was opened at 2007-07-11 03:48
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=1751598&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 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: struni: str() doesn't call __str__() of subclasses of str
Initial Comment:
In the py3k-struni branch the str() constructor doesn't use __str__ when the
argument is an instance of a subclass of str. A user defined string can't
change __str__().
It works in Python 2.5 and in the p3yk branch.
Python 3.0x (py3k-struni:56245, Jul 10 2007, 23:34:56)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Mystr(str):
... def __str__(self): return 'v'
...
>>> s = Mystr('x')
>>> s
'x'
>>> str(s)
'x' # <- SHOULD RETURN 'v'
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Mystr(str):
... def __str__(self): return 'v'
...
>>> s = Mystr('x')
>>> s
'x'
>>> str(s)
'v'
Python 3.0x (p3yk:56180, Jul 6 2007, 23:35:08)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Mystr(str):
... def __str__(self): return 'v'
...
>>> s = Mystr('x')
>>> s
'x'
>>> str(s)
'v'
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1751598&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
