One case that is easy: Files that go into /tmp on unix should probably
go into \tmp on my dos machine. ( \tmp is not a necessary part of the
dos file tree, but quite a number of programs require it, or some logical
assignment of TEMP. I can think up other cases, but most of them are
a little more strained in terms of what is "reasonable" translation.
One other case that is not would be with relative pathnames in a package
that expected files to be in a definite "relative" path. ( Like for
example Python's own import search path! ). [ Actually, if you stick
to common denominator characters, you can already do this with the
path module. ]. The user may be expected to change the top level
directory, but not the whole set of path names used.
>
> Filenames (i.e. no slash on UNIX) are a different matter, but even
> there the choice of names usually has to be revised by a human being
> when moving to a different O.S., e.g. names begginning with a . are
> not usable on MS-DOS.
>
But, yes: *FILE* names, rather than *PATH* names are where MOST of the
translation is useful. Even useful interactively - some of us who jump
from system to system would RATHER be able to slip up and write a
unix style pathname and have it translated instead of getting an error.
But, again: I'm not asking for that as an automatic feature. Someone
should have to explicitly invoke it or explicitly alias open() to a
wrapper that does it. It should NOT be a default action to rename
peoples files into something else without warning them!!!
Bye - I've got to go celebrate Chinese New Year ( a few days late ) !
- Steve