confusion regarding os.path.walk()

[Steven Majewski]

On Tue, 19 Feb 2002, Andrew Brown wrote:

>
> Thanks for your help. What you describe is what I thought should
> happen. But I couldn't figure out how to join the paths. It always
> looked right: I'd do debugging runs that simply printed out the
> command it was supposed to execute, and I could get results like
>
> 'ln -s ./wombats/habitat/burrows.html ./wombats/habitat/Burrows.htm'
>
> (which I think should work) but when I ran this through os.system(),
> it failed every time. So did every other variant I could think of
> except changing to the directory where the file was and linking
> without any paths involved.
>

Ok -- the problem there is that if you use a relative path in the
symbolic link, then when it's expanded, it's relative to the LINK,
and not to you current working directory. So it's trying to resolve
into something like:

  .../wombats/habitat/wombats/habitat/burrows.html

That's not really a Python problem: I'ld say that the man page for
'ln' is wrong because they list the arguments as both being files
( source_file, target_file ) when in fact, one of them is a file
name ( which it will create ) and the other is a path name of a
file that may or may not exist. Saying the args are files makes
you think that it's going to go out there and find the file and
do something with it (like normalize it's pathname) when all it
does it stick the pathname in the link.

os.path.abspath( link )  and os.readlink( link ) can both give
you the pathname of the file that is linked to, if you want to
check this stuff from Python.

>>> os.symlink( './mail/wwww', './mail/abcXYZ' )
>>> os.readlink( './mail/abcXYZ' )
'./mail/wwww'
>>> os.path.realpath( './mail/abcXYZ' )
'/Users/sdm7g/mail/mail/wwww'



-- Steve