Issue 1646838: os.path, %HOME% set: realpath contradicts expanduser on '~' (original) (raw)

Issue1646838

Created on 2007-01-29 08:07 by wrstlprmpft, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg61057 - (view)	Author: wrstl prmpft (wrstlprmpft)	Date: 2007-01-29 08:07
This might be intentional, but it is still confusing. On Windows XP (german):: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] ... In [1]: import os.path as path In [2]: import os; os.environ['HOME'] Out[2]: 'D:\\HOME' In [3]: path.realpath('~') Out[3]: 'C:\\Dokumente und Einstellungen\\wrstl\\~' In [4]: path.expanduser('~') Out[4]: 'D:\\HOME' The cause: realpath uses path._getfullpathname which seems to do the '~' expansion, while path.expanduser has special code to look for HOME* environment variables. I would expect that the HOME setting should always be honored if expansion is done. cheers, stefan
msg94210 - (view)	Author: strank (strank)	Date: 2009-10-18 10:27
I agree with the 'test needed' stage, but for that, the intended behaviour should be decided on first. A quick test for checking current behaviour:: pythonX.Y -c 'import os; p = os.path; print (os.environ["HOME"], p.realpath("~"), p.expanduser("~"), p.normpath("~"))' Run both, with and without HOME set (or set to something unusual). Current result on Linux for both 2.5 and 2.6:: ('/home/rank', '/home/rank/~', '/home/rank', '~') on Mac OS for 2.5, 2.6 and 3.1:: ('/Users/rank', '/Users/rank/~', '/Users/rank', '~') (for 3.1 it's not a tuple of course). Cannot test on Windows at the moment, but I think there's already something wrong going on here :-). Adding Macintosh and tested python version tags (there's no Unix tag?). cheers
msg94211 - (view)	Author: Marco Buccini (markon)	Date: 2009-10-18 11:06
If we decide to follow paths as '~' it means that we want to follow the POSIX standard. Infact, it doesn't make sense calling os.path.realpath as follow: >>> import os >>> os.getcwd() '/home/marco/Desktop' >>> os.path.realpath('~') To get something like: '/home/marco/Desktop/$HOME' that would expand as: '/home/marco/Desktop/home/marco' At this point we should implement a new os.path.realpath to check if the path passed as argument exists [ See ERRORS section: http://www.opengroup.org/onlinepubs/9699919799/functions/realpath.html ]. But this means that in the worst case, we would raise an Exception (i.e., OSError). As I've said [ here: http://bugs.python.org/issue6975 ] we cannot implement a POSIX compliant os.path.realpath, since it would break with existing code. You understand that a change like this is an API change. I think Python will have an own `realpath` version, not fully POSIX-compliant, unluckly.
msg94217 - (view)	Author: Ezio Melotti (ezio.melotti) *	Date: 2009-10-18 17:42
realpath is only supposed to return an absolute pathname, resolving '.', '..' and symlinks. It's not its duty to expand '~', therefore in your example > In [3]: path.realpath('~') > Out[3]: 'C:\\Dokumente und Einstellungen\\wrstl\\~' the '~' is seen as a normal file and the cwd is used to create the absolute path to it (on Windows realpath is the same as abspath, on Linux realpath calls abspath when there's nothing to resolve, so the result is the same -- i.e. cwd + filename). realpath needs better tests and documentation though, but this can be addressed in #6975, so I'm closing this.