This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Python 3.5 starts in C:\Windows\system32 as current directory
Type: behavior Stage: resolved
Components: Installation, Windows Versions: Python 3.6, Python 3.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: Maja Tomic, eryksun, kbk, larry, ned.deily, paul.moore, python-dev, roger.serwy, steve.dower, terry.reedy, tim.golden, zach.ware
Priority: release blocker Keywords:

Created on 2015-10-20 21:31 by Maja Tomic, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (11)
msg253257 - (view) Author: Maja Tomic (Maja Tomic) Date: 2015-10-20 21:31
I'm teaching kids to code in Python. Today we had two boys, one with Windows 8, the other one with Windows 10. In both cases Python 3.5 was installed and the automatic path where files are saved was C:\Windows\system32. This wasn't possible, since it cannot be written to. Yet, the boys tried to save files to it. 

In the Windows 8-case the file did not get saved. Yet, IDLE still refered to the file as having an error (it couldn't find the turtle package because the file was called - we got that right eventually). Even after reinstalling Python it still refered to the non-existing file and the error in it. 
We changed the path and it solved the problem. Hope this can be fixed.
msg253276 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-10-21 04:27
On my win 10 machine, upgraded from win 7 a week ago, I have C:/programs/Python27, ...34, and ...35.  C:/Windows/system32 contains python27.dll and ...34.dll, but not ...35.dll.  For Idle 2.7 and 3.4, default 'Save As' directory is Python27 and ...34.  (Saving to install directory is not best but works.) For 3.5, it is indeed ...system32.  This is wrong and bad.  The startup directory becomes '.', at the head of sys.path, the module search path.

This is not an IDLE issue.  Start console Python from the icon.
>>> import os; os.getcwd()
'C:\\Programs\\Python34'  # 3.4
'C:\\WINDOWS\\System32'  # 3.5
The following test of Python installed on Windows (preferably before release) would have caught this regression/bug.
  os.getcwd() == os.path.split(sys.executable)[0]

As for IDLE: in, save_as (l.350) calls asksavefile (l.512).  That calls tkinter.filedialog.SaveAs().show with initialdir = self.defaultfilename("save")[0].  defaultfilename (l.500) defaults to os.getcwd(), which, as above, returns ...system32.

I believe this is an installation bug of not specifying the startup directory for the 3.5 Python and IDLE icons (others should be checked also).

The 3.4 IDLE Icon Properties dialog has 'Target: Python 3.4.3 (64bit)', the latter in grayed-out read-only unselectable text and Start in: C:\Programs\Python34\, the latter rather dangerously pre-selecteed (and hence too easy to inadvertently alter or delete).  

The 3.5 dialog has '''Target: C:\Programs\Python35\pythonw.exe "C:\Programs\Python35\Lib\idlelib\idle.pyw"''', with the target preselected.  This change is useful since users can add IDLE startup arguments at the end, such as '-s' to execute PYTHONSTARTUP.

However, 'Start in:' is blank and for what ever reason, the default is ...system32.  Putting C:\Programs\Python35\ there fixes the problem, and that or something should be there on installation.  When I start IDLE on a command line with "python -m idlelib", the start 'directory' is "Desktop /n Terry", which is an alias for c:\Users\Terry. For most people, that is a better default directory than the install directory.

Larry, Maja is the 2nd or 3rd teacher to report this problem.  See python-list thread "teacher need help!"
for one who had problems on 3 of 13 machines and in desperation "formatted the machines, reinstalling everything, including Python."

Maja, the recurring problem may have been due to the bad startup directory being the first directory searched for imports. Or it it may be due to 'C:\Windows\system34\' being recorded in <home directory>/.idlerc/recent-files.lst, which is used for File -> Recent Files.  Although IDLE deletes at least some bad entries, the ultimate solution to problems with that file is for a user to edit and delete bad names or delete the file entirely.
msg253278 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-10-21 07:57
> 'Start in:' is blank and for what ever reason, the default is ...system32. 

When the "Start in" field of a .lnk shortcut is blank, the child process inherits the working directory of the parent process (i.e. the process that runs the shortcut), unless the parent passes some other directory to ShellExecute. 

If you copy the shortcut to the desktop, for example, Explorer sets the working directory to the desktop. If it's run from the command prompt, cmd uses its own working directory. When run from the Start menu, the child inherits Explorer's working directory, %SystemRoot%\System32.

The old installer (pre-3.5) sets "Start in" to the installation directory. IMO, a better choice would be "%USERPROFILE%". The Windows shell expands the environment variable to the current user's profile directory when it runs the shortcut. 

I'm not keen on using a profile subdirectory such as "Documents" or "Desktop", since a user can relocate most of the special folders in his or her profile. Unfortunately the "Start in" field won't accept shell: locations such as "shell:Personal" or "shell:Desktop". It would be nice if it did, since those take into account relocated folders.
msg253280 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-10-21 08:15
Thanks for the explanation.  When I did the test with Command Prompt, I happened to be in /Users/Terry, which is where C.P. starts.  %USERPROFILE% is what I was thinking of but could not precisely remember.  It worked when put in that box.

I think adding /Documents would be a mistake because many users (including me) put Python stuff in other subdirectories.

A minor mystery.  Changing Start in: for the Python icon requires admin permission; for the IDLE icon, not.
msg253393 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-10-23 20:41
Unfortunately it looks like MSI won't let you put an environment variable into the shortcut, as it has to resolve it on install (see WkDir at

Trying some other ideas, but it looks like the most robust solution will be for IDLE to change the current directory on startup (maybe via a command line option?), or specify the initial directory in its open/save dialogs.

Otherwise, the best I can realistically promise is to set it to the Python install directory, which is not particularly useful either...
msg253394 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-10-24 03:35
I see the problem: there is only one IDLE icon for all users, so you need the env var to customize for each user, which you cannot use. Staying with the python install directory, as before, should be better.  We never got any complaints about that.  But the new install locations are more problematical.

I have also thought of adding an new startup option, but it should only apply if IDLE is started with the ICON.  When started at the command line, it should start at the current directory of the console, as it does now, so '.' refers to that directory.  Ironically, a current directory of .../system32 would be a good indicator.  I need to see what is in sys.argv after the different start methods.

This issue is currently only for Windows. I don't know what happens on other systems or whether they could stand improvement.
msg253401 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-10-24 09:52
Steve, I think you're right that it's simpler and more reliable to add a command-line option that sets IDLE's working directory to the current user's home directory. 

Terry, the default behavior in Linux, at least in Ubuntu, is to start IDLE with the working directory set to the user's home directory. 

The Linux equivalent of a Windows .lnk shortcut is an XDG .desktop file [1]. A desktop application entry sets the working directory using the "Path" key, such as Path=/absolute/path (or also, and maybe only in Ubuntu Unity, Path=relative/path) in the main "Desktop Entry" or in a "Desktop Action" (i.e. right-click menu action). Environment variables are not supported. 

If "Path" isn't defined, I can only say from experience what Ubuntu's Unity shell does, since the spec doesn't define a default behavior. In this case, the child process inherits Unity's working directory. Since it's a plugin for the Compiz window manager, the child inherits the working directory of Compiz. This is the current user's $HOME directory, which Compiz inherits indirectly from the user-mode init process. I confirmed the behavior by attaching gdb to compiz and executing `call chdir("/home")`, and then continued compiz and opened IDLE to verify that the working directory was inherited as "/home". 

msg253440 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-10-25 23:16
We can add more options to the start menu icon, even something like "--start-in %userprofile%" should work there, as it really is just a blob of text (though I need to test that). Accepting "--start-in ~" and os.path.expanduser() would also be fine, I believe.
msg253804 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-10-31 20:08
New changeset df12c29882b1 by Steve Dower in branch '3.5':
Issue #25450: Updates shortcuts to start Python in installation directory.
msg253805 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-10-31 20:09
I've fixed the shortcuts. Let me know if you add any extra command line options to Idle for setting a more useful start directory and I can add those to the shortcuts as well.
msg253816 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-11-01 00:11
Steve, I am adding you as nosy on #22121, which is now about adding a new startup option.
Date User Action Args
2022-04-11 14:58:23adminsetnosy: + ned.deily, larry
github: 69636
2015-11-01 00:11:23terry.reedysetmessages: + msg253816
2015-10-31 20:09:51steve.dowersetstatus: open -> closed
stage: needs patch -> resolved
2015-10-31 20:09:37steve.dowersetresolution: fixed
messages: + msg253805
2015-10-31 20:08:08python-devsetnosy: + python-dev
messages: + msg253804
2015-10-25 23:16:29steve.dowersetmessages: + msg253440
2015-10-24 09:52:01eryksunsetmessages: + msg253401
2015-10-24 03:35:44terry.reedysetmessages: + msg253394
2015-10-23 20:41:42steve.dowersetmessages: + msg253393
2015-10-21 19:51:42steve.dowersetassignee: steve.dower
2015-10-21 08:15:07terry.reedysetmessages: + msg253280
2015-10-21 07:57:20eryksunsetnosy: + eryksun
messages: + msg253278
2015-10-21 07:44:48terry.reedysettitle: IDLE: Save path automatically choses C:\Windows\system32 -> Python 3.5 starts in C:\Windows\system32 as current directory
versions: + Python 3.6
2015-10-21 04:27:46terry.reedysetpriority: normal -> release blocker

messages: + msg253276
components: + Installation, - IDLE
stage: needs patch
2015-10-20 22:01:22zach.waresetnosy: + roger.serwy, paul.moore, tim.golden, terry.reedy, kbk, zach.ware, steve.dower

components: + IDLE, Windows, - Installation
title: Save path automatically choses C:\Windows\system32 -> IDLE: Save path automatically choses C:\Windows\system32
2015-10-20 21:31:56Maja Tomiccreate