New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDLE: inconsistent use of HOMEDRIVE, HOMEPATH, and USERPROFILE on Windows #58781
Comments
It's a common issue that IDLE cannot start on Windows because "IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection." Everyone claim that the user should set the firewal so that IDLE can connect to subprocess via loopback. I found, instead, that this issue is often caused by an incorrect or missing setting of one the following variables: HOME, USERPROFILE or the combination of HOMEPATH and HOMEDRIVE; if these variables don't represent an existent and writable directory, the error occurs. OS: Windows XP clikkeb |
I can confirm that setting HOMEPATH to a non-existent directory will prevent IDLE from starting when using idle.bat. If you modify idle.bat such that python.exe is called instead of pythonw.exe, then IDLE starts normally, but with this console message: Warning: os.path.expanduser("~") points to Normally, the message is written to sys.stderr, which is None when using pythonw. See bpo-13582 for more information. |
Thanks for your answer. Trying to understand how IDLE uses HOMEPATH and USERPROFILE Windows
Due to the Python's tricky behaviour in determining the Windows clikkeb. |
It certainly is worthwhile pursing this in some fashion, since at the very least the existing error message needs to be improved. But perhaps there is something more that can be done to gracefully handle this case, instead. I think the next interesting question is to find out why an invalid home directory causes idle to not start up. There's no obvious reason why that should be the case in principle, so I suspect there's some error handling missing somewhere. This probably also applies to 2.7; someone should test that. |
I think that lines 207-210 of GetUserCfgDir should be modified like this: try: because when you start IDLE via pythonw.exe (that sets sys.stderr to "None"),
and IDLE stops running without displaying any exception error, because that There is a funcion call to sys.stderr.write also at line 222, just before a |
I guess IdleConf should to have flag like 'writable'. BTW, there are related bpo-8231. |
It is one of the possible solutions. In combination with the "writable flag" solution, you might create a class Anyway, keep in mind that in GetUserConfig there's an unhandled exception (AttributeError) that might be the cause of the "IDLE doesn't start..." issue reported by users. |
As Roger showed, IDLE will start up with an invalid home directory.
Yes, the uncaught exception raised when attempting to display a non-essential but user-useful messages (this is the third issue I know of about this). There are 5 places in configHandler.py where a warning is directly printed to sys.stderr. There are two similar writes in PyShell.py. The first warning is the problem here, but any of them could be a problem and all should be handled better. Lib/idlelib\PyShell.py: 1357: sys.stderr.write("Error: %s\n" % str(msg)) Why are warning used instead of message boxes? Perhaps easier, perhaps the latter are not available because the tk loop is not running. Possible solutions:
import io
class DummyOut(io.IOBase):
def write(self, s):
return len(s)
dum = DummyOut()
print(dum.write('sixsix'))
# 6 |
This issue triggers the problem described in bpo-13582. It points out problems with IDLE's configuration manager w.r.t. determining the home directory. I changed the title so that it reflects that point. |
I found a weird solution for the problem. Exchange the names of python and pythonw in the python33 folder. This makes the IDLE to call both and as a result python opens in both modes simultaneosly, and the subprocess connection error don't shows up. |
I do not understand what you mean by "Exchange the names of python and pythonw in the python33 folder.". In any case, idle.bat cannot run both simultaneously. Perhaps idle.bat should have an option to start with python instead of pythonw. |
I found the root cause for the error regarding python in my pc that shows the error message "IDLE's subprocess didn't make connection.Either IDLE can't start a subprocess or personal firewall software is blocking the connection." It was caused due to a software known as proxifier which provides fast and somewhat unrestricted network access on proxy networks. It redirected my connection request from pythonw.exe to the port and IP on which the proxy network is established. The problem hence can be easily sorted by creating new proxification rules in such softwares, if the cause of the problem can be traced to some similar mechanisms used that may intercept and modify the network requests for other programs. |
Divyanshu, please do not hijack by changing the title to a different issue. There are multiple causes for the message, some unknown. Your non-standard system is different from that of clikkeb. |
I hit this issue with an "H:" homedrive that is on a network share, and then in Windows is using "offline files" to keep a local copy. .idlerc was not cached so IDLE worked when online/connected to my work network but not when I was offline. The temporary workaround was to mark .idlerc as "available offline" when connected. I wanted to document this in case others hit this scenario. I also noticed that there is a .idlerc directory created in my local user directory c:\users\[username\.idlerc. This one has the recent-files.lst in it. So IDLE is creating two copies of .idlerc - one in the environment-variable-defined (and roaming) home directory, and one in the default local user directory. I would suggest that as this bug is investigated, you keep track of both instances of .idlerc. |
For the h: drive issue mentioned above: This was on Python 2.7.10. |
John, thank you for the additional information. 2 copies of .idlerc is definitely bad. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: