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-24.09:52:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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". 

Date User Action Args
2015-10-24 09:52:01eryksunsetrecipients: + eryksun, terry.reedy, kbk, paul.moore, tim.golden, roger.serwy, zach.ware, steve.dower, Maja Tomic
2015-10-24 09:52:01eryksunsetmessageid: <>
2015-10-24 09:52:01eryksunlinkissue25450 messages
2015-10-24 09:52:01eryksuncreate