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.

Author eryksun
Recipients Maja Tomic, eryksun, kbk, paul.moore, roger.serwy, steve.dower, terry.reedy, tim.golden, zach.ware
Date 2015-10-21.07:57:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1445414240.56.0.271474827174.issue25450@psf.upfronthosting.co.za>
In-reply-to
Content
> '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.
History
Date User Action Args
2015-10-21 07:57:20eryksunsetrecipients: + eryksun, terry.reedy, kbk, paul.moore, tim.golden, roger.serwy, zach.ware, steve.dower, Maja Tomic
2015-10-21 07:57:20eryksunsetmessageid: <1445414240.56.0.271474827174.issue25450@psf.upfronthosting.co.za>
2015-10-21 07:57:20eryksunlinkissue25450 messages
2015-10-21 07:57:19eryksuncreate